Can anybody from Hubitat confirm the proper sendEvent coding for Zwave meter reports. More specifically, Zwave standard SDS13781, Table 74 (page356 of https://www.silabs.com/documents/login/miscellaneous/SDS13781-Z-Wave-Application-Command-Class-Specification.pdf), defines the following 9 meter report types. I want to be sure I'm mapping them properly and I'm using the expected "unit" values, but I can't find clear developer documentation from Hubitat on this:
"kWh"
sendEvent(name: "energy", value: cmd.scaledMeterValue, unit: "kWh", isStateChange: true )
"kVAh"
No Hubitat defined sendEvent name / attribute / unit (?)
"W"
sendEvent(name: "power", value: cmd.scaledMeterValue, unit: "W", isStateChange: true )
"Pulse Count"
No Hubitat defined sendEvent name / attribute / unit (?)
"V"
sendEvent(name: "voltage", value: cmd.scaledMeterValue, unit: "V", isStateChange: true )
"A"
sendEvent(name: "amperage", value: cmd.scaledMeterValue, unit: "A", isStateChange: true )
"Power Factor"
No Hubitat defined sendEvent name / attribute / unit (?)
"kWh"
No Hubitat defined sendEvent name / attribute / unit (?)
"kVAh"
No Hubitat defined sendEvent name / attribute / unit (?)
Secondly.. I would avoid using isStateChange: true. Using this on meter events could overwhelm the database and is unnecessary. If there is no change to the value why force a database entry?
The other ones.. Looks like you have the basics down..
There are not capabilities for all of these, but if you need them for some reason, you can do custom attributes.
Thanks. On the isStateChange comment, I thought I had seen some developer documentation that you were supposed to include that in sendEvents -- I think it was on the State Object page, but when I went to check that page, it seems to have disappeared https://docs.hubitat.com/index.php?title=State_Object so I just added it from recall. Thanks for clarifying (and it would be helpful for somone to restore that State Object page!).
If you isStateChange is used to force a database entry.. If the values have changed there will be an entry.. But if the values are the same there won’t be an entry unless you set this..
The only time I use this in my drivers is button controllers, where you might hit the same button multiple times.
Otherwise if the value hasn’t changed why write to the database?
thats why im inquiring, what situations would you use false, im wondering if it could be used to clear up history list where i have heating setpoint and thermostat setpoint but their always the same
The only thing that clears history is a db cleanup/pruning.
You might use false if values change by a little bit (decimal place) and you as the device driver writer don't want to wake the world up about it. Concocted example, but what I can think of.
The default value (if not included in the method call) for isStateChange is false, there is no need to set it.
The database will not commit a value if it is the same as the previous value unless either of the following are true.
sendEvent included isStateChange:true, or an app subscription includes filterEvents:false
This is an event driven system, most events are only of interest when the value changes, the above constitute performance optimizations.
If we're trying to create datasets for charts, it's more efficient to have the export app use its own rate interval by reading the existing attribute values then force devices to comply with the desired reporting interval when most of the time their values will not have changed.
No... if it is a new value then it would be a state change by definition and would log an event. isStateChange = false only throws out values that are the same, not new/different ones. (assuming no app has subscribed to an event with filterEvents: false like Mike mentioned above - that overrides the isStateChange: false setting).
Summary:
Event with different value for the attribute = event always logged
Event with exact same value as the previous event for that attribute:
isStateChange: true OR app exists with subscription and specifies filterEvents: false = event is logged
(this is a general comment on developer documentation, and not to you (Mike) specifically)
It would be extremely helpful if there were a practice put into place where, each time someone at Hubitat responds to a user on issues like this, providing clarification that isn't already present in the online documentation, the substance of the response be incorporated into the online documentation. Over time, that would greatly improve the online documentation and cut down the time that Hubitat staff spends responding to questions (though the staff's responses are very helpful and timely). For example, the online documentation suggest that "displayed" is used (otherwise, its odd to have it listed). Event Object - Hubitat Documentation
I realize that the online documentation is supposed to be a wiki, but that doesn't seem to be effective without more Hubitat staff input. For example, months ago, I made edits to the Driver Capability List page (Driver Capability List - Hubitat Documentation) to add a section on implementation notes and units section to many of the Capabilities. I used to be able to access my pending edits on that page, but they were never incorporated (and now I don't see them at all) - it was quite a bit of lost work which, if I knew there was someone incorporating the edits, I would attempt again, but it doesn't seem to be the case that they get incorporated.
Its not really the same comment. End users and Hubitat staff are in totally different positions as to their ability to make edits, and the definitiveness of their knowledge.
Putting that aside, my point was that the staff is already writing responses -- often very helpful, clear, and well thought-out responses -- I was simply suggesting that it would benefit all if there was a process whereby a copy of those responses are incorporated into the developer documentation, rather than existing only as forum messages where its a bit of a hit-or-miss to find them. The forum response to a user can then just be a link to the updated documentation. This benefits all developers and centralizes the information where it logically belongs. It doesn't seem like much additional work, just a choice to make clear and complete documentation a higher priority.
As for user's making edits, I can't incorporate what I don't know. And even if I do know something, when I make edits they don't get incorporated until a moderator reviews them (which I recognize is an important step to make sure only correct information is included). However, as mentioned above, I went through this process, submitted edits, they weren't incorporated, no feedback given, and it appears they're now gone -- maybe rejected for some reason, maybe not -- I just don't know. That's not a process that works. In any event, for many functions, like how you properly format a sendEvent, the proper "units" to specify in those messages, etc., it really should be Hubitat that gives a definitive word on this to ensure a unambiguous standard is established. User's generally can't provide the certainty or intent that the more knowledgeable staff has.
This.. Except in a few rare cases where duplicates are expected and necessary, like button controllers.
