sendEvent(name: "alarm", value: "off", displayed: false)
This is in a driver code. How would I make it such that it ONLY sends a "sendEvent" if the alarm <> off?
There is no way to answer that question with that limited info...
The general answer, though, is that in the code wherever it is checking the value of the alarm, you would do an IF statement on it...
by default only events where the new value != the old value are committed to the database.
also, the displayed parameter is not used in Hubitat, best to just drop it altogether...
1 Like
So you never want alarm off events to happen?
Why?
No, only if the previous state was not off
Then the code is correct as is. As Mike explained, an alarm off event will only happen if the value for alarm was different. Is the driver not working as expected?
displayed: false can be removed because it's not used on Hubitat, but it won't hurt anything because it's ignored.
Don't know exactly what happens behind the scenes but something is definitely happening when using sendEvent() even thought the current attribute state is the same as the value being sent.
I have a custom driver which are polling a cloud API every minute (async) and without a conditional check in the parse method I can see the same events pushed every minute in the eventsocket stream. Since this driver is creating multiple child devices with lots of attributes there is a lot happening in the ws without anything actually changing (of course there are changes from time to time).
In my mind the the correct approach would be to handle this conditionally and not let the hub process unnecessary data and the same goes for the receiving part that handles the websocket stream.
Agreed, sendEvent() is sending an event via websocket even if the previous state was the same.
What is the specific command that is in the driver? sendEvent(.....)?
With conditional check:
if (device.currentValue('status') != alarmState.statusType) sendEvent(name: "status", value: alarmState.statusType)
As a HubConnect user, I'm landing on the 'more pleased' side that the Event socket is behaving this way...my reasoning is this:
Eventsocket is a tcp data flow. We have 100mb data connections and therefore the stream is 'sparse' relative to the connection capacity. Same is true on the receiver end, where I hope that the events get processed identically..
This would mean to me that Events on Hub 1 would be seen by Hub 2 and ignored if there's no matching device on hub 2; or would be seen and processed using that ' !=' and therefore for duplicate events, also ignored.
In other words, burning through a few hundred K of LAN traffic isn't something that's worth it to "fix". On the other hand, if that '!=' doesn't get applied... we then, nevermind 
This is mirroring HSM armed status?
I don't see the benefit of a repeating message with the same information, perhaps if you use it as a way to see if the device is still alive. In my mind when there is an actual change it should be pushed.
The transport of the data is not the problem but more how it's being generated and handled on the other end. Remember that people are experiencing problems with hub slow down etc and if their is a better way to do things I think that we as developers should do it. In the end the better way would be to validate this in the sendEvent api.
1 Like
Nope nothing fancy there yet. Only a asynchttpGet with a json reponse that is parsed and updates device attributes and child devices or creates new if not found.
Without the conditionally if check, if nothing is happening with sensors, switches etc I get 20-30 updates in the eventsocket every minute with the exact same information. And my system the driver is integrating is quite small compared to other users.
It's not 'accidental' duplicate events under discussion.. or at least I assume not. Someone pushed a button then again, then again. Or Automation is running a Rule that's doing the same thing over. In other words, they are 'real events' and thus the Event stream should be informative.
wx-ApiXU-Driver does the same:
It acquires 60+ attributes with each poll cycle. It then injects those into the db via sendEvent. I spent my coding time trying to inject ONLY the attributes the user wants, not on trying to duplicate that '!=' code.
yea, sounds familiar. APIXU polling isn't every minute, but with each poll, many attributes can change, or remain static. Temperatures change pretty often I'd assume, especially at tenths of a degree. On the other hand, sunrise doesn't change ever and yes, I 'filtered that' by not polling but once a day. But my filtering was on the cloud side.. the 'slow' side. Injecting events into the DB locally sure isn't slow.
I did all the work on wx-ApiXU-Driver simply because it came up that APIXU-Weather was hammering the DB with "isStateChange: true" on everything. After that I couldn't leave well enough alone. 
Today I read that I can edit every line again for 'displayed: true'
APIXU was injecting 15,000 events a day, and the event log pagewould take 2 mins to load, displaying 56,000 lines. Looking at my production wx-ApiXU-Driver events now, I can see 75 days of logs and 15,889 entries.. 211 a day. A giant improvement, and one in line with trying to reduce the core load on the DB.
It's your app. If you feel that another '!=' check is invaluable, I would agree. But I'd still come down on the 'more pleased' side of letting Hubitat have the '!=' check on the db, vs the event stream.
Ah, well you didn't mention events via web socket in the OP, sorry.
Since @mike.maxwell specifically refered to the default behavior of events as it pertains to the database, perhaps ask him what the expected behavior is as it pertains to event sockets?
It's Ok, I figured it out, which is rather incredible!
I managed to work out how to do the if statement, and it's working well.
1 Like
