core: zha not starting on 2021.7.2, Conbee II.

The problem

Since updating from 2021.6.6 zha is not starting on Raspberry pi 3b. Docker tag: raspberrypi3-homeassistant:2021.7.2. Before 2021.7 I didnt need to run the container privileged, but now it will not start without it. Don’t think this is causing the issue, but thought I might mention it anyway since I had to change it. I first thought it was related to issue #52777. But looks like this is different. Just say if you need anything else.

docker-compose

version: '3'
services:
  homeassistant:
    container_name: hassio
    image: homeassistant/raspberrypi3-homeassistant:2021.7.2
    volumes:
      # Local path where your home assistant config will be stored
      - /home/pi/docker/hassio:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped
    privileged: true
    network_mode: host
    depends_on:
      - mariadb
    devices:
      - /dev/ttyUSB-ConBeeII:/dev/ttyACM0
      - /dev/ttyUSB-ZStick-5G:/dev/ttyACM1

Tried setting mode 0666 on the stick aswell

These are my udev rules.

SUBSYSTEM=="tty", ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", SYMLINK+="ttyUSB-ConBeeII", MODE="0666"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="ttyUSB-ZStick-5G"

After running a separate deconz installation to update firmware on the stick deconz has added these udev rules aswell:

# ConBee II disbale modem manager and mtp probing
ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", ENV{MTP_NO_PROBE}="1"
# KERNEL=="ttyACM?", SUBSYSTEMS=="usb", DRIVERS=="usb", ACTION=="add", ATTRS{idVendor}=="1cf1", ATTRS{idProduct}=="0030", SYMLINK+="ttyConBee2", GROUP="dialout", MODE="0660"

What is version of Home Assistant Core has the issue?

2021.7.2

What was the last working version of Home Assistant Core?

2021.6.6

What type of installation are you running?

Home Assistant Container

Integration causing the issue

zha

Link to integration documentation on our website

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

Example YAML snippet

No response

Anything in the logs that might be useful for us?

2021-07-15 23:50:11 WARNING (MainThread) [zigpy_deconz.api] No response to 'Command.read_parameter' command with seq id '0x02'
2021-07-15 23:50:11 ERROR (MainThread) [zigpy.application] Couldn't start application
2021-07-15 23:50:11 ERROR (MainThread) [homeassistant.components.zha.core.gateway] 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 152, in async_initialize
    self.application_controller = await app_controller_cls.new(
  File "/usr/local/lib/python3.9/site-packages/zigpy/application.py", line 74, in new
    await app.startup(auto_form)
  File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/zigbee/application.py", line 66, in startup
    self.version = await self._api.version()
  File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/api.py", line 455, in version
    (self._proto_ver,) = await self[NetworkParameter.protocol_version]
  File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/api.py", line 420, 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 305, 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

cat .storage/core.config_entries

                "entry_id": "34f23d9a50b74b38b6247219c9abf2ca",
                "version": 2,
                "domain": "zha",
                "title": "ConBee II, s/n: DE2152142 - dresden elektronik ingenieurtechnik GmbH",
                "data": {
                    "device": {
                        "path": "/dev/ttyACM0"
                    },
                    "radio_type": "deconz"
                },
                "options": {},
                "pref_disable_new_entities": false,
                "pref_disable_polling": false,
                "source": "user",
                "unique_id": null,
                "disabled_by": null
            },

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (7 by maintainers)

Most upvoted comments

Ok, so thanks for all your help @Adminiuga, sorry if I wasted any of your time though. does not look like this was at all related to zigpy but an issue with running privileged docker container. I would probably have to bind mount the /dev folder instead to get symlinked containers in privileged. You may close this issue if you want to.

oppsig on Jul 16, 2021

Ok, I’ve gotten a bit further. I reverted to 2017.06.06, privileged = true, and were having basicly the same errors. Then removed the privileged flag and restarted. zigpy did complain about not finding /dev/ttyACM0 at first but then started and all zigbee devices were available. Remember in raspbian ConBee II were running on /dev/ttyACM1, while the ZStick were at /dev/ttyACM0.

So symlinks in raspbian: /dev/ttyACM1 -> /dev/ttyUSB-ConBeeII /dev/ttyACM0 -> /dev/ttyUSB-ZStick-5G

And then docker-compose mapped them like this: devices: - /dev/ttyUSB-ConBeeII:/dev/ttyACM0 - /dev/ttyUSB-ZStick-5G:/dev/ttyACM1

So this has been the way I have been running it all the time, and it has worked perfectly but not with privileged mode. And with release 2021.7+ I could no longer even start home assistant unprivileged.

So what I did then was just poweroff the pi, remove the ZStick so that it would not mount to /dev/ACM0. Then Conbee II would mount to /dev/ACM0 instead. I still kept the udev rules so Conbee II would still be available at /dev/ttyUSB-ConBeeII. And docker would in theory use /dev/ttyUSB-ConBeeII and map it to /dev/tty/ACM0 via devices in docker-compose no matter what /dev/tty/ACM* the stick was assigned to. But I then enabled priviliged mode again and started 2017.6.6 again. Everything is working fine in privileged mode now.

I kinda suspect there is something wrong going on when using symlinked device and running privileged. Privileged was exposing whole /dev and there might have been a conflict when dev in raspbian had zstick at /ttyACM0 and home assistant was expecting to find ConBeeII via /tty/ACM0 according to .storage/core.config_entries. So that was probably causing the conflict.

Upgraded to 2021.7.2 and 2021.7.3 working fine here aswell in privileged with ConBeeII in raspbian at /dev/tty/ACM0 with same udev rules. Compose kept the same, but I don’t think device mapping in there is doing much now that whole dev is exposed. Commented out Zstick because it is unplugged and docker was complaining.

    devices:
      - /dev/ttyUSB-ConBeeII:/dev/ttyACM0
      #- /dev/ttyUSB-ZStick-5G:/dev/ttyACM1

If I do: docker exec -ti hassio ls -al /dev/ttyACM0 The device is there and functioning.

But if i change to this:

    devices:
      - /dev/ttyUSB-ConBeeII:/dev/ttyUSB-ConBeeII
      #- /dev/ttyUSB-ZStick-5G:/dev/ttyACM1

Then only /dev/ACM0 is there inside the container, not the symlinked device.

Ok, so to sum up the issue. According to .storage/core.config_entries zigpy was expecting to find ConBeeII at /dev/ttyACM0 and that was working perfectly fine in unprivileged (2021.6.6). But when I could no longer start container in privileged mode from 2017.7+, and had to run privileged, privileged exposed whole /dev and because ZStick was in reality mounted at /dev/ACM0 in raspbian, zigpy was in reality finding the zstick at /dev/ACM0 instead because when in privileged symlinks doesn’t get exposed.

oppsig on Jul 16, 2021