#Has something changed with adding a Zigbee device (with ZHA) recently?

1 messages · Page 1 of 1 (latest)

tropic eagle
#

I'm tearing my hair out here. I have two garage TS0203 door sensors. They both had gone offline due to flat batteries. During this time I upgraded to HA 2024.9.3

I replaced the battery in one sensor, then re-added it back in using add device in the UI. All went well. The second door sensor, I tried the same, but, after pairing it quickly showed as unavailable. I have tried multiple times to add this device back in, I've tried another identtical sensor with the same result every time. After the interview/configuring is completed, sometimes the sensor works for a few minutes, other times it just shows as unavailable. I have battery device timeout set to something like 79999 seconds.

The only clue I can find in the logs so far is this: https://pastebin.com/cbWAc43Z

Any idea what's going on?

Pastebin
zha - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

tropic eagle
#

Oh, it looks like there are several related/similar issues reported in github for version 2024.9.x
I'm going to try downgrading to 2024.8.something

tropic eagle
#

2024.8.3 not working for me either, I'm going back to 2024.6.4 which is where I started from this morning.

#

I've given up for now, cannot get this one sensor to work.

elder grail
#

how many devices are on the network? and how many of them are routers?

tropic eagle
#

32/11

It's really weird. When I try to re-pair this device - it seems to go into some kind of loop. the interview completes, then I get the green popup to change the name/area, then it pops up another configuring box which never finishes.

tropic eagle
#

753 attempts later and it seems to be working. Even though the repeater is just on the other side of the room it seems to be marginal whether it will connect or not.

restive light
#

Sounds like a faulty device to me. It does happen.

tropic eagle
#

I tried two devices with the same result. I think it was just insufficiient signal. I was using an IKEA bulb as a router but it's in an anglepoise (metal shade). I changed the angle of the shade slightly and that seemed to do the trick. I am just waiting for a new router to arrive to use instead of the bulb.

tropic eagle
#

ok this is still driving me crazy. I have other devices that pair with a router just a few cm away, then immediately their entities become unavailable. I can see some errors in the log eg:

Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:147
First occurred: 10:59:03 (6 occurrences)
Last logged: 11:29:30

Error doing job: Exception in callback Gateway.device_initialized.<locals>.<lambda>(<Task finishe...> result=None>) at /usr/local/lib/python3.12/site-packages/zha/application/gateway.py:455 (None)
Error doing job: Exception in callback Gateway.device_initialized.<locals>.<lambda>(<Task finishe...ILED: 3074>')>) at /usr/local/lib/python3.12/site-packages/zha/application/gateway.py:455 (None)
Traceback (most recent call last):
File "/usr/local/lib/python3.12/asyncio/events.py", line 88, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.12/site-packages/zha/application/gateway.py", line 455, in <lambda>
init_task.add_done_callback(lambda _: self._device_init_tasks.pop(device.ieee))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: xx:xx:xx:xx:xx:xx:xx

Is there something obvious going on?

tropic eagle
#

I'm right at the point of giving up with ZHA 😦

young shuttle
#

Tuya devices are known to be not good

#

Try another brand

tropic eagle
#

I have many of these door sensors and they have all been working fine. Suddenly more than one of them have stopped working.

restive light
#

That happens often with Tuya devices. They'll be fine for a while and then go to crap seemingly overnight. We've seen this happen many, many, MANY times before.

tropic eagle
#

I have a bunch them working just fine in another place using zigbee2mqtt.

elder grail
#

Put ZHA in pairing mode and then reset the sensor

tropic eagle
#

Yes this exactly. I have tried this (re-pairing) multiple times and for some reason it's not working. The device successfully pairs, then very shortly after its entities become unavailable.

elder grail
#

My guess is it is leaving the network

#

Do it again and after resetting it push the button on it every second or so to keep it awake

tropic eagle
#

I did also try that but I will try again. The router its connecting to is super close.

elder grail
#

Maybe the table space in the router is full

#

Pair it to something else

tropic eagle
#

I don't think there's anything else connected to that router. I will try again shortly and let it choose its own router (that's always worked before, I was trying to eliminate signal problems)

tropic eagle
#

frequently clicking the setup button during thr interview/configuring seems to have worked. I've never had to do that before - is there something slowing down the process?

elder grail
#

No, pressing the button keeps the device awake so it responds to commands

#

Lots of battery powered devices sleep very quickly

#

That said… if you have misbehaving custom components it is possible

tropic eagle
#

Nope still can't get the sensor in the second location to setup correctly. What happens is this:

  1. long press reset button until light flashes
  2. Interview starts, light continues to flash
  3. Configuring starts, light continues to flash
  4. I'm able to name the device and set it's area (light continues to flash)
  5. it loops around to step 2, light continues to flash
  6. sometimes loops to step 2 again, then light stops flashing
  7. device shows up in HA, but its 2 sensors are both unavailable

I've tried this with two devices, exactly the same behaviour with both.

elder grail
#

Pull the log, zip it and attach it here. I bet there are references to the device leaving the network. If anything we may be addressing it too fast… I have seen artificial sleep code in z2m specifically for Tuya…

#

Also, as others have mentioned, in the long run you are better off w/ non Tuya devices

restive light
tropic eagle
#

Ok I'll get the log shortly. Fyi, I've just setup Z2M to test it and it works perfectly. This all used to work fine in ZHA as well.

tropic eagle
#

log = home-assitant.log? I tried to get the zigbee diagnostics but failed. There are no secrets in HA log, right?

tropic eagle
elder grail
#

Right, see above… there is actually an explicit comment about this exact case in their source

#

So we need to do something similar to account for bad device firmware

# 
2024-10-08 16:30:43.922 DEBUG (MainThread) [bellows.ezsp.protocol] Received command childJoinHandler: {'index': 0, 'joining': <Bool.false: 0>, 'childId': 0x3D59, 'childEui64': a4:c1:38:84:32:38:9f:63, 'childType': <EmberNodeType.SLEEPY_END_DEVICE: 4>}
2024-10-08 16:30:43.922 DEBUG (MainThread) [bellows.zigbee.application] Received childJoinHandler frame with [0, <Bool.false: 0>, 0x3D59, a4:c1:38:84:32:38:9f:63, <EmberNodeType.SLEEPY_END_DEVICE: 4>]
2024-10-08 16:30:43.923 DEBUG (MainThread) [bellows.ezsp.protocol] Received command trustCenterJoinHandler: {'newNodeId': 0x3D59, 'newNodeEui64': a4:c1:38:84:32:38:9f:63, 'status': <EmberDeviceUpdate.DEVICE_LEFT: 2>, 'policyDecision': <EmberJoinDecision.NO_ACTION: 3>, 'parentOfNewNodeId': 0xFFFF}
2024-10-08 16:30:43.923 DEBUG (MainThread) [bellows.zigbee.application] Received trustCenterJoinHandler frame with [0x3D59, a4:c1:38:84:32:38:9f:63, <EmberDeviceUpdate.DEVICE_LEFT: 2>, <EmberJoinDecision.NO_ACTION: 3>, 0xFFFF]
#

Search your log for deviceleft… it’s happening a lot

tropic eagle
#

Thanks. What's weird is I thought all my door sensors were the same - it turns out I have a mixture of Sonoff and Tuya - but up until recently the Tuya ons have been behaving well in ZHA