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
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.
2 Likes
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).
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
- 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). https://docs.hubitat.com/index.php?title=Event_Object
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 (https://docs.hubitat.com/index.php?title=Driver_Capability_List) 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. 
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.
2 Likes
Well, that is 100% on Hubitat then. Disappointing.
1 Like
If I use isStateChange:false, will it send a state change if something actually changed? Or does that force it not to update?
yes, it is supposed to. Really, setting it to true just bypasses the hub's built-in event de-duplication.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
