When a device attribute receives duplicate data it still calls any subscriptions, which is rather inefficient. Is there anyway to avoid this, other than modifying isStateChange in the driver?
I think that in the case when the attribute value does not change, calling sendEvent() does not actually trigger any of the subscribed apps. The only thing that happens is that the device's last activity property is updated.
1 Like
Definitely triggers apps.
I have some logic to ignore these close together events, but it would be better if they were not called at all for duplicate data.
What does your subscription look like? Did you specify filter: false? And is your app actually waking, or are you just relying on the Events page to show what apps might (not sure if that is technically looking at that or just subscriptions to the event in general)?
@bertabcd1234 The mystery is solved, it is the device driver that sets the isStateChange:true for duplicated values of the temperature attribute when the minimum reporting time (1 minute) is exceeded, in combination with a chatty device.
A note for me : ) : The logic should be : set the isStateChange:true flag only when the device did not report during the 'Maximum reporting time' preference parameter.
As an example:
'Minimum reporting time = 60 seconds' - do not send events if less than 60 seconds have elapsed since the last temperature event. Send the event delayed 60 seconds since the last temp. event.
"Maximum reporting time = 3600 seconds (one hour)" - send the temperature event even if it is duplicated, but the time since the last event is more than one hour (useful for showing nice graphs)
... or something like this.
2 Likes
I was not familiar with the filter option so I'm not specifying it. Which should be favorable to me as the default is true (filter duplicate events.).
I was looking at the events page on the device
Obviously the value is duplicate and the events are only seconds apart and it indicates that the event handler is called, even though the default option on the subscribe is true (filter).
I have some logic in my app to group events within a given time window. But it still results in the app being called excessively, it just publishes less. If there is a built-in way to be more efficient I'd prefer to use that.
I'll have to do a little testing to see if the device handler is actually getting called each time but the Count column in the App Stats suggests that it is. It would also be a poor choice to indicate the handler was getting called if it were not being executed.
