I’m not familiar with that docker run command but this:
--device=/dev/zwaveStick
isn’t the same as the label you gave the stick in the UDEV rules above.
Also just as a double check does the zstick show up in the Supervisor->System->Host->hardware list?
What system are you running HAOS or HA Supervised?
This is a docker run option to directly expose/pass the host device to the docker container.
https://docs.docker.com/engine/reference/commandline/run/#add-host-device-to-container—device
And you are correct sir, it isn’t the same. Sorry for the confusion. As I continued to troubleshoot the issue, I shortened the name in my UDEV rules to create a static symlinked mapping to the USB device, and in my configuration.yaml file. I also removed the OpenZWave (beta) add-on at the suggestion of @silvrr.
It does not show up in my Hardware list in Supervisor -> System -> Host -> Hardware
I’m running Supervisord and just upgraded to core-2021.1.4 at the behest of the Security Bulletin advisory… which is what broke my system.
udev rule
SUBSYSTEM=="tty", ATTRS{idVendor}=="0658", ATTRS{idProduct}=="0200", SYMLINK+="zwaveStick"
...
zwave:
debug: true
usb_path: /dev/zwaveStick
network_key: !secret zwave_network_key
...
services-admin@ubuntu: ~/DockerServices$ lsusb
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 1a86:e024 QinHeng Electronics
Bus 001 Device 003: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Have you tried setting your zwave configuration to using the default persistent path? I didn’t think Supervisor allowed arbitrary udev symlink paths, so I’m surprised it ever worked. It does explicitly allow /dev/serial/by-id symlinks.
zwave:
debug: true
usb_path: /dev/serial/by-id/usb-0658_0200-if00
network_key: !secret zwave_network_key
Exact same issue here. Running the OVA version of HAOS in VMWare Fusion on a Mac Pro.
As of the last supervisor update, the USB Z-wave controller is no longer getting passed in to the core container on startup. I also did most of the troubleshooting mentioned above, to no avail. My workaround has been to physically unplug/replug the device, which causes it to show up in the Supervisor, then restart the core. That works for a bit, but it will typically fail within a day.
What are all the hardware options listed there?
No, I had not. I do know that you can explicitly pass host devices to a container where the container doesn’t use the --privileged run option. In this case the hassio-supervisor run script does use the --privileged option in the run command and therefore gives elevated privileges to access the host’s hardware. Since the device was not showing up in my HA Hardware list, I added the option to the startup script, but no worky.
I used the UDEV Rules prior to statically map the USB device and that worked fine. I did so in my case because I was also seeing posts regarding issues with the Wyze Hub, which I also have. So the UDEV Rules route resolved any issues around either of the USB devices and it was working fine.
I looked for /dev/serial/by-id devices and I have a /dev/serial but no by-id. A Google search revealed that others have reported no /dev/serial/by-id. A review of the kernel documentation seems to indicate that this is because the Aeontec isn’t a recognized device having a driver built into the kernel. Another post suggested:
In general, lsusb tells you the hardware is there. This is the low level view.
Showing up in /dev means the hardware was recognized by the kernel and the drivers for it were loaded and the device is available for use.
It is not uncommon to plug in some USB device - say a wireless “dongle” that is not supported by the current kernel - and have it show up in lsusb, but not in /dev.
All I know is that the Aeontec device was working and since the core update not working.
serial:
- /dev/ttyS4
- /dev/ttyS0
- /dev/ttyS1
- /dev/ttyS10
- /dev/ttyS11
- /dev/ttyS12
- /dev/ttyS13
- /dev/ttyS14
- /dev/ttyS15
- /dev/ttyS16
- /dev/ttyS17
- /dev/ttyS18
- /dev/ttyS19
- /dev/ttyS2
- /dev/ttyS20
- /dev/ttyS21
- /dev/ttyS22
- /dev/ttyS23
- /dev/ttyS24
- /dev/ttyS25
- /dev/ttyS26
- /dev/ttyS27
- /dev/ttyS28
- /dev/ttyS29
- /dev/ttyS3
- /dev/ttyS30
- /dev/ttyS31
- /dev/ttyS5
- /dev/ttyS6
- /dev/ttyS7
- /dev/ttyS8
- /dev/ttyS9
input:
- Power Button
disk: []
gpio: []
usb:
- /dev/bus/usb/003/001
- /dev/bus/usb/004/001
- /dev/bus/usb/001/001
- /dev/bus/usb/001/002
- /dev/bus/usb/001/003
- /dev/bus/usb/001/004
- /dev/bus/usb/002/001
- /dev/bus/usb/002/002
audio: {}
I haven’t mentioned (until my response to @freshcoast’s question ) that I also have a Wyze Hub, that is still working. It’s located at /dev/hidraw0. Notice it is not listed in the Hardware list.
configuration.yaml
binary_sensor:
- platform: wyzesense
device: "/dev/hidraw0"
OK, I’m sorry but I’ve reached the end of my technical knowledge on how to continue troubleshooting this.
I don’t use a supervised version in production but just as a test platform. And I’m on the ~latest versions of everything and my Aeotech Z Stick is showing up just fine along with all of my other USB devices.
And I use docker for pretty much everything on my HA machine but I’ve never tried to modify the supervisor docker run command to explicitly add any devices to the path (but I have needed to do that with my production HA Container version so the command is understood by me). I just ran the Supervised install script and it found everything automatically. That’s what I meant above when I said I have seen that docker run command for the supervisor - that I’ve never seen anyone actually modify their run command to pass a USB device.
Where did you get the idea that you needed to modify that docker command? Because I don’t remember that ever being recommended in the docs or forum anywhere.
First to your last question… The forum link is https://community.home-assistant.io/t/making-aeotec-z-wave-stick-static/3716 and following this link http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/ in that thread, 2nd post down, posted by @aimc. This suggestion to set UDEV Rules worked without any issues and resolved an issue I had with both the Wyze and Aeotec Hubs.
The modification of the hassio-supervisor comes from my own use and knowledge of docker. Prior to my retirement a couple years ago, I had managed a WISP ISP Data Center for 12 years. I worked extensively with converting bare metal servers/services to microservices and HA (High Availability) for any and all basic network services (DNS, DHCP, NTP, Mail, Radius, Sandvine Bandwidth Mgmt/Motorola
& Huawei WiMAX, ZTE LTE and Unlicensed Technology Provisioning, Tool Sets for T1/T2 Support and Management, Network Monitoring, etc.), to give you an idea of the range of docker use application.
Circling back around to your description of your production environment. I don’t have a specific love/desire/need to run supervised. In fact I would prefer not to as I don’t love the control it has over the host. But I seemed to understand that it was the necessary “evil” in order to benefit from add-ons.
Perhaps I was unclear on that point. I’m well versed in Docker Containerization, it’s Networking and Volume management. Given that, you mentioned you don’t use supervised but
“…use docker for pretty much everything on my HA machine”
So do you spin up docker containers for the add-ons you use, i.e. Node-Red, ESPHome, etc?
Also, your System Health seems to indicate you are running supervised. Can you clear up my confusion?
Installation Type Home Assistant Supervised
Supervisor true
Docker true
Thanks
FWIW I’m having the exact same issues. I had downgraded to 2021.1.3 and it started working again. Zwave on 2021.1.4 is broken.
To downgrade did you simply change the hassio-supervisor docker run statement to pull a previous image version? If so, no issues with the db/tables?
I restored a previous backup with 2021.1.3.
I have a habit of taking full backups before any updates. Saved my bottom couple of times.
I too, but doing so with the “Home Assistant Google Drive Backup” Add-on. I wasn’t aware it would backup/restore the host docker hassio-supervisor startup script. Or are you speaking about a backup from outside the Docker Container?
I have the exact addon. It was a full backup within taken with that addon, which I restored.
Hmm, very interesting. I’ll investigate. Having said that, it puts anyone who reverts back to an installed core with a security issue with the recommendation to disable all add-ons. Now, some may have a better idea as to the exposure risk of one add-on over the other. I don’t have that information.
hmm… I thought the security issue was addressed if you upgrade to 2021.1.3 and only impacts custom integrations/components.
That’s interesting. Up until I looked today, based on your comment, HA’s website stated 2021.1.4, or at least I would swear by it. And now the advisory states 2021.1.3. What gives? So rhetorical question, why is it that my install stated to update the 2021.1.4. See my other post prior to my upgrade and initiating this thread which shows a screenshot of said version.
https://community.home-assistant.io/t/security-alert-ha-supervisord-wont-update/269277/4
Sorry for any confusion…
As I said I don’t run Supervised for my production system. I just run HA Container and I run my own non-add-on containers for everything. Well, except for the NUT-UPSD container - I run that from the Supervised HA as an add-on since I couldn’t ever seem to get a non-add-on container to work. It’s literally the only reason I still even have the Supervised HA version hanging around (I really need to get that running separately…).
If you are well versed in Docker then I would just switch to HA Container and get away from Supervised. And for the exact reasons you mentioned. There is really no benefit to you to run that install type. Even snapshots aren’t important if you have a good backup plan.
THe only reason I posted the pics of my supervised version was to show you that my zwave and other USB devices actually showed up there so it isn’t the “supervisor install” that is causing your issues. There has to be something else going on. And since you have been modifying the Supervisor Docker environment the that might be the likely cause. ??
The UDEV rules there I were definitely not for use with the Supervised version. There was no such thing in 2016.
the advisory always stated that you need to be running at least 2021.1.3 for the security patch to be in place.
The screenshot from above was just the system telling you that there was an update available. Not that it was a recommended update for the security patch.
I hope I answered your questions.
After weeks of trying to resolve my broken ZWave after the update to 2021.2.1, I have yet to sort it out,
ZWave still broken. So it looks like my next step is to do a fresh install!?!?
So my question is, what Zwave hub would you recommend? Still the Aeotek? Nortek GoControl? Or other?
Thanks
I would say yes.
take a snapshot of your current system.
As far as controller, I use both.
I have the Aeotec as my main production controller since I bought that first when I got started with HA. I’ve never had any problems in three years of using it.
Then later when I decided to get some zigbee stuff I bought the Nortek stick.
But now I’m using the zwave portion of the Nortek stick for testing the zwavejs system. And it’s working fine too for that.
