I have an idea of migrating Z-wave to a separate device. I am currently running Hass in Docker on a Synology and the stability of Z-wave is terrible to be honest. I believe running Z-wave on a separate device will add both stability and security to the system and like the idea of separating the different layers of my home automation.
I know that this is nothing new and a lot of you guys are using devices such as Vera to handle Z-wave. This is more or less what I want, but I don’t really like the idea of buying another home automation hub just to run Z-wave on it and not use any of the other functions. Instead I would like to use an Rpi (perhaps even Rpi Zero in the long run) together with Z-stick or Razberry.
I have been doing some tests with MQTT, but it will more or less require me to manually setup the sensors, switches etc. on the main device (I don’t want to run MQTT Eventstream on both sides since it will mirror EVERYTHING to the Rpi).
I am now more into the idea of writing a custom component and use the RESTful API to automatically generate the connection to the Z-wave devices. Only problem is that I’m new to both RESTful and Python programming, but I guess I just have to dive into it and I will learn eventually.
Has anyone else done something similar? All kind of tips and ideas of how to do this in the best way are very much welcome.
Z-Wave stability problems generally indicates that your mesh is incomplete. Moving controllers to another system is unlikely to help by itself, but relocating that system or placing more powered devices in the right locations will. If you can share your building’s layout, and where your controller, powered devices, and battery devices are, we can probably help solve that.
If you want to continue with moving the controller, then instead of Eventstream, have a look at Statestream.
I’m sorry, perhaps I should’ve been more clear about the issues. It’s not in the Z-wave network itself, it’s how the Z-stick is not working very well together with Synology and Docker. After a reboot or power failure the USB port is no longer available in Docker and you have to recreate the Docker container in order to get the USB connection to work again. It’s only a matter of a few commands through SSH, but it’s annoying as hell, especially when it happens when I’m not at home and the rest of the family can’t control the home.
Statestream is only one direction, isn’t it? I can watch the state of the Z-wave devices but I cannot control them?
Yes, Statestream is uni-directional, it simply publishes state changes. Obviously you can publish in both directions should you wish, but at that point you’d have been as well to use Eventstream.
The point though of Eventstream is to do what you’re after, connecting 2 instances.
I have tried MQTT Eventstream and it will more or less solve my problem. But the downside is that it will mirror exactly everything between the both instances. That would be useful if I wanted to have a copy of the main instance, but in my case I don’t really see the point in putting all the load from the main instance on the Rpi slave when I basically only want the Z-wave events. I could probably put NodeRED in between as a filter, but since I don’t use NodeRED for anything today I’d like to avoid adding another software to the setup.
But that might actually be a good feature request - to add an include/exclude configuration to the Eventstream component, making it possible to choose what to send to the Eventstream.
I’m also using a z-wave stick in a synology with docker and never had this problem.
The only problem is if I remove the stick ( to include a device for example ) when I plug it back in it will be /dev/ACM1. I solve this by rebooting the synology.
I’ve failed to create an udev rule to have it always /dev/ACM0.
I used to create the docker by hand but now I create it from the UI:
Like z0mbieprocess said, I too have never had this issue. My home assistant docker container is always on and if I reboot it or the synology, it auto restarts and can see the USB Z Wave stick just fine. I do have the options enabled in the container to run as high privilege and auto restart. Not sure if those matter, but just double check how you have it configured.
That might be it! I am mapping /dev/ttyACM0 into Docker.
I didn’t know that High privileges gave you direct access to /dev from within the container. I will try with changing the Hass config to point directly to /dev/ttyACM0 and remove the mapping.
This is working very good so far!
I have tried to replicate the problem by restarting the Hass instance as well as rebooting the Synology (which was not possible to do before, without Z-wave failing), but Z-wave is working fine every time. Thanks a lot for the help!
I am still interested in creating slave instances though, since I might want to have several Z-wave controllers in different areas where my main Z-wave network cannot reach. I wrote a Feature request for a change in the MQTT Eventstream that will make this possible. Please give it a vote if find it useful.
Rather than setting udev rules, try using how your device is listed under /dev/serial/by-id/usb-xxx-xxx That uses the device identity and it won’t change. In my case I have /dev/serial/by-id/usb-0658_0200-if00
the /dev/serial/ directory does not exist on a Synology. The z wave z stick appears as /dev/ttyACM0 so their only option is /dev/ttyACM0 unless they symlink by device id using dev rules.
I think the udev issue appears when removing the stick while hass is running. I’ve stopped hass and removed the stick to include something several times and it worked fine.
You could also use mapping but I think it’s a permission issue, /dev/ttyACM0 is 600.
For example, I’ve tried several times to start ozcp and it did not work until I did chmod 777 /dev/ttyACM0. Maybe we need to add docker to some group in synology
