#Unable to turn on Zigbee lights if light switch manually turned on or off

1 messages · Page 1 of 1 (latest)

inner hare
#

I've recently setup a bunch of Aqara T2 lights under Zigbee and all work fine under the ZHA integration. I noticed however that if Home Assistant is unavailable, if I turn the light off at the switch then back on again a few seconds later, the light does NOT turn back on, which is a problem if Home Assistant goes unavailable at night and people in the house want to use the lights manually.

The Nanoleaf lights I replaced these with have this functionality, and I would expect this to be the same with all lights but appears not to be the case. Is this expected behaviour with Zigbee-configured lights?

#

I've also tested waiting up to half an hour with the same behaviour, so Home Assistant has come a single point of failure which is not ideal.

cinder jasper
#

I haven't used the T2 bulbs with zigbee, but under Matter they have a configuration entity for "Power on behaviour on startup". If that is set to "on", the bulb should turn on if you turn the bulb off then on at the switch. They might have a similar configuration available in zigbee mode?

#

the T2 bulbs default that setting to "Previous" (i.e. remember whether they were on/off last time they had power). The Nanoleaf bulbs default that setting on "On". But bulbs from both brands can run in either mode.

inner hare
#

I do recall that setting with the Nanoleaf lights, but that does not appear to exist with Zigbee:

#

vs a Nanoleaf Lightstrip, for example, which does have that option:

#

aaaaaand it appears it cannot be changed with Zigbee attributes 😦 that's disappointing:

cinder jasper
#

Zigbee protocols do support this - if the device supports it, ZHA will show a configuration entity for "startup behaviour"

#

so it must be the aqara firmware not exposing it in a standard way in zigbee mode :(

inner hare
#

the T2 has both a Zigbee and Thread radio, but only one works at a time (changeable via Bluetooth in the Aqara Home app). I do vaguely recall this start up behaviour being an option when it was in Thread configuration. will need to retest

cinder jasper
#

yes, i have some in thread mode and the setting is available.

inner hare
#

ah, right.. I won't need to test then lol

cinder jasper
#

it's possible that the setting is available in zigbee mode but only in a proprietary way (from the web page it looks like they allow configuring it via their hub?) if so, it might be possible to reverse-engineer it to add support for it in ZHA.

inner hare
#

yeah I avoided getting the hub as that's another one trick pony device that I didn't want. sigh

#

looks like Z2M device exposure for Aqara doesn't have this functionality either, but I guess that makes sense?

cinder jasper
#

yeah, if it was exposed via the standard attribute it would work with both.

#

fwiw, this is what the setting should look like in ZHA (this is on an IKEA bulb)

inner hare
#

right, thanks for that

#

and I can't migrate these lights to Thread either due a loooong issue that can't be resolved by the devs as the issue is not replicable, so I'm in somewhat of a pickle.

cinder jasper
#

that's kind of annoying; i dunno if i've been lucky or what but my thread network has been pretty stable (with the exception of some of the broken older firmware on the nanoleaf bulbs...)

inner hare
#

I removed all my Nanoleaf bulbs and replaced with these Aqaras as the performance was abysmal towards the end

#

I still have Eve Motion, Eve Energy, Aqara Door/Window and Meross Presence sensors on Matter/Thread (exception being Meross as it's Matter over WiFi) and they perform just fine

#

the Nanoleafs A19/A60s ruined everything

cinder jasper
#

If you do end up getting the aqara hub, one thing to note is that it works as a matter bridge (so you can use matter to connect to the bulbs from HA). I'd be curious to see if the power on behaviour attribute is available in that configuration. The downside of course is that it will create its own separate zigbee mesh :/

inner hare
#

yeah, and I have a SLZB-MR1 doing Zigbee/Thread radio mesh work and want to keep it that way

cinder jasper
#

huh, that's an interesting device. two radios in one physical device.

inner hare
#

yeah, it's pretty nifty

#

they released an MR3 recently (updated radio chips for both)

cinder jasper
#

I should note that people have run into stability problems when doing thread via a network-connected radio in the SLZB-06M due to issues with latency in the radio control protocol.

#

usb-connected radios have tended to be more stable

inner hare
inner hare
cinder jasper
#

(that did seem to be worse for people using HAOS in a virtual machine, and didn't affect everyone)

inner hare
#

yeah, I had my SkyConnect on a USB extension off an RPI4B and it didn't make a lick of difference if it was on separate hardware or a VM

#

I'm back on a VM as the OTBR addon has a bug in the RPI implementation that virtual tty devices do not exist, but do in the HAOS VM implementation, which is a requirement for the SLZB to function

cinder jasper
#

An interesting thing about the SLZB-06 type devices is that the ESP32 they use as the controller is powerful enough to run as a completely independent thread border router. I keep thinking I should order one of them and see if I can build a working firmware for that :)

inner hare
#

there's multiple flavours of SLZB units with different chips, so I'd expect some to perform slightly different to others

#

I had Zigbee on a SLZB-06 and Thread on a SLZB-06MG24

#

before migrating to the MR1

cinder jasper
inner hare
#

I still have the SLZB-06MG24 but don't currently have a use for it 🤷

cinder jasper
#

well, if i ever do build a TBR firmware for an SLZB-06 series device, i'll make a thread here. But it probably won't be any time soon :)

inner hare
#

back to the original topic; how would one request a dev to see whether the on-off component for these lights is even possible to reverse engineer?

cinder jasper
#

I'd probably start by downloading the device diagnostics, which should have a complete list of the clusters and attributes exposed by the device.

#

unfortunately, the "Works via Matter with Home Assistant" badge on the T2 box only covers Matter, not directly connecting to HA via Zigbee :/

#

ah, one thing i'm curious about - I have the T2 RGB bulbs, and I found that their color temperature is a bit redder (at the same configured value) than my other bulbs from nanoleaf, ikea, philips. Do you have the RGB bulbs or CCT-only T2 bulbs, and have you noticed anything like that?

inner hare
#

I have all RGB variant (18 E27 and 4 GU10) and they all seem to feel like the same colour temperature to me that the Nanoleaf lights had. I know they're slightly brighter (~1100 lumens vs 800), but when they are used in a colour capacity, I don't notice any colour distortion specifically.

cinder jasper
#

hmm, i guess maybe it's just me, or there's some variance in the bulbs.

inner hare
#

I did notice that when onboarding the lights, they do seem to be in two different hardware revisions though

cinder jasper
#

(I've got the E26 ones so it's probably a different batch from the E27 anyways)

inner hare
#

some of the models are identified as 'lumi.light.agl003 and others are lumi.light.agl005', if that makes a difference.

#

nope, nevermind

#

that's a fail on my part

#

005 are GU10, 003 are E27

#

🤦

cinder jasper
#

the way device ids work is different between zigbee vs matter, so i don't see any comparable ids. my devices say hardware revision "1.0.0.0".

#

you could try poking around for that in ZHA, it'll be cluster id 0xFCC0 and attribute id 0x0201

#

if that exists, you could try setting it manually (to 0 i think to set it to "false") and see if the behaviour changes.

inner hare
inner hare
inner hare
#

hmm, so I came across https://community.home-assistant.io/t/zigbee-guide-how-to-add-setup-local-custom-zha-device-handlers-also-known-as-quirks-in-the-zha-integration/683473 using the T1 entry in https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/xiaomi/aqara/light_acn.py#L40 and modified it based on the T2 signature differences, but doesn't seem to have made any difference after restarting HA 😦

https://pastebin.com/Rrzv6wXd

@cinder jasper any chance you can look at the above pastebin and see if this works on your T2s?

cinder jasper
#

You should be able to try manually setting that attribute from the ZHA Manage ZigBee device tool, if the attribute exists.

inner hare
#

0xFCC0 exists in the signature listing, but selecting it in the cluster brings up no options

cinder jasper
#

I'm not planning to switch my T2 bulbs to ZigBee, would be kinda disruptive to swap over from Matter/Thread.

inner hare
#

fair enough

cinder jasper
#

That's unfortunate, I dunno what that means. Maybe they don't use the same attribute :/

inner hare