Two Hubitat Questions

When making large rules, for example, turning lights on and off, would performance benefit from checking if a light is already on/off or not before running an on/off command or just run the command regardless?

I have a ring alarm and recently the keypads started going offline and became unreliable. Also began having trouble with a motion sensor (not ring). After spending time on support, someone asked if I have any other smart system in the house. Long story short, one of my many GE light switches became "stuck" broadcasting whatever it broadcasts. Support suggested turning off all power to reset all of them, which worked and resolved all issues. So... is there a way in hubitat to detect if this happens again and if so, which switch it is and a way to fix it without turning off power?

Thanks.

I would think the opposite... the extra conditional adds processing time. Though not much!

I use Device Watchdog by @bptworld. It will report on any device that is not responding (though not in real time). Your device isn't exactly "not responding" but it might very well catch it. I run it nightly and let it generate a tile that I check regularly.

Oh I didn't know that app can generate a tile! Let me explore

Yup... easy...

It is my understanding that the choke point when sending out a lot of commands is the z-wave radio, not the processor on the Hubitat. So checking a device status before sending a command is net better if sending a bunch of consecutive ZWave commands.

I think that is what "on/off optimization" is in the Groups app.

I use Node Red for automations but I query a device's status before sending a command in my Good Night flow because there are potentially up to 25 things that might need to be turned off.

I don't if sending a command to just one device.

1 Like

Hmm yes good point. I was just thinking of CPU.

I have that happen to me in the past as well. It was caused by one of my devices being “hung” and saturating on of the the Z-Wave frequencies. It is not something that Hubitat can detect unfortunately. However, the symptoms will be apparent (No response or disconnection of Z-Wave devices).

in general it is likely good to check if a device is already in the state requested.

  • This would be an access on the hub, but should be nothing on the zwave network
  • This allows you to not send needless commands on the zwave network

Rule may do this already...

WebCoRE does this by default, but it can be turned of in the webcore ide via "Disable Command Optimization".

Other apps do this like echo speaks also.

This can be a problem if using older zwave devices, that don't report state accurately, but for a bunch of reasons including this, you should really get rid of those devices as they do nothing good for your mesh.

1 Like

I have been wondering about that… if a command is sent to a driver via an app or Rule Machine and the driver knows the device is already in that state, will it send it again? Is there a “standard” around that? Is it even something that the driver can decide?

Thanks for all the feedback.