Yup, me again, sendingEvents again..
When I get an update in a "Sensor" (polling or whatever) .. should I send the event anyway, or should I just drop it if there's no change?
It seems to me like I shouldn't send "duplicate" events, but could this bork anything - most likely in the rule machine.
Not sending a duplicate should reduce load on the system - even if its only to avoid it being written to the event stream.
Thoughts?
Most drivers will do a send event, and just leave isStateChange as false. That way the code is easy (you don't need to decide if/when to send it - you get a report/update you send it), and the system can worry about tossing the dupes.
Because how do you even know if it 'changed' or not when you get a report unless you put in a bunch of code to track and check the variables?
duplicate events aren't committed to the database unless one of more or the following are true:
- the sendEvent isStateChange:true is set
OR
- on the app side the subscribe filterEvents: false
option is set.
1 Like
I just installed Device Watchdog .. and it found a case where suppressing events has an effect.
I have a virtual sensor that I coded to suppress duplicate events, and although it has been receiving "on" events for weeks (via the makerAPI), it hasn't had to send an event in ages.
As a consequence it has a last activity timestamp of "2019-03-14 11:09:24 GMT" - which looks like it's dead, though it ain't!
So "Last Activity" is affected if you suppress events.
1 Like
which duplicates the code in the OS to suppress duplicate events.
Almost, but not exactly... HE code still sends out to the eventsocket.
In fact I think one of the recent dashboard changes was to alter the way it used the eventsocket to reduce this kind of unwanted noise.
Nonetheless, looks like the basic law of optimization applies. Don't do it unless actually necessary.
Which would be for a "high" rate of events where the definition of high is not clearly known.
1 Like