You and me both.. Especially because I'm running the latest HubConnect code and nothing from my dev branch at the moment.
Technically, your systems behavior is wrong 
The documentation about isStateChange says:
By following that logic, specifying isStateChange:true will cause an overwriting of the standard behavior and cause an event every time. But I can't understand why you are not seeing this....
Just curious, and it may be unrelated, but why does Hub 1 show the Red Ball in the top right corner, while Home Hub does not - is Hub 1 not responding or something?
I bet it is a SW update for beta releases that he doesn't have installed.
1 Like
Haha.. It's telling me that there is an update. The hub is registered for the beta but I'm not installing any beta code right now so close to the holidays.
1 Like
Oddly,
I was able to replicate the duplicate events on the Hubitat virtual on my dev hub. I had been having issues with @djgutheinz TP-Link drivers throwing a ton of duplicate events on HubConnect.
His drivers are not filtering state changes for attributes at all.
It appears that the hub is not consistently performing any event deduplication for virtual & LAN devices.
I'm tagging @mike.maxwell and @chuck.schwer for a more definitive answer.
what's the elapsed time in ms between the events in question?
In my case, in the video I posted about 3 events in approximately 1 second.
EDIT.. However, if a driver calls sendEvent with a name/value pair, and there is no change to the value, shouldn't the event be cancelled as a dup? That is how it works with the Zigbee/ZWave devices I've tested.
That is the right question - When do dup events get de-duped?
Before or after they get sent out on the Event Socket?
I assume after based on what I am seeing (which I think makes sense, as the dedup would happen 'later' when it goes to write the event to database) but that is an important detail to clarify.
Actually, the real question is whether they are following the SmartThings paradigm as we all assume.
On ST:
Only events that constitute a state change are propagated through the SmartThings platform. A state change is when a particular attribute of the device changes. This is handled automatically by the platform, but should you want to override that behavior, you can do so by specifying the
isStateChangeparameter discussed below.
Therefore, any attribute change should be filtered and killed before raising the event if there's no change to the value. This is currently not happening consistently, as we are seeing here and with the TP-Link drivers.
Agreed. And for what it is worth that is how I think it should work. Event Socket should be propagating only de-duped and/or explicitly tagged state change events.
1 Like
And you need to consider this
isStateChange
boolean - true if this Event caused the device’s attribute to change state. false otherwise. If not provided, createEvent will populate this based on the current state of the device.
Meaning, if it is set to true the platform shall not filter out events...
1 Like
Right, but if Event Socket was only passing de-duped + explicit state change events to begin with, then having "isStateChange: true" on the HubConnect remote side would be fine [required, actually, to ensure explicit isStateChange: true events on the source side are honored].
As, by definition, every event that showed up on the other side would be a real event (so nothing left to filter out on the remote side - regardless what the previous value was).
1 Like
HubConnect is built upon the SmartThings event model, meaning that any events sent from one hub to the other are supposed to reflect an actual change in state as the event is generated at the sending hub.
At that point on the receive hub, having isStateChange:true on the receive end will not have any impact as all received events are SUPPOSED to be state changes. It shouldn't even be needed for buttons but it has been posted here before that it is.
2 Likes
This does feel more and more like a Hubitat bug/design issue to me. 
1 Like
Not disagreeing on that, going to be interesting for us to justify that on the unsupported event socket... just saying 
1 Like
For those wondering why isStateChange has to be true for buttons...
True. 
How dare the unofficial, unsupported function not work the way we want! lol
Yes. Anything with only 1 state, or multiple single states, has to have isStateChange: true.
Yeah, the event socket was meant for the dashboard where it doesn’t matter if the event with the same value is happening twice. Yes, it does force a redraw on the dashboard but there is no user/functionality impact
