descriptionText inconsistencies in built-in drivers

As background, Im suffering from continued unreliability in status updates from z-wave devices. No matter how much I add devices to strengthen the mesh, some of my z-wave devices hear and act on commands just fine, but dont report back their status properly. Ive also seen occasions when power reporting devices show a stale, non-zero power reading even though the outlet is off. These devices always snap to the correct status when refreshed by hand.

So Ive put together a node-red flow to randomly refresh my 'switch' and 'level' devices and at some time period after they are actioned. It listens to the event socket and looks at descriptionText to determine if the event is a switch action, or the result of a refresh. The wording convention of "was turned on" for switch actions vs "is on" in response to the refresh command works well for this purpose. However I found that certain of the built-in drivers dont follow the convention.

HB Fan Controller says "was turned on" both when actioned and when refreshed. Should say "is on" when refreshed.

Aeotec Nano Dimmer says "is on" or "level is" when turned on or level changed. Should say "was turned on" or "was set to".

Neo Coolcam Plug says "is on" when turned on. Should say "was turned on".

These are the only issues I found from the devices I have, perhaps all the built-in drivers should be audited to ensure they follow the standard format.

Well, first of all, the HB Fan Controller is Zigbee, not Z-wave. So, that might be your first problem. Z-wave will not repeat Zigbee and Zigbee will not repeat Z-wave.

Second, you're talking about debug logging. Something that has absolutely no impact on the functionality of the device or the system as a whole. Personally, I want the Hubitat staff working on fixing bugs and coming up with great new features and improvements. Not spending time making sure the debug logs are grammatically correct. Why does it matter? Is it really that difficult to understand? Obviously not since you knew what you think they should have been. There's only so many hours in a day, let's spending them where we can get the biggest bang for our buck, wouldn't you agree?

If theres a convention, it should be adhered to. Im referring to what comes out of the event socket. Sure, its probably low priority.

Websockets are currently unsupported and undocumented although they have plans to make them supported at some time in the future. I would assume that standardization, if necessary, would be implemented then. From what I've read on other posts, it's not happening anytime soon. But of course, that could change. We have no visibility into what is coming next.

There is no convention for this.

Hubitat suppresses duplicate events by default so if the switch is displaying the correct state and you click refresh, it's not going to create a new event so it usually won't log anything.

1 Like

The generic drivers are “well behaved” and respond syntactically correctly. ie “is on” on refresh and “was turned on” on refresh.

Nearly all the devices do generate an event on refresh. It’s true that some seem not to.

An event is not the same as the data shown in live logging. What's shown in live logging is the discriptionText property of an event, this property is not mandatory and is not used in building rules or automations, it is there as a convienence only and is irrelevant in the context of automation.

They will usually generate discriptionText in the live logs, they will not generate an event under normal circumstances unless the events attribute value has changed.

I will re-think the process. Most of the drivers I tested did generate events upon refresh, which is why I found the need to differentiate between an event that was the direct result of a switch action, and that of a refresh. The only difference I could see was the wording of the descriptionText. Of course I realize something like this would not be relied upon in practice, but at the same time I should not need to manually refresh these devices to get the correct status if the transport layers below were properly reliable.