What's the Proper Meter sendEvent coding .

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:

	sendEvent(name: "energy", value: cmd.scaledMeterValue, unit: "kWh", isStateChange: true )
	No Hubitat defined sendEvent name / attribute / unit (?)
	sendEvent(name: "power", value: cmd.scaledMeterValue, unit: "W", isStateChange: true )
"Pulse Count"
	No Hubitat defined sendEvent name / attribute / unit (?)

	sendEvent(name: "voltage", value: cmd.scaledMeterValue, unit: "V", isStateChange: true )
	sendEvent(name: "amperage", value: cmd.scaledMeterValue, unit: "A", isStateChange: true )
"Power Factor"
	No Hubitat defined sendEvent name / attribute / unit (?)

	No Hubitat defined sendEvent name / attribute / unit (?)

	No Hubitat defined sendEvent name / attribute / unit (?)

First of all it's all based on the driver capabilities:

Driver Capability List - Hubitat Documentation

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?

1 Like

when would be a example of using false?

I think he is suggesting don't set it at all and let the DB figure it out.

It definitely enlarges the db and works the entire system on needless wakeups of subscribers.

1 Like

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.

1 Like

:point_up_2:This.. Except in a few rare cases where duplicates are expected and necessary, like button controllers.

1 Like

You would be better off not sending the event.. Because it will write if the value is different.


thats why i couldnt understand if you are sending event and its false, does it do anthying?

i get the true, but what happens if you put false, would the event be recorded?

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.

So even if it was a new value, it wouldn't get written anywhere and just skipped?

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).


  1. Event with different value for the attribute = event always logged
  2. 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
  • otherwise event is thrown out

im confused, i was looking to clean the history, so displayed false works for thermostatOperatingState but not thermostatSetpoint what am i missing

sendEvent(name: "heatingSetpoint", value: SetPoint, unit: "C")
	                            sendEvent(name: "thermostatSetpoint", value: SetPoint, displayed: false)
                                if (device.currentValue("thermostatMode") != "off" && SetPoint.toFloat() > device.currentValue("temperature").toFloat()) { 
                                    sendEvent(name: "thermostatOperatingState", value: "heating", displayed: false)}
                                else { sendEvent(name: "thermostatOperatingState", value: "idle", displayed: false)}

The "displayed" parameter currently does nothing, it's a carryover from st and isn't used in Hubitat.

If you're trying to truncate event history you can temporarily set the event history setting to 1.

(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.

1 Like

Thanks i was only trying to clean it up on the dashboard device history, guess I cant

Users can edit the online documentation too...

So the same comment can be made to end users that feel strongly about this - feel free to do an online edit. :slight_smile:

But I agree that continued improvement in documentation is valued.

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.