I’m transitioning my Hue Bulbs to from Hue Bridge to ZHA and I wonder how do I set it to “Recover state after power loss”?
I believe that it’s a feature built into lamps themselves, because when it’s enabled inside the Hue App they restore to their previous state immediately. If they were turning on and then recovering state the would’ve been a lag between “turned on” “connected to bridge” “received a command with old state”? I also recall that this feature required firmware update.
I can see some OnOff settings in ZigBee Clusters inside ZHA, but I’m not sure which I should care about and which values to use, etc. Is there any documentation about this?
There is a recent post on this issue, and the consensus is that it couldn’t be done via ZHA. I haven’t read about anything that has changed since then, though it’s certainly possible:
However, there is a workaround in that thread if you have the newer Bluetooth+Zigbee bulbs: just use the Bluetooth connection to set the configuration on the bulbs instead. It should be theoretically possible to do this on ZHA, but I’m not sure they’ve figured out exactly what configuration they’d need to send to the bulb. It looks like Zigbee2MQTT may have got this figured out, FWIW. (You might be able to do it manually if you know what to send where in ZHA based on what they do, but I won’t be much help there…)
This is really a different issue; Hue bulbs support this on their firmware (and actually require fairly recent firmware to do so if you have older Hue bulbs), so the bulb would actually have to implement it (and do so in the same way as Hue) in order for the same thing to work. I’m not aware of any other Zigbee bulbs that do this at all, though there could be some I don’t know of. Most of the few Z-Wave bulbs I’m aware of have a configuration parameter for this. I’ve seen some “hub”-side solutions for this, though none that are quite as satisfactory (e.g., if you have some way to detect power loss or bulbs on for an “excessive” period of time, you might be able to respond appropriately).
Well, I entered 0xff and clicked Set ZigBee Attribute. Then clicked Get - and it returned “StartUpOnOff.PreviousValue”. So it did recognize it.
However when I then turned the bulb off and toggled the light switch off and on - bulb turned on. However the parameter is still “StartUpOnOff.PreviousValue” so it did not reset.
I never figured it out. I just created an automation to run when the ups status changes back to online to turn off all the lights in a few scenarios. Not perfect but it’s better than all the lights being on.
I also have an automation that shuts down home assistant and turns on an input Boolean when the ups battery is running low. When home assistant starts and that Boolean is on the script will run after a delay to give zha time to start up.
I also have lamps in my room with zigbee bulbs and 0 overhead lights so I put them on a ups to avoid being woken up in the middle of the night as they won’t actually turn off unless the power was out for over an 1 hour 30 minutes. That’s my workaround to this.
dmulcahey discussion mention future ZHA goals once ZCL R7 PR merged into zigpy (which it now has):
“Once the ZCL 7/8 PR that was merged into Zigpy is in HA the goal is to support this type of thing w/o having to explicitly specify things the same way that z2m does (“exposes”) otherwise every device would need to be quirked. The part of this that is in Zigpy may be handled in HA itself (or the web socket server) I started the beginning of this type of thing w/ sirens. We already expose several selects for things like alert tone, volume and strobe. The goal is to extend the support w/ number fields and additional selects, switches etc. tied directly to ZCL commands / attributes. Currently things look like this: core/select.py at cdd23abea7f8854d95c22a2dadeaffdbceeccc55 · home-assistant/core · GitHub Next we’ll tie these to ZCL commands for things like power on state etc.”
“My preference is to expose the most common functionalities (things like power on state, sensitivities, reset times, etc. Things that are used configurable w/ attributes writes or commands and are used by many users) via direct class definitions in ZHA / zha-websocket-server leveraging multi match so that we define them once and they just work for all devices (and for things that aren’t spec compliant we can continue to intercept the calls and translate as necessary in quirks). That said I am open to talking through alternatives.”
You have to restart home assistant again after updating to 2022.5 and you will see the setting on the device page. It works with ecosmart a19 and br30s.
