I have pretty much converted over to using apps vs rules. I had github copilot using Claude Sonnet 4.5 analyze my rules (107 of em) and design a series of apps broken down into subject areas that do the same thing, and more! This is working very well.
I want to share a few discoveries I made along the way. I noticed that just like with the rules results were variable, ie: lights would sometimes not go off, or on. I asked claude to look into it and he (remember he has digested ALL of the hubitat docs, and outside sources of z-wave/zigbee doc as well) and came up with the following which has all but fixed my issues, every one of them.
Learned:
He noticed that if you have a lot of zigbee devices and you tell all of them to turn on (or off) the signals congest the band and some get lost.
Devices do not respond instantly to commands, that response time can vary.
Claude added batching the commands, with complete retry (a variable I can tweak) logic (I have seen others are doing this) and delays between the sending of commands. He also added wait times for responses, I demanded responses were received so proper retry can happen. all of these variables have defaults I can tweak.
The results is my lights and other actions now have a near 100% success rate, every time. When my evening lights come on I can see the delays, but they always come on, every time. And go off when they should.
I have a github repo if anyone wants to see how it works:
The Docs folder has claude's analysis of the Hubitat docs. He has an imperative to always read all docs before doing anything.
I've had good luck in my apps with just a 100ms delay between commands, I think that is all that is needed.
I read my device scene info for each scene from a map, I create a deviceWrapper for each device as I iterate through the map, and then I set the device to the level and/or switch state from the map using the device wrapper.
I don't think batching is really needed either if there is already a delay between commands. You can also just enable the Hubitat device retry in the devices themselves to get that logic out of you apps.
I want all the logic in my apps. That is why I did it. I get tired of going to this device, that device, that rule etc, was becoming tedious. This way all is in one place.
Fair enough. I just don't want to add overhead to my apps for something that is already a hub function, which will run in it's own thread outside of the app, and I assume in a more optimized way than it would run if it was coded into the app directly.
I also only use Hubitat command retry on a few devices, which have there own issues, not related to how my apps command them. I generally don't have any issues with devices missing commands from my apps using the 100ms delay.
Yup, that is pretty much what I have command retry on, the Sengled Bulbs, specifically the candelabra bulbs. Though I have added a lot of repeaters over time and that seems to have sorted the Sengled bulb problem lately. Sengled bulbs are very picky about having a strong mesh or they can miss commands. I assume it is something to do with how they pick their routes, my bulbs will ignore repeaters that are close by, but if given many repeater route options, they seem to find their way.
Exactly what I see. I have zigbee repeaters all over but some bulbs seem to ignore them. Thwe rety logic seems to have sorted them. I also use a lot of sengled zigbee switches, which seem to do better than the bulbs
My zwave contacts do better than the zigbee ones ever did, in fact I rarely have any trouble with the zwave devices
Are you using Zigbee Group Messaging for these bulbs? Assuming you have a bunch of bulbs in a single fixture, and want them all to act simultaneously as a single device, you can use Hubitat’s built-in Groups and Scenes app to create a Group of Zigbee bulbs. Enable Zigbee Group Messaging for the Group and then use the resulting Group device to control the bulbs. The Hub will only send a single Zigbee command that all of the bulbs in the Group will receive and act on simultaneously. It really reduces the Zigbee network traffic when controlling a large group of bulbs, and eliminates the Popcorn Effect.
Not to take this conversation too far off into the weeds - But there is a similar concept in the Matter standard - Known as GroupCasts, and based on IPV6 multicast messages -
Alias, it's not yet supported by HE (or at least exposed in their API, as far as I know): Technical Documentation
Good to know, thank you! It makes sense that Matter should hopefully include all of Zigbee’s core functionality, at a minimum. After all, the same group oversees both standards.
Same here. Every light switch box in my house has a Zwave Dimmer in it. I really only use Zigbee for bulbs in table lamps and such, though I am using a Zwave dimmer outlet for my bedside lamps now, and a Zwave dimmer outlet for a small lamp that needs a small bulb to fit.
I find Zwave can be all or nothing, it is great and works most of the time, but when some device fails, it can take down the whole network with it. Zigbee seems to fail more at the device level.
I have only one existing Candleabra bulb online, though in the past I had two in my bedside lamps, one in a decorative ceramic lamp in the living room, and one in a lamp made out of a bottle, also in the living room. The bedroom bulbs would miss more than others, and it is a known weak zone, though I added a couple repeaters. Those bulbs were the worst behaving, missed the most, sometimes disconnecting and reconnecting themselves. The living room ones still missed occasionally, even in the strongest part of my mesh, and they would occasionally disconnect.
I use custom apps, so the back scene executer controls the bedside lights when scenes are run. I iterate through scene data from a map and set the devices with a 100ms delay between commands. Same in the living room for those lights, but that is controlled by the front scene executer app.
Anyway, the bottle light with the candelabra bulb has been behaving especially well lately, with the addition of several Zigbee Outlets used for Xmas Window Candles lights this past Christmas. I'm just leaving the outlets plugged in until next year.
