I've noticed that most of my automations do not work the first time they're executed after a hub reboot. Second time, they do run. For example, my "double tap down to set dimmer to 25%" Rule Machine 5.1 app. It works fine until the hub reboots. Then, no matter how long after the hub reboot, the first time I double-tap, the light doesn't turn on/get set to 25%. I double-tap a second time and the rule executes as expected.
I've checked for z-wave ghosts, and there was one, but removing it hasn't fixed the issue. It happens on switches of various brands (GE, Zooz, Inovelli), so maybe this has something to do with the hub.
I've searched, and most results are for issues where rebooting the hub is the solution to an issue with the automation itself--that is not the situation here.
If you can share screenshots of the rule as well as hub log entries around the time you trigger it, that will help a lot in getting to the bottom of what’s going on.
Google AI says " The issue of Z-Wave button devices missing the initial command after a hub reboot is a known behavior, often stemming from timing issues during network re-initialization. "
Maybe that has something to do with it, hard to say given the info. It seems you are referring to mains powered Zwave switches, and you are not just talking about battery devices?
Very common for me. I’m pretty sure, for me, it’s just battery powered devices that haven’t awoken since the reboot. I have few enough that I can usually just walk around and cycle them once.
I've been chasing down all the angles I've come across so far:
z-wave ghosts: had one, can't imagine it was interfering, and after removal problem persists
hub firmware updates; problem has been present for a while, and I'm currently on latest (Platform Version 2.4.3.176)
overly-chatty devices: I unknowingly had logging set to "debug" for lots of devices; disabling debug logging has obviously cut down on z-wave chattiness, but problem still persists
known issue mentioned by @chrisbvt above about timing issues: I've waited many hours between hub reboot and triggering one of these automations, and the problem persists
device firmware updates: I'm working through device firmware updates now, but my devices do seem to have relatively recent firmware (e.g., Zooz ZEN72 switches are on 3.30 (3.70 is latest))
AI sent me down a seemingly reasonable path of creating a rule to "warm up/prime" my z-wave devices after a hub reboot. The theory was that the hub had to query the device to "warm up" whatever chips/code/etc. was needed to execute the automations. The rule we configured attempted to do a "Refresh" of each device about 90 seconds after the "systemStart" event was recorded in the hub logs. This rule also didn't resolve the issue, and AI's next suggestion was to change the rule to do an innocuous "set" command instead of a "get" command, with the theory being that this would truly get the comms channels up and running so that the button-press automation would work the first time. This is the point at which I felt the AI was starting to make up nonsense, so I pivoted here.
As for the automations themselves, they're fairly straightforward Rule Machine 5.1 rules for multi-tap gestures on my Zooz, GE, and Inovelli wall switches. Here's a sample of one of them:
I can reliably reproduce the issue by rebooting the hub. I'm now trying to more formally test what, exactly, happens in the logs when the multi-tab gesture is pressed on the switch after a hub reboot. My recollection is that the first time the gesture is executed, the logs show the button press, but the lights don't turn (which implies to me that the RM rule isn't firing and this is a hub issue). The second time the gesture is executed, the logs show the same entries for the button press, and the rule actually fires and the lights go to the correct level.
@TArman , totally understood about battery-powered devices needing to be woken up, but in my case this is happening with mains-powered wall switches.
I'll post logs as soon as I can after this round of testing.
Well...a firmware update on the Zen72 switch seems to have resolved it there. I did have to exclude and re-include the Zen72 to get the new firmware version to appear in Hubitat. (Either that or some of the other "handle jiggling" I've been doing has resolved it in initial testing.)
I've started what apparently will be a very long firmware update process on the Inovelli LZW-31SN switches (to Beta 1.61 from Production 1.57) to see if that fixes it on that model switch. We'll see if I have to exclude/re-include these. If so, I'd guess it's not the firmware update itself, but the exclusion itself that is fixing it. Not sure if I'll be able to know for sure, of course.
