Hey Hubitat Team and Community,
I wanted to share an observation after a recent hub update, and see if others are running into something similar—or if there’s a better way I should be handling this.
I’m using a C-8 hub, and all of my devices are Z-Wave, which work extremely reliably. The issue I’m seeing isn’t with the devices themselves, but rather with apps and automations not behaving quite right after a firmware update.
For example, built-in apps like Button Controller and Room Lighting seem to stop working as expected after an update. I’ve had to go into each app and either hit “Done” or make a small change (like turning on logging) to get them to start working again. When I do that, I see log entries like this:
app:7320 25-04-13 09:29:04.701 info Initialized
So it seems like they’re not reinitializing automatically after the hub restarts. Until I give them that manual nudge, some rules just won’t trigger at all. It feels like they’re in some kind of paused or dormant state.
Would it be possible to:
- Add a global “reinitialize all apps” function after updates?
- Automatically reinitialize key built-in apps like Rule Machine, Button Controller, and Room Lighting on boot?
- Or maybe provide some guidance on which apps may need a manual re-init and how best to handle that?
If there’s something I’m missing on my end, or if this behavior is expected and there’s a better way to work around it, I’m totally open to learning. I really appreciate everything the team and community have built here, and I’d love to help improve things however I can.
Thanks again for all the awesome work—and thanks in advance for any advice or insight!
WoA
The first thing you ask for is already there. Click rule machine and a button has been added very recently to initialise all rules.
Add a rule that is triggered on systemStart, set up whatever initialization actions you want. There’s really no way for Hubitat to know the desired initialization actions for your particular setup.
They're not going to unless they subscribe to the systemStart event because they need to for some reason, but these ones don't. So, whatever you're seeing is merely coincidental. Can you share more about your setup so someone can see what might be happening in your specific case? (If you had an RL instance restricted based on some event and something that might undo that happened when your hub was off, that could explain something like what you're seeing -- but that is a very specific case, one you may be able to find another way to work with, and not a general pattern for any of the apps you mentioned -- or really any app -- so that's why this information would be helpful.)
Hey again Hubitat Team and Community (Sorry posted in wrong thread and moving to this one),
Following up on the weird behavior I’ve been seeing since the last hub update—I’ve got a specific example this time that I hope helps illustrate the issue more clearly.
I’m attaching three screenshots to this post:
-
The original rule that used to work just fine. It was triggered by either HSM Arm Away or HSM Arm Night and worked perfectly before the update.
-
A post update log snapshot showing the rule executing correctly when Arm Away is triggered, but doing nothing at all when Arm Night happens.
-
The modified version of the rule that I had to create to get it working again. It seems like I had to rework the trigger to adapt to the post-update behavior.
So basically, the original rule stopped reacting to HSM Arm Night, even though the trigger conditions haven’t changed. It’s like the trigger is no longer firing or being processed properly after the update.
This ties into my earlier post about apps and rules not reinitializing properly after hub updates. Something definitely seems to be different now, and I’m not sure if this is expected behavior or a bug.
If I’ve misunderstood how this should work, or if there’s something else I should be doing differently with mode-based triggers after an update, I’m totally open to correction. Just want to help make sure everything’s running smoothly again and contribute whatever I can to the conversation.
I understand now the Update All Rules button in Rule Machine is for the initialization but there seems to be mini-rules in other apps like button controller, etc that I dont see an update button. Or maybe I haven't looked properly?
Thanks so much for your help and for everything you all do!
—WoA
I'm able to reproduce something similar, which I think comes down to having two sticky ("and stays?") triggers for the same event. There were some changes/fixes made to this in 2.4.1 to address device attributes, but I'm not sure about other events.
With this rule:
I do get a subscription:
But if the data, 9, is supposed to be for the trigger, that is only there for trigger 9, which is one of my HSM states, not the other:
And that is indeed the only one that triggers:
(The last/bottom event here should have triggered but didn't.)
Tagging @bravenel for investigation ... and hoping I'm not forgetting any fixes that might be in beta for this. I don't see anything in the release notes offhand.
I should note that a "Done" or "Update Rule" did not have any effect on this, so I'm not sure what's going in with that if you still see some difference there. I did not test a hub reboot, but that does not affect event subscriptions, so I can't imagine it getting in the way unless you have some other automation changing something like HSM status as a result.
Thanks for investigating. I’ve rebooted many times and troubleshot as best as I could prior to posting. I know I don’t need to say this but the reason why I’m posting is because this rule and many others worked without thought prior to the update. Just fyi and hope I can add more info as it comes up.
This used to work with a single Stays timer because the two triggers are mutually exclusive. But, in 2.4.1, HSM Status is not supported with multiple Stays triggers, breaking backwards compatibility for this case.
I will have a fix for this case coming up in a release. HSM Status just got overlooked in this case. The needed mechanism was there for variables and devices, but not HSM. Fixed and tested with your case....
4 Likes
The fix for this has been released in 2.4.1.162.
2 Likes
