I’ve snapped Open-Zwave Daemon (ozwdaemon) regards to Home Assistant’s move away from it’s built-in Z-wave integration towards the “Z-wave to MQTT” integration - what they call Open-Zwave Beta.
I’m struggling to apply the network key to my device, which is a Aeotec Z Stick Gen5 (not the revised model that supports RPi 4). After a lot of testing ang googling I’ve read that it’s a problem with this stick. Many of my devices require a secure connection, such as my lock
I’m located in the northern region of Norway and getting ahold of a new stick isn’t that easy. I had to order from abroad and it can take days or weeks to arrive.
I’m therefore hoping that some of you have a Z-wave stick and could help out testing this snap.
It’s found in the edge channel.
snap install ozwdaemon --edge
It doesn’t run as a daemon yet, so you can simply run it with ozwdaemon.
See snap get ozwdaemon -d for settings
PS! I’m aware of the environment variables printing etc upon execution. It will be removed.
Edit: Sorry, I had listed it as Private. It’s now listed as Unlisted (does not appear in search).
The issue was with the implementation (frontend) of Home Assistant, that didn’t take the secure flag into consideration. To add a device you’ll have to use service calls (from the Developer Tools), e.g:
{
"secure": true,
"instance_id": <id>
}
See snap get ozwdaemon ozw.instance to find the id.
Snap is now daemonized and you can find more information about the settings (and to test them) with ozwdaemon.exec --help.
/snap/ozwdaemon/74/usr/local/bin/ozwdaemon: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
But the file libQt5Core.so.5 is in the right directory
@joachimmg, I think this is great of you to do this but regrettably I was not successful at installing/running the snap ozwdaemon service.
I run a standard Home Assistant 2020.12.0 venv setup on CentOS 7. Where I might differ slightly in my installation is that I run a Socat Service to communicate with a Z-Wave Aeotec Z Stick Gen5 Hub that I believe to be similar to yours. I am not certain if this is the right place to post this and/or this snap release was conceived to support a USB ZStick over IP? All to say that if you are interested here is the log error that I got after my installation:
[root@services28 ~]# snap logs ozwdaemon -f
2020-12-28T19:25:37Z systemd[1]: snap.ozwdaemon.ozwdaemon.service failed.
2020-12-28T19:25:37Z ozwdaemon.ozwdaemon[10776]: usb-path (/dev/ttyUSB61) does not exist, or is not a Character Device.
2020-12-28T19:25:37Z ozwdaemon.ozwdaemon[10776]: See: snap get ozwdaemon -d usb-path
2020-12-28T19:25:37Z systemd[1]: snap.ozwdaemon.ozwdaemon.service: main process exited, code=exited, status=1/FAILURE
2020-12-28T19:25:37Z systemd[1]: Unit snap.ozwdaemon.ozwdaemon.service entered failed state.
2020-12-28T19:25:37Z systemd[1]: snap.ozwdaemon.ozwdaemon.service failed.
2020-12-28T19:25:37Z systemd[1]: start request repeated too quickly for snap.ozwdaemon.ozwdaemon.service
2020-12-28T19:25:37Z systemd[1]: Failed to start Service for snap application ozwdaemon.ozwdaemon.
2020-12-28T19:25:37Z systemd[1]: Unit snap.ozwdaemon.ozwdaemon.service entered failed state.
2020-12-28T19:25:37Z systemd[1]: snap.ozwdaemon.ozwdaemon.service failed.
Have you checked the the USB-path is set correctly?
usb-path (/dev/ttyUSB61) does not exist, or is not a Character Device.
2020-12-28T19:25:37Z ozwdaemon.ozwdaemon[10776]: See: snap get ozwdaemon -d usb-path
It seems to me that the path is not existing. See ozwdaemon.exec -h for help-text.
Best wishes!
PS! Also make sure that you can run the daemon (ozwdaemon.exec) before you start it as a service. You might find it easier to debug.
I agree with you from the message it does sound like I have the incorrect USB-path. Though I have been using this approach for over two years … I double checked everything that I could think of.
[root@services28 ~]# snap get ozwdaemon -d usb-path
{
"usb-path": "/dev/ttyUSB61"
}
[root@services28 ~]# ls -l /dev/ttyUSB*
lrwxrwxrwx 1 root root 10 Dec 30 09:55 /dev/ttyUSB61 -> /dev/pts/0
[root@services28 ~]#
[root@services28 ~]# systemctl status zwave-client-controller.service
● zwave-client-controller.service - Z-Wave Remote Client
Loaded: loaded (/etc/systemd/system/zwave-client-controller.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2020-12-30 09:55:01 EST; 26min ago
Main PID: 1108 (socat)
CGroup: /system.slice/zwave-client-controller.service
└─1108 /usr/bin/socat pty,link=/dev/ttyUSB61,nonblock,raw,echo=0,ignoreof,waitslave,user=homeassistant,group=dialout,mode=660 tcp:raspberrypi10.cognoquest.org:4001
[root@services28 ~]#
[root@services28 ~]# ozwdaemon.exec
usb-path (/dev/ttyUSB61) does not exist, or is not a Character Device.
See: snap get ozwdaemon -d usb-path
I stopped the homeassistant service to see if it would help, regrettably not. Also could there be a permission issue? I added root to the dialout group used by socat but again not working.
Do you know what this means? I am running out of idea…
Expecting to have an early release of this solution anytime soon! Not sure if it will be zwave-js-server and zwavejs2mqtt, since both is offering the web-socket that Home Assistant need to consume Z-wave data. It might be zwavejs2mqtt for the benefit of mqtt.