Avoid sending events for unchanged attributes


#1

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?


#2

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?


#3

duplicate events aren't committed to the database unless one of more or the following are true:

  1. the sendEvent isStateChange:true is set
    OR
  2. on the app side the subscribe filterEvents: false
    option is set.

#4

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.


#5

which duplicates the code in the OS to suppress duplicate events. :slight_smile:


#6

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.


#7

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.