HA 0.112.0 - Zigbee not working since update

Configuration Zigbee
1

Updated to 0.112.0 today. Previously both Zigbee and ZHA were working. Now neither are. I use the Conbee II stick and am running Hass.io in Docker on a Synology NAS.

Log Details (ERROR)

Logger: homeassistant.components.zha.core.gateway
Source: components/zha/core/gateway.py:147
Integration: Zigbee Home Automation (documentation, issues)
First occurred: 3:47:40 PM (7 occurrences)
Last logged: 3:51:54 PM

Couldn’t start deCONZ = dresden elektronik deCONZ protocol: ConBee I/II, RaspBee I/II coordinator

Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/serial/serialposix.py”, line 265, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: ‘/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2191790-if00’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py”, line 147, in async_initialize
app_config, auto_form=True, start_radio=True
File “/usr/local/lib/python3.7/site-packages/zigpy/application.py”, line 65, in new
await app.startup(auto_form)
File “/usr/local/lib/python3.7/site-packages/zigpy_deconz/zigbee/application.py”, line 58, in startup
await self._api.connect()
File “/usr/local/lib/python3.7/site-packages/zigpy_deconz/api.py”, line 229, in connect
self._uart = await zigpy_deconz.uart.connect(self._config, self)
File “/usr/local/lib/python3.7/site-packages/zigpy_deconz/uart.py”, line 140, in connect
xonxoff=False,
File “/usr/local/lib/python3.7/asyncio/coroutines.py”, line 120, in coro
res = func(*args, **kw)
File “/usr/local/lib/python3.7/site-packages/serial_asyncio/init.py”, line 410, in create_serial_connection
ser = serial.serial_for_url(*args, **kwargs)
File “/usr/local/lib/python3.7/site-packages/serial/init.py”, line 88, in serial_for_url
instance.open()
File “/usr/local/lib/python3.7/site-packages/serial/serialposix.py”, line 268, in open
raise SerialException(msg.errno, “could not open port {}: {}”.format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2191790-if00: [Errno 2] No such file or directory: ‘/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2191790-if00’

But in Supervisor - System - Hardware
serial:

/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2191790-if00
/dev/ttyS1
/dev/ttyACM1
/dev/ttyS3
/dev/ttyACM0
/dev/serial/by-id/usb-0658_USBDevice_ffffffd1ffffffb2ffffffdbffffffad-if00
/dev/ttyS0
/dev/ttyS2
2

Take stick out and in and that solved it for me.

1 Like
3

Thanks. Did you have same issue with Zwave too? I uses a Zooz stick for that and having the same problem. I have the sticks attached to the NAS. Always thought I had to power it down in order to do anything with the Zigbee/Zwave sticks but would be FAR easier to unplug ‘hot’

4

No for zwave I just restart container, no physical action needed.

5

No Zigbee errors in Logs anymore but every Zigbee entity has a big red exclamation circle in entities and is shown as unavailable in Lovelace dashboard

Meanwhile, Zwave network shows up but with same issue of unavailable entities. Tried healing network. In Logs, I get:
Logger: homeassistant.components.zwave
Source: components/zwave/init.py:476
Integration: Z-Wave (documentation, issues)
First occurred: 4:49:05 PM (6 occurrences)
Last logged: 4:49:05 PM

Z-Wave node 11 not ready after 30 seconds, continuing anyway
Z-Wave node 12 not ready after 30 seconds, continuing anyway
Z-Wave node 13 not ready after 30 seconds, continuing anyway
Z-Wave node 14 not ready after 30 seconds, continuing anyway
Z-Wave node 15 not ready after 30 seconds, continuing anyway
6

Rebooted Synology NAS…no difference

7

Zigbee devices are back. Not sure how/why. Had to turn off a Cree bulb and then back on to get it to work. A leak sensor in basement needed to have batteries removed and put back in. The plugged in items showed up after another HA restart.

Zwave still not showing

8

I’ve noticed that when this happens to my setup (Conbee II, Hassio on a Pi 4): the host machine needs to be fully rebooted - and when that’s done, HA needs to be restarted from within the interface.

I thought it was just my setup, but maybe not, either way it’s what works reliably for me after every update.

1 Like
9

What’s your homeassistant log telling you?

10

Just updated and having the same issues. My Zigbee devies are all not reachable. No errors in frontend logs, but on the console output I see the following error:

[zigpy_deconz.zigbee.application] Unexpected transmit confirm for request id 30, Status: TXStatus.NWK_ROUTE_DISCOVERY_FAILED
11

Hi

I do not think your issue has anything to do with 0.112

You have the problem setup where you both have a /dev/ttyACM0 and /dev/ttyACM1 and you use Deconz Addon.

You have defined the device as ‘/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2191790-if00’

That is not reliable in the Deconz addon´. I raised the bug several times and each time the bug was closed unresolved so I gave up. It is a matter of probability. Some may never see this. Some see it 50% of reboots.

If you use the /dev/ttyACM0 or 1 then it works - but only if the two devices are created in the right order. And you cannot be sure that Linux loads the two in the right order. That is why you should use the symlink method but it just does not work. If you only have one device that installs as ttyACM0 then you can just use this device and you never see the problem.

If you pull out the Conbee stick, boot, let the other USB stick load as ttyACM0, and wait, and then plug the Conbee, then you know it will be ttyACM1.

This is not a Deconz issue. It is the addon. My personal solution was to give up the addon and install Deconz outside the HA ecosystem using the native Dresden Elektronik method. You can do this on a different Raspberry if you want.

12

That may be part of the issue though I had so much trouble getting the Conbee II stick going that I am loathe to play with it.

Few points:

  1. This is on a Synology DS918+ NAS (not Pi)
  2. The issue occurred between a running HA version and the new 0.112 without a NAS reboot
  3. All Zigbee devices are now available after a repeat HA reboot and forcing some battery powered devices to wake
  4. Zwave went down at same time and those still show as unavailable - also battery powered (Dome water sensors) that I think will become available if I trigger them - today’s exercise.

So I think there was something with the update/DB rewrite that affected Zigbee/Zwave devices. I’m not a coder but maybe the polling of devices changed?

13

That sounds interesting, Kenneth. I do indeed have two devices as /dev/ttyACM0 and /dev/ttyACM1. Is there any more detail that you can provide? Like a link to the bug you filed or so? Trying to understand what exactly is going on.

You’re saying that using Deconz uses the by-id device path (which would allow it to reliably address the right USB stick as a Zigbee radio), but that using that device path is not reliable? Do you know why that doesn’t work reliablly?

If Deconz used the /dev/ttyACM0 path, then it would work reliably but depending on order of plugging in the devices and speed of discovery during boot-time, the Zigbee stick might end up as /dev/ttyACM0 or /dev/ttyACM1, which basically turns this into a big gamble on every host reboot or USB subsystem restart?

How does one even go about telling Deconz which device to use? I’m pretty sure I selected one when I installed the integration, but am not sure how to change it again now. Just manually updating it to the correct device path might be a temporary solution.

I also believe you can tell linux which device paths to use based on deviceUUIDs like serial numbers, etc. That way we might be able to permanently tie ttyACM0 and ttyACM1 to the same physical devices respectively.

14

I am a little bit confused though. I am pretty sure I am using ZHA as my Zigbee Integration, not Deconz. Or am I misunderstanding something here?

15

Did a little bit more digging. The serial device path is stored in config/.storage/core.config_entries. My Conbee II is pointing at /dev/ttyACM0 which is the same path that the by-id symlink points to and after some digging around in dmesg is almost certainly my Conbee II. So I don’t think that this is a case of wrong USB device being assigned the wrong device path - at least in my case.

I’ve also noted the following message in dmesg right after I replugged in my Conbee II:

cdc_acm 1-1.1.2:1.0: failed to set dtr/rts

I’ve one a little bit of googling but haven’t foundd anything for sure that could tell me if this might be a problem or not.

16

What I wrote is not relevant for ZHA.

17

Here’s what I did to get it working again. Note that this is more of a re-bootstrap instead of a recovery and if you have a large Zigbee network, this might not be viable for you.

  1. I uninstalled the Zigbee integration
  2. I shutdown HA
  3. I went into config and moved zigbee.db to zigbee.db.bak
  4. I went into config/.store and moved zha.storage to zha.storage.bak
  5. I unplugged a 2.4GHz WIFI router that sits close
  6. I unplugged the ZWave Controller I have in the same USB hub
  7. I restarte HA
  8. I re-added the Zigbee integration
  9. I repaired all of my Zigbee devices.

This fixed it for me and I can talk to my Zigbee devices again. I will need to go and rename all my entities / devices again to what they were before, but since I just recently started using HA + Zigbee and I only have a small test setup of devices it’s not too much effort.

Note that I do not believe the 2.4GHz router or the Zwave stick to have had a direct impact on this. I think a combination of wiping configuration and repairing the Zigbee devices was what fixed this for me. I will replug the Wifi router and the Zwave stick to confirm this. Also not sure if this will just suddenly break again at some point in the future. I somewhat suspect that maybe the HA upgrade messed up some of my Zigbee configuration somehow and fully bootstrapping it from scratch again resolved that. But this is just a random guess, I don’t actually know.

18

To update my post - Zigbee had worked by waking devices. Now the Zwave devices are back from ‘unavailable’ after 36 hours or so…

19

I also had the same issue and could not find a way to fix it…other than the same method @dev0 used (minus the WiFi stuff). I had to start from scratch. Luckily I only have 8 Zigbee devices so it didn’t take long.

20

I’m also getting NWK_ROUTE_DISCOVERY_FAILED when trying to do a RECONFIGURE on a device that is not responding.