Got this working with port “2” in the config.
Do we have any idea why this is an issue with Unraid (is it an issue with Unraid)? It wasn’t an issue for me to pass through the device using Proxmox previously.
I tried these solutions. I can see and select it when installing ZHA but it will still fail to connect.
Which value should I put in the xaml based of this:
You Legend, you!
Thank you. I saw your solution and did some further research, where others came up with a similar solution.
My situation was a bit different though as I don’t use Unraid, but rather Ubuntu Server.
I upgraded from Ubuntu 20.04.4 LTS to 22.04 LTS and was met with this problem.
I am using QEMU (Virtual Machine Manager for the GUI-focused people).
Before I was using USB pass-through and it worked like a dream.
I managed to get HA to detect the USB pass-through by removing and re-adding it to a USB3 controller, but HA kept giving me errors such as failed to connect when ever it tried to access the device. Logs stated errors about the device not responding to requests.
After days of struggle and research (as I wanted to stick with the USB pass-through solution if possible) I came across a post that said that others were having this issue due to a bug in libvert > version 6.6, which I suppose is one of the changes from the two LTS versions. Anyway, this is a widespread bug, so, USB pass-through seems like it just won’t work.
Using your example <serial> configuration, I copied your configuration by using virsh edit (vm_name_here) and pasting it under the other default <serial>...</serial>
entry. For those using Virtual Machine Manager, you would be able to copy-paste the <serial>...</serial> XML code in if you enable XML editing in the app preferences and try adding a serial device, then switching to the XML tab. Unfortunately, the GUI doesn’t make it easy to add in a pass-through serial device.
My <source path="..."> was a bit different,
<source path='/dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DXXXXXXXX-if00'/>
and I changed the usb port from “4” to “2” as others had. After a reboot of my host, HA now automatically detected the device.
Now, I had a different problem. HA still was expecting the device using the old path, which had now changed to the /dev/serial/by-id/usb-QEMU path. I tried to remove and re-add the integration, but all the entity ids were different. I had to restore to my most recent HA Core backup and then edit via SSH my config/.storage/core.config_entries file.
I replaced the path of the Conbee to the new one:
"data": {
"radio_type": "deconz",
"device": {
"path": "/dev/serial/by-id/usb-QEMU_QEMU_USB_SERIAL_1-0000:00:02.0-2-if00-port0"
}
},
I then restarted my host again (overkill maybe, but I wanted to be sure it all worked from scratch). Well, everything did work! All entity IDs remain the same, and all my integrations and automations seem to be working!
So, TLDR:
- Update virtual machine config with my specific path, and setting the port of the pass-through USB to 2 (perhaps optional)
- Edit HA core.config_entries file with the newly passed through serial device path as confirmed in HA SSH
- Reboot everything
Hope my struggles and this post will also help some people using Ubuntu or other QEMU solution.
2 Likes
Had the same issue. I got advice in the forum that if using USB manager plugin (which I do use), you can now change type of passing the device as serial mode.
https://forums.unraid.net/topic/100511-plugin-usb_manager/page/9/#comment-1147207
I changed that for my conbee stick, shut down VM, started it again. Then just changed path for device in Z2M from /dev/serial/by-id/conbeeXYZ to /dev/serial/by-id/qemuXYZ and that was it. All of my zigbee network continued to work.
Upgraded now to 6.10.3 without any issues.
2 Likes
I had this thread up and was looking for a solution for about 2 hours when you posted your comment. This is the most elegant solution so far and has worked for me.
For ZHA, you’ll have to make changes (within the VM terminal) to ~/config/.storage/core.config_entries
@curreta Could you help me out?
What changes do I have to do? - cant find the old HW menu in HA anymore to validate the USB path?
Go to Settings > System > Hardware > then to the three dot menu up top > All Hardware
That should show you the full list of everything Hass can see.
@casperse Personally I do not pass port but the device. Enable serial method on device (see screenshots I posted above). After that, shut down the VM and start it again. If you enabled auto-attach, it should attach automatically upon VM start.
Also if you have terminal (in web ui) or ssh to your HA, navigate to /dev/serial/by-id/ and do “ls”. Device should show up. That is the path and device name you need to change in ZHA config
hey, I hope it’s ok if I describe my problem here again, because it’s also about Unraid, Conbee and Zigbee2MQTT.
Unfortunately the solutions don’t work for me. I have rebuilt Home Assistant in Unraid as a VM. I passed the Conbee II stick to the VM via the USB Manager in Unraid as described. Unfortunately Zigbe2MQTT does not start.
I am surprised that ZHA works immediately and without problems. This means that the stick must be present in the Home Assistant?!
Today I also installed the latest firmware on the Conbee II stick. In addition, I have reinstalled Mosquitto broker and Zigbee2MQTT in Home Assistant. ZHA I had always uninstalled.
Attached are a few screenshots with my settings:
Home Assistant Hardware Infos (Settings → System → Hardware)
Zigbee2MQTT Settings in Home Assistant:
And i only get this Messages in the error log from Z2M:
[19:05:53] INFO: Handing over control to Zigbee2MQTT Core ...
Zigbee2MQTT:info 2022-09-23 19:05:55: Logging to console and directory: '/config/zigbee2mqtt/log/2022-09-23.19-05-55' filename: log.txt
Zigbee2MQTT:info 2022-09-23 19:05:55: Starting Zigbee2MQTT version 1.27.2 (commit #unknown)
Zigbee2MQTT:info 2022-09-23 19:05:55: Starting zigbee-herdsman (0.14.53)
Zigbee2MQTT:info 2022-09-23 19:05:55: zigbee-herdsman started (resumed)
Zigbee2MQTT:info 2022-09-23 19:05:55: Coordinator firmware version: '{"meta":{"maintrel":0,"majorrel":38,"minorrel":114,"product":0,"revision":"0x26720700","transportrev":0},"type":"ConBee2/RaspBee2"}'
Zigbee2MQTT:info 2022-09-23 19:05:55: Currently 0 devices are joined:
Zigbee2MQTT:info 2022-09-23 19:05:55: Zigbee: disabling joining new devices.
Zigbee2MQTT:info 2022-09-23 19:05:57: Connecting to MQTT server at mqtt://core-mosquitto
Zigbee2MQTT:error 2022-09-23 19:05:57: MQTT failed to connect: Connection refused: Not authorized
Zigbee2MQTT:error 2022-09-23 19:05:57: Exiting...
Zigbee2MQTT:info 2022-09-23 19:05:57: Stopping zigbee-herdsman...
Zigbee2MQTT:info 2022-09-23 19:05:58: Stopped zigbee-herdsman
Does anyone have an idea and can help me with my problem? I have already tried everything possible?
@Pixelpaule seems like it cannot connect to MQTT. I did not even get there when I had issue with 6.10.3
My mqtt portion of config only has:
base_topic: zigbee2mqtt
I am using mosqito broker as addon inside HA
I’m using ZHA, so I don’t know the details of setting up Z2mqtt, but you definitely need MQTT set up and connected. Did you create a user for Z2MQTT to use? Which guide did you follow to set this up?
Hey, thanks for your reply. I use this guide for setting up zigbee2mqtt, mosquitto broker and HA. How to Install Zigbee2MQTT in Home Assistant - TUTORIAL - NEW VERSION - YouTube
What do your Mqtt logs show?
Your settings?
Hey, this is the mosquitto log:
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/mosquitto.sh
[17:28:52] INFO: SSL is not enabled
cont-init: info: /etc/cont-init.d/mosquitto.sh exited 0
cont-init: info: running /etc/cont-init.d/nginx.sh
cont-init: info: /etc/cont-init.d/nginx.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun mosquitto (no readiness notification)
services-up: info: copying legacy longrun nginx (no readiness notification)
s6-rc: info: service legacy-services successfully started
[17:28:52] INFO: Starting NGINX for authentication handling...
[17:28:53] INFO: Starting mosquitto MQTT broker...
2022-09-24 17:28:53: Warning: Mosquitto should not be run as root/administrator.
2022-09-24 17:28:53: mosquitto version 2.0.11 starting
2022-09-24 17:28:53: Config loaded from /etc/mosquitto/mosquitto.conf.
2022-09-24 17:28:53: Loading plugin: /usr/share/mosquitto/go-auth.so
2022-09-24 17:28:53: ├── Username/password checking enabled.
2022-09-24 17:28:53: ├── TLS-PSK checking enabled.
2022-09-24 17:28:53: └── Extended authentication not enabled.
2022-09-24 17:28:53: Opening ipv4 listen socket on port 1883.
2022-09-24 17:28:53: Opening ipv6 listen socket on port 1883.
2022-09-24 17:28:53: Opening websockets listen socket on port 1884.
2022-09-24 17:28:53: mosquitto version 2.0.11 running
2022-09-24 17:28:53: New connection from 172.30.33.3:56134 on port 1883.
error: received null username or password for unpwd check
[17:28:54] INFO: Successfully send discovery information to Home Assistant.
[17:28:54] INFO: Successfully send service information to the Supervisor.
2022-09-24 17:28:53: Client <unknown> disconnected, not authorised.
2022-09-24 17:28:53: New connection from 127.0.0.1:51320 on port 1883.
2022-09-24 17:28:53: Client <unknown> closed its connection.
2022-09-24 17:28:57: New connection from 172.30.33.3:50222 on port 1883.
error: received null username or password for unpwd check
2022-09-24 17:28:57: Client <unknown> disconnected, not authorised.
2022-09-24 17:28:58: New connection from 172.30.33.3:50228 on port 1883.
error: received null username or password for unpwd check
2022-09-24 17:28:58: Client <unknown> disconnected, not authorised.
2022-09-24 17:29:00: New connection from 172.30.32.1:57609 on port 1883.
2022-09-24 17:29:00: New client connected from 172.30.32.1:57609 as 7EbXvFLCqpMglodU1Srrqr (p2, c1, k60, u'homeassistant').
2022-09-24 17:29:03: New connection from 172.30.33.3:50230 on port 1883.
error: received null username or password for unpwd check
These are my configs in mqtt:
EDIT:
Okay, it works… It was a mistake in the configuration. In the first YouTube tutorial, the YouTuber did not specify a username or password in the Z2M configuration. (5) How to Install Zigbee2MQTT in Home Assistant - TUTORIAL - NEW VERSION - YouTube
In the updated version he does! So I had to put only the data from the mqtt-user in the configuration of Z2M! (5) How to Install Zigbee2MQTT with the Sonoff ZBDongle E in Home Assistant - Tutorial - YouTube
Now it seems to work!
1 Like
I tried to set up Home Assistant and the Conbee for the first time yesterday… this solved my issues so quickly!
Thanks!
1 Like
My f***en GOD! If only I’d found this like 6 hours ago. Idk who you are, idk what you want but you diserve a cookie! After 2 years lurking on the pages of this community this was it, this was the time for me to do an account and actually write something. Thank you man!
1 Like
Is this still a required workaround for the latest versions of unraid 6.11.x?
Was hoping to avoid it, but think it’s time to upgrade.
For reference, still have to edit the XML, the passthrough of the USB device still not working in 6.11.5
I have moved from ZHA to ZigbeeMQTT. I had a number of issues using the Conbee stick with ZHA (namely that it would take a while to start it back up everytime I wanted to reload HASS) and the lag when changing light brightness. This lead me to decide to make the switch. I installed the ZigbeeMQTT docker on unraid and passed the Conbee stick. Everything has been working pretty great so far. The only issue I have experienced is that I need to re-start the container sometimes as it stops randomly. I haven’t investigated it, but shoddily “fixed” it with the following command:
--restart unless-stopped
Might be worth considering Z2MQTT for others if they’re having issues!
Having the same problem but with proxmox instead.
I don’t think this fix will apply ?
If not, I’ll keep looking for a similar solution for a proxmox VM