Zigbee Home Automation - RaspBee II doesn't work after HA OS 8.0 upgrade

[pes001]

The problem

Hi, I updated today my HA on OS 8.0 and 2022.5.4 core and Raspbee II device and Zigbee integration doesn't work since the upgrade. Any suggestions?

Thanks, Petr

What version of Home Assistant Core has the issue?

2022.5.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Zigbee Home Automation

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zha

Diagnostics information

How to get diagnostic file?

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Messages from log:
Logger: homeassistant.config_entries
Source: config_entries.py:366
First occurred: 16:48:00 (1 occurrences)
Last logged: 16:48:00

Config entry '/dev/ttyS0' for zha integration not ready yet; Retrying in background

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/connection.py:96
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 17:06:34 (4 occurrences)
Last logged: 17:06:41

[547224274928] Received invalid command: zha/configuration
[547224274928] Received invalid command: zha/groups
[547224274928] Received invalid command: zha/devices

Logger: homeassistant.components.zha.core.gateway
Source: components/zha/core/gateway.py:182
Integration: Zigbee Home Automation (documentation, issues)
First occurred: 16:48:00 (21 occurrences)
Last logged: 17:07:13

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.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 182, in async_initialize
    self.application_controller = await app_controller_cls.new(
  File "/usr/local/lib/python3.9/site-packages/zigpy/application.py", line 69, in new
    await app.startup(auto_form)
  File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/zigbee/application.py", line 84, in startup
    self.version = await self._api.version()
  File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/api.py", line 464, in version
    (self._proto_ver,) = await self[NetworkParameter.protocol_version]
  File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/api.py", line 429, in read_parameter
    r = await self._command(Command.read_parameter, 1 + len(data), param, data)
  File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/api.py", line 314, in _command
    return await asyncio.wait_for(fut, timeout=COMMAND_TIMEOUT)
  File "/usr/local/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

Additional information

No response

[probot-home-assistant[bot]]

Hey there @dmulcahey, @adminiuga, mind taking a look at this issue as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

---

zha documentation zha source _{^{(message by IssueLinks)}}

[Adminiuga]

Power cycle raspBee. Make sure the configuration to expose the serial port on GPIO header is still in place.

[Thom402]

Had the same issue. For me it worked by changing the device in the deCONZ app-configuration.

[kusmi]

Had the same issue. For me it worked by changing the device in the deCONZ app-configuration.

How did you do that?

[mhl66]

Had the same issue. For me it worked by changing the device in the deCONZ app-configuration.

In other words: what is "the deCONZ app-configuration", since PHOSCON isn ´t installed!? I´m relying on ZHA only...

[Thom402]

ah, sorry i missed that

[mhl66]

Power cycle raspBee. Make sure the configuration to expose the serial port on GPIO header is still in place.

Sorry, power cycle don´t work. The "configuration to expose" IS in place:

enable_uart=1
dtoverlay=pi3-disable-bt

[mhl66]

NB: After reverting to Hassio 7 Build 6 from haos_rpi4-64-7.6.img.xz, ZHA works flawlessly with Raspbee II.

[Adminiuga]

If Hass OS downgrade works while keeping Core at 2022.5.4, then something might have changed at the os level. And there were no changes in the zigpy_deconz since the last update.

What serial ports the hardware tab reports? Try also asking in Hass is repo about this issue.

[mhl66]

Obviously "something might have changed at the os level"... /dev/ttyS0 is shown for "ls /dev/tty*", but no connection is made. See OP log above.

What do you mean with "hardware tab"? .../config/hardware reports only this:

Raspberry Pi 4 rpi4-64

[pes001]

It's definitely at the OS level because I restored the HA core to the previous version 2022.5.3 and the situation remains the same. How can I downgrade HA OS?

[mhl66]

Simply get the Hassio image called "haos_rpi4-64-7.6.img.xz" from the official download page ("releases"): https://github.com/home-assistant/operating-system/releases/, flash it to the SD card, and after initial setup, restore the last backup.

[NAP141]

Hi all, same exact issue. Unfortunately, I am far away from my device. Unable to downgrade remotely. Please help resolving, I lost all zigbee devices

[NAP141]

If it helps, my error log is exactly the same as pes001. I am on Raspberry Pi3 and in System / Hardware / All Hardware

I see the following:

Drop Down ttyAMA0

Subsystem: tty Device path: /dev/ttyAMA0 Attributes: DEVLINKS: /dev/serial0 DEVNAME: /dev/ttyAMA0 DEVPATH: /devices/platform/soc/3f201000.serial/tty/ttyAMA0 MAJOR: '204' MINOR: '64' SUBSYSTEM: tty TAGS: ':systemd:' USEC_INITIALIZED: '7806671'

Drop down tyS0

Subsystem: tty Device path: /dev/ttyS0 Attributes: DEVLINKS: /dev/serial1 DEVNAME: /dev/ttyS0 DEVPATH: /devices/platform/soc/3f215040.serial/tty/ttyS0 MAJOR: '4' MINOR: '64' SUBSYSTEM: tty TAGS: ':systemd:' USEC_INITIALIZED: '7826601'

[cahaverl]

I also had this problem. In my case the root cause was the serial ports for my Zigbee and ZWave USB dongles got switched.

I was using the invariant device name for my Zigbee controller (ConBee II), so after the upgrade to HA OS 8.0 I had

• Zigbee at /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2499961-if00
• Zigbee aka /dev/ttyACM0
• ZWave configured to /dev/ttyACM0

Before the upgrade, the invariant Zigbee name was mapped to /dev/ttyACM1.

With both protocols trying to use the same port, Zigbee and ZWave both didn't work.

I was able to fix Zigbee by reconfiguring the port used by Z-Wave JS to MQTT. I pasted in the invariant name for the ZWave controller, which for me is /dev/serial/by-id/usb-0658_0200-if00 . For details of where to do this, see [here](https://help.aeotec.com/support/solutions/articles/6000246297-setup-home-assistant-with-z-stick-gen5-#:~:text=Click%20Zwave-,Click%20Serial%20port%20and%20select%20/dev/ttyACM0,-\(Newly%20updated%2C%20this), though note that the instructions recommend using a raw device name, which would likely cause this issue to recur.

To see the device names in all their glory, go to Settings > System > Hardware > 3 Dots Menu > All Hardware

[panhans]

Hi, same issue here. With rasbee 1 and rpi4. But it worked for me the first time. I was so stupid to tried out deconz and upgraded the firmware of the raspbee. After deinstalling it again and a restart I ran in this issue here.

[NAP141]

Any suggestions how to fix the issue? Since I cannot roll back (being remote), i do not know what I had. Given the error HA is looking for /dev/ttyS0. Should I try and reconfigure it to look for /dev/ttyAMA0? if so how? As mention above I am remote and cannot do anything other than what is possible through the web interface.

[Oderik]

@NAP141, the comment above solved it for me. I configured the Zigbee integration to use "the other" serial device (now ttyAMA0). Worked for both ZHA and Deconz.

For ZHA, remove the integration and add it again.

For Deconz, go to Add-Ons -> deCONZ -> Configuration and select the correct device.

[mhl66]

@NAP141, the comment above solved it for me. I configured the Zigbee integration to use "the other" serial device (now ttyAMA0). Worked for both ZHA and Deconz.

For ZHA, remove the integration and add it again.

For Deconz, go to Add-Ons -> deCONZ -> Configuration and select the correct device.

...not for me, though; see above: https://github.com/home-assistant/core/issues/71950#issuecomment-1128182180

After removing and adding the ZHA integration again, the setup offered /dev/ttyAMA0 as default, but no connection can be made. /dev/ttyS0 was shown as device, but also resulted in no connection. Downgrading to hassio 7.6 instantly solves this problem (see above).

@cahaverl With hassio, there is no "invariant device name": /dev/serial is simply empty...

[NAP141]

@mhl66 I was able to solve it. After removing ZHA and tried to add it back it did not work. But I then did full reboot and it did find it under /dev/ttyAMA0. Although all my Zigbee devices did show, I lost the names I gave them but that is okay I will rename them again to what they used to be.

[raidnet-ms]

Same problem here. I will stay tuned.

[Adminiuga]

Open this issue in HassOS repository. If the problem is fixed with the HassOS downgrade then the core is not the root cause.

[prigal]

Same issue here, downgrading to 7.6 in progress.

[NAP141]

I resolved the issue without downgrading.

1. Delete ZHA integration
2. Hardware reboot
3. Add ZHA integration Note: all ZigBee devices are back online but I lost Device and Entity renaming. I had to rename them again to what they were. If this works for you no need to downgrade.

[Adminiuga]

Whelp, if changing the serial port works, then the new Hass must have changed the port naming.

[Ryloguy]

Can confirm that my serial port changed after updating my installation. I changed the port for my raspbee in /config/.storage/core.config_entries. My rasbpee is working again without having to rename any entities. If you can't see the .storage folder, make sure it is not in the blacklist in the File Editor configuration under Add-Ons. After changing the port, reboot your host and your raspbee should be working again. Hope this helps! :)

Note: Restarting the core didn't work for me. You will need to reboot the host.

[panhans]

Can someone share the /boot/config.txt for the pi4. I edit some entries in order to solve this problem but I think I broke something now. :\

Thanks in advance!

[chrismazanec]

I was thinking if the old bluetooth disable option has not been deprecated with the new OS/kernel?

dtoverlay=pi3-disable-bt -> dtoverlay=disable-bt

perhaps worth trying, dtoverlay=disable-bt works well with HA OS 8.0, RaspBee 2 and RPI4 for me

[panhans]

The config.txt of the rasbian provided by dresden electronics says:

dtoverlay=pi3-miniuart-bt-overlay
enable_uart=1

So, I am a little confused.

My pi doesnt boot up anymore. I'll get no access with ssh & debug port and I've lost my micro-hdmi cable. Now waiting for a new one.

//EDIT:

ok. i've had a look in the overlay. you can choose between disable-bt or miniuart-bt

[Zipp0KMS]

Can confirm that my serial port changed after updating my installation. I changed the port for my raspbee in /config/.storage/core.config_entries. My rasbpee is working again without having to rename any entities. If you can't see the .storage folder, make sure it is not in the blacklist in the File Editor configuration under Add-Ons. After changing the port, reboot your host and your raspbee should be working again. Hope this helps! :)

Note: Restarting the core didn't work for me. You will need to reboot the host.

which line did you change? what did you enter? the config_entries confuses me

[Ryloguy]

config_entries raspbee

As far as I can tell the config_entries file is basically a record of all devices and where to find them. If you scroll down you should be able to find the entry for the raspbee as seen above. The main line you need to change is the "path:" string, however, I also changed my "title:" string for consistency sake. The title is what is shown in the interface throughout home assistant.

[Adminiuga]

What Ryloguy said!

[Zipp0KMS]

OK. I changed the path from "/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_XXXX" to "/dev/ttyACM0". Unfortunately, only the battery devices are still displayed. Sockets and lamps are not available.

[Ryloguy]

OK. I changed the path from "/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_XXXX" to "/dev/ttyACM0". Unfortunately, only the battery devices are still displayed. Sockets and lamps are not available.

For me it took a while for some devices to reconnect. I either had to wait for them to reconnect on their own or manually wake or restart then for them to become available in Home Assistant again. I was able to get my raspbee fixed last night and by this morning everything was reconnected and working as normal.

[PR-UK]

Doesn't seem to work for me, if I rename the entry to \dev\ttyACM0 and restart the host the device disappears altogether, if I perform a cold-boot then it appears but the entry in core.config_entries is, after a few minutes, renamed back to its full name.

[panhans]

I flashed dresden electronics raspbian on a seperate sdcard. Updated the firmware of my raspbee and a conbee II of a friend of mine and voir la it worked again.

params in config.txt for raspbee:

dtoverlay=miniuart-bt
enable_uart=1

[Zipp0KMS]

OK. I changed the path from "/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_XXXX" to "/dev/ttyACM0". Unfortunately, only the battery devices are still displayed. Sockets and lamps are not available.

For me it took a while for some devices to reconnect. I either had to wait for them to reconnect on their own or manually wake or restart then for them to become available in Home Assistant again. I was able to get my raspbee fixed last night and by this morning everything was reconnected and working as normal.

This morning I shut down the Rasp Pi again. After the reboot there was no change. However, all devices are now available again. Thanks for the help! I hope there will be no more failures.

[Zipp0KMS]

However, I get the following error:

Logger: homeassistant.components.zha.core.channels.base Source: components/zha/core/channels/base.py:474 Integration: Zigbee Home Automation (documentation, issues) First occurred: 08:45:26 (5 occurrences) Last logged: 08:46:12

[0xF369:1:0x0008]: async_initialize: all attempts have failed: [DeliveryError('[0xf369:1:0x0008]: Message send failure'), DeliveryError('[0xf369:1:0x0008]: Message send failure'), DeliveryError('[0xf369:1:0x0008]: Message send failure'), DeliveryError('[0xf369:1:0x0008]: Message send failure')] [0x9192:1:0x0008]: async_initialize: all attempts have failed: [DeliveryError('[0x9192:1:0x0008]: Message send failure'), DeliveryError('[0x9192:1:0x0008]: Message send failure'), DeliveryError('[0x9192:1:0x0008]: Message send failure'), DeliveryError('[0x9192:1:0x0008]: Message send failure')] [0x0000:1:0x0006]: async_initialize: all attempts have failed: [TimeoutError(), TimeoutError(), TimeoutError(), TimeoutError()] [0xF369:1:0x0006]: async_initialize: all attempts have failed: [DeliveryError('[0xf369:1:0x0006]: Message send failure'), DeliveryError('[0xf369:1:0x0006]: Message send failure'), DeliveryError('[0xf369:1:0x0006]: Message send failure'), DeliveryError('[0xf369:1:0x0006]: Message send failure')] [0x9192:1:0x0006]: async_initialize: all attempts have failed: [DeliveryError('[0x9192:1:0x0006]: Message send failure'), DeliveryError('[0x9192:1:0x0006]: Message send failure'), DeliveryError('[0x9192:1:0x0006]: Message send failure'), DeliveryError('[0x9192:1:0x0006]: Message send failure')]

[pes001]

I resolved my issue by reinstalling ZHA integration as @NAP141 wrote. Unfortunately I had to configure all my zigbee devices and entities again - 2hrs spent. I have another instance of HA at another house where I'd like just to edit /config/.storage/core.config_entries file but I can't see .storage folder. Where can I find the blacklist @Ryloguy mentioned or how to reach the file? How to avoid this during the next upgrade?

[mbrennan]

I am having this issue as well. Downgrading to HassOS 7.6 did not resolve the problem.

[Zipp0KMS]

I resolved my issue by reinstalling ZHA integration as @NAP141 wrote. Unfortunately I had to configure all my zigbee devices and entities again - 2hrs spent. I have another instance of HA at another house where I'd like just to edit /config/.storage/core.config_entries file but I can't see .storage folder. Where can I find the blacklist @Ryloguy mentioned or how to reach the file? How to avoid this during the next upgrade?

You can choose the blacklist folders in the file editor config under Adons.

[agners]

The config.txt of the rasbian provided by dresden electronics says:

dtoverlay=pi3-miniuart-bt-overlay
enable_uart=1

So, I am a little confused.

The pi3- prefixed overlays have been removed long time ago (see https://github.com/raspberrypi/linux/commit/e8d411fb2e9a40fa6f3988334221371fe4620a75). In theory, this should have stopped working in 7.x already. If rpi3- prefixed overlays did work, then it was maybe some work around Raspberry Pi had in the firmware, I am not sure.

In any case, please remove this prefix. For those using RaspBee II, it's likely that this prefix prevented the overlay from being applied correctly, which leads to a different device name for the RaspBee II.

[mbrennan]

Are the device pairings associated with the Raspbee II device itself? If we remove the ZHA integration, then do you have to repair all the Zigbee devices? I don't want to repair 40 devices...

[Thom402]

The config.txt of the rasbian provided by dresden electronics says:

dtoverlay=pi3-miniuart-bt-overlay
enable_uart=1

So, I am a little confused.

The pi3- prefixed overlays have been removed long time ago (see raspberrypi/linux@e8d411f). In theory, this should have stopped working in 7.x already. If rpi3- prefixed overlays did work, then it was maybe some work around Raspberry Pi had in the firmware, I am not sure.

In any case, please remove this prefix. For those using RaspBee II, it's likely that this prefix prevented the overlay from being applied correctly, which leads to a different device name for the RaspBee II.

This worked for me. Thank you very much. :)

[CraigComberbach]

For those that follow in our footsteps here is the specific steps I took for my setup (RPi 4):

• Open the config file. I accessed the card directly and changed it using a Windows machine, presumably you can change it by SSHing in
• Change the file as per below

  enable_uart=1 dtoverlay=pi3-miniuart-bt-overlay

• Presumably you will need to powercycle it (mine was as a natural consequence of how I did it)

In my case dtoverlay was the only thing needing to be changed. Thanks to everyone above that did all the hard work and figured out what I needed to do.

[mbrennan]

For those that follow in our footsteps here is the specific steps I took for my setup (RPi 4): Open the config file. I accessed the card directly and changed it using a Windows machine, presumably you can change it > by SSHing in Change the file as per below enable_uart=1 dtoverlay=pi3-miniuart-bt-overlay

I don't think that's right. As what @agners wrote above:

The pi3- prefixed overlays have been removed long time ago (see raspberrypi/linux@e8d411f). In theory, this should have stopped working in 7.x already. If rpi3- prefixed overlays did work, then it was maybe some work around Raspberry Pi had in the firmware, I am not sure.

[Ryloguy]

I don't think you would be able to change it by SSHing into the Pi as it is on a different partition than the OS. For the record I was able to get mine working without changing the flags so I don't think that's necessary.

[mhl66]

Back to business: Solved for me by appending the following lines to config.txt in root partition (via Windows PC):

enable_uart=1
dtoverlay=disable-bt

After reboot, change "/dev/ttyS0" to "/dev/ttyAMA0" in /config/.storage/core.config_entries (used Studio Code Server plugin with disabled ".storage"-exclusion via settings):

                "data": {
                    "device": {
                        "path": "/dev/ttyAMA0"
                    },
                    "radio_type": "deconz"
                },

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.