RPi as Z-Wave/ZigBee-over-IP server for Hass

shbatm · March 10, 2019, 10:52am

I was only able to get usbip working, but it is working well so far.

I did have to modify the service files above to use network-online.target because the service was starting too soon and not connecting on boot.

Niklas · March 10, 2019, 2:29pm

does it reconnect automatically after rebooting the server or client?

ramdisk · March 10, 2019, 3:46pm

Thanks for the write up I’m also interested in getting this up a running. I have zwave issues,
What files are you showing in your example and where are they located please

Michael_Grossman · March 12, 2019, 6:01pm

Looks like what I have been looking for. I read through this thread and seem lost. Assuming i have a spare pi, a working instannce of HASSIO a aeon zwave stick, what’s the best way to do this?

For now my hassio runs on a laptop, but would like to get it into a hyper-v, and that doesn’t allow me to pass the usb over. I’m so basic when it comes to linux.

flemmingss · March 24, 2019, 5:55pm

I get this error.

Job for usbip.service failed because the control process exited with error code. See "systemctl status usbip.service" and "journalctl -xe" for details.



Last login: Sun Mar 24 00:17:19 2019 from 10.0.24.7
flemmingss@Home-Assistant:~$ systemctl status usbip.service
● usbip.service - usbip client
   Loaded: loaded (/lib/systemd/system/usbip.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-03-24 00:42:29 CET; 18h ago
  Process: 1278 ExecStart=/bin/sh -c /usr/lib/linux-tools/$(uname -r)/usbip attach -r 10.0.24.11 -b $(/usr/lib/linux-tools/$(una
 Main PID: 1278 (code=exited, status=127)

Mar 24 00:42:29 Home-Assistant systemd[1]: Starting usbip client...
Mar 24 00:42:29 Home-Assistant sh[1278]: /bin/sh: 1: /usr/lib/linux-tools/4.4.0-31-generic/usbip: not found
Mar 24 00:42:29 Home-Assistant sh[1278]: /bin/sh: 1: /usr/lib/linux-tools/4.4.0-31-generic/usbip: not found
Mar 24 00:42:29 Home-Assistant systemd[1]: usbip.service: Main process exited, code=exited, status=127/n/a
Mar 24 00:42:29 Home-Assistant systemd[1]: Failed to start usbip client.
Mar 24 00:42:29 Home-Assistant systemd[1]: usbip.service: Unit entered failed state.
Mar 24 00:42:29 Home-Assistant systemd[1]: usbip.service: Failed with result 'exit-code'.

Is my configuration wrong?
Devices:

Bus 001 Device 011: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC #RFXTRX433E
Bus 001 Device 009: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) #Deconz
Bus 001 Device 010: ID 0658:0200 Sigma Designs, Inc. #UZB1

/lib/systemd/system/usbipd.service

[Unit]
Description=usbip host daemon
After=network.target

[Service]
Type=forking
ExecStart=/usr/sbin/usbipd -D
ExecStartPost=/bin/sh -c "/usr/sbin/usbip bind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0403:6001#' | cut '-d#' -f1)" #RFXTRX433E
ExecStartPost=/bin/sh -c "/usr/sbin/usbip bind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0403:6015#' | cut '-d#' -f1)" #ConBee
ExecStartPost=/bin/sh -c "/usr/sbin/usbip bind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0658:0200#' | cut '-d#' -f1)" #UZB1
ExecStop=/bin/sh -c "/usr/sbin/usbip unbind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0403:6001#' | cut '-d#' -f1`); killall usbipd" #RFXTRX433E
ExecStop=/bin/sh -c "/usr/sbin/usbip unbind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0403:6015#' | cut '-d#' -f1`); killall usbipd" #ConBee
ExecStop=/bin/sh -c "/usr/sbin/usbip unbind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0658:0200#' | cut '-d#' -f1`); killall usbipd" #UZB1

[Install]
WantedBy=multi-user.target

/lib/systemd/system/usbip.service

[Unit]
Description=usbip client
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c "/usr/lib/linux-tools/$(uname -r)/usbip attach -r 10.0.24.11 -b $(/usr/lib/linux-tools/$(uname -r)/usbip list -r 10.0.24.11 | grep '0403:6001' | cut -d: -f1)" #RFXTRX433E
ExecStart=/bin/sh -c "/usr/lib/linux-tools/$(uname -r)/usbip attach -r 10.0.24.11 -b $(/usr/lib/linux-tools/$(uname -r)/usbip list -r 10.0.24.11 | grep '0403:6015' | cut -d: -f1)" #ConBee
ExecStart=/bin/sh -c "/usr/lib/linux-tools/$(uname -r)/usbip attach -r 10.0.24.11 -b $(/usr/lib/linux-tools/$(uname -r)/usbip list -r 10.0.24.11 | grep '0658:0200' | cut -d: -f1)" #UZB1
ExecStop=/bin/sh -c "/usr/lib/linux-tools/$(uname -r)/usbip detach --port=$(/usr/lib/linux-tools/$(uname -r)/usbip port | grep '<Port in Use>' | sed -E 's/^Port ([0-9][0-9]).*/\\1/')"

[Install]
WantedBy=multi-user.target

btw, 10.0.24.4 is HA, 10.0.24.11 is the Pi

The service from pie, looks god?

root@raspberrypi:~# sudo systemctl status usbipd.service
● usbipd.service - usbip host daemon
   Loaded: loaded (/lib/systemd/system/usbipd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-03-24 00:19:24 CET; 19h ago
  Process: 517 ExecStartPost=/bin/sh -c /usr/sbin/usbip bind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0658:0200#' | cut '-d
  Process: 510 ExecStartPost=/bin/sh -c /usr/sbin/usbip bind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0403:6015#' | cut '-d
  Process: 495 ExecStartPost=/bin/sh -c /usr/sbin/usbip bind --$(/usr/sbin/usbip list -p -l | grep '#usbid=0403:6001#' | cut '-d
  Process: 487 ExecStart=/usr/sbin/usbipd -D (code=exited, status=0/SUCCESS)
 Main PID: 493 (usbipd)
   CGroup: /system.slice/usbipd.service
           └─493 /usr/sbin/usbipd -D

Mar 24 00:19:22 raspberrypi systemd[1]: Starting usbip host daemon...
Mar 24 00:19:22 raspberrypi usbipd[493]: usbipd: info: starting usbipd (usbip-utils 2.0)
Mar 24 00:19:22 raspberrypi usbipd[493]: usbipd: info: listening on 0.0.0.0:3240
Mar 24 00:19:22 raspberrypi usbipd[493]: usbipd: info: listening on :::3240
Mar 24 00:19:22 raspberrypi sh[495]: usbip: info: bind device on busid 1-1.4: complete
Mar 24 00:19:23 raspberrypi sh[510]: usbip: info: bind device on busid 1-1.3: complete
Mar 24 00:19:24 raspberrypi sh[517]: usbip: info: bind device on busid 1-1.2: complete
Mar 24 00:19:24 raspberrypi systemd[1]: Started usbip host daemon.

shbatm · March 26, 2019, 9:47pm

Use this post as a starting point: RPi as Z-Wave/ZigBee-over-IP server for Hass

I made some tweaks to the service files posted there. I’ve included mine in a gist here: https://gist.github.com/shbatm/1526174a9d285c342eb05c9efa35c02d

shbatm · March 26, 2019, 9:53pm

@flemmingss I would try what was suggested above and split the devices into multiple service files. Also, I would suggest updating the service to use After=network-online.target so the service comes up after you have a network connection (vs. just an active network stack).

Michael_Grossman · March 26, 2019, 10:33pm

Thanks for your help. You made my life so much easier.

bbalz · March 27, 2019, 9:49pm

You sir, rock my socks. Thank you for your effort and documentation on this!

legit · April 7, 2019, 8:08am

Just wanted to add that the usbip method works with HASSIO as of ver 0.90.1 I’ve been testing.

My Setup:

Zwave Server
- Pi 3B
- OS: DietPi
- Aeotec Z-wave Stick - 0658:0200
- Ethernet instead of WiFi
HA Server - Zwave client
- Host: 2c/8gb ram VM running on ESXi 6.7
- OS: DietPi vmware
- HASSIO installed following this method

# Ensure that `/dev/ttyACM0` shows on the host and inside the hassio container
$ docker exec -it $(docker ps -f name=homeassistant -q) stat /dev/ttyACM0 | head -n1
  File: /dev/ttyACM0

Other notes:

Referenced: RPi as Z-Wave/ZigBee-over-IP server for Hass (#63) @shbatm
created symlink: ln -s /usr/local/sbin/usbip /usr/sbin/usbip

Removed a ` in the usbip.service file.

From:

ExecStop=/bin/sh -c "/usr/sbin/usbip unbind --$(/usr/sbin/usbip list -p -l | grep '#usbid=10c4:8a2a#' | cut '-d#' -f1`); killall usbipd"

To:

ExecStop=/bin/sh -c "/usr/sbin/usbip unbind --$(/usr/sbin/usbip list -p -l | grep '#usbid=10c4:8a2a#' | cut '-d#' -f1); killall usbipd"

Niklas · April 13, 2019, 4:03pm

Im getting the same error like @flemmingss had. Already using @shbatm 's config file with the network online target and just one device. Has someone an idead what I’m doing wrong?

-- Unit usbip.service has begun starting up.
Apr 13 17:24:43 server-landerer sh[18437]: /bin/sh: 1: /usr/local/sbin/usbip: not found
Apr 13 17:24:43 server-landerer sh[18437]: /bin/sh: 1: /usr/local/sbin/usbip: not found
Apr 13 17:24:43 server-landerer systemd[1]: usbip.service: Main process exited, code=exited, status=127/n/a
Apr 13 17:24:43 server-landerer systemd[1]: usbip.service: Failed with result 'exit-code'.
Apr 13 17:24:43 server-landerer systemd[1]: Failed to start usbip client.
-- Subject: Unit usbip.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit usbip.service has failed.
-- 
-- The result is RESULT.

shbatm · April 13, 2019, 8:34pm

Make sure you have enabled the kernel module and then try running the usbip command from the command line. There should be an option to list connected ports and list available ports on a remote host.

Sorry I don’t have the exact steps (out of town). But the kernel module should be in the link above, the commands can be found with usbip --help

Niklas · April 14, 2019, 1:50pm

I already loaded thekernel module and checked if they are loaded:

When I’m trying to use usbip, I’m always getting the same error:

Am I missig a symlink?

shbatm · April 15, 2019, 10:26am

@Niklas - I get this error when the host is offline or unreachable (the device with the physical USB device). Check that the service is up and running on the host, that it’s exporting the correct devices, and that it’s reachable from your client.

Niklas · April 15, 2019, 1:12pm

Sorry that I’m still bothering you
From the client I can ping the host, usbipd ist listening on port 3240 on the host so that should be fine…

I just noticed the double slash in the path (/hwdata//usb.ids, last screenshot). Could that be the reason?

legit · April 16, 2019, 7:43am

Your usbip list command from the client should look like:

usbip list -r 192.168.178.31

If that works, then at least your usbip server with your zwave stick is working.
In your client’s system service script, you can either modify the path for where your usbip command lives, or create a symlink.

To modify: get the path with where usbip, and use that path in your /lib/systemd/system/usbip.service

To symlink: ln -s $(which usbip) /usr/local/sbin/usbip
In my case, my usbip was in /usr/sbin/usbip

Linwood · May 2, 2019, 2:52pm

I have spent the last several days exercising this approach extensively, with usbip as a service on an rPi and hass.io running in a Hyper-V VM. I like the result a lot (thank you), and it appears stable in use, but not on any kind of restart.

Rebooting the client (Hyper-V VM) from the outer ubuntu OS works OK, rebooting it from the hass.io docker causes the rPi server to think the connection is still in use and it will not then reconnect when the hass.io side restarts. Rebooting or restarting the service on the rPi, the starting the service on the Hyper-V client, THEN restarting the HA service from the HA configuration page will restore it.

Rebooting the server (or restarting the usbip service on the rPi server) will break the connection but not cause the service on Hyper-V to fail, so it does not restart, so it just never works again until you restart it (and then restart HA again).

This is workable but awkward – any time I am rebooting either side requires care and checking to see that everything is functional. I can’t find any kind of watchdog or heartbeat setting that might automate this. Since in the rPi reboot case both ends have the service running but not functional, it is hard to script something to notice (the only clue I have is that a HA restart gives an error on the zwave integration startup).

Those using this – have you found a way to make the client/server reliably survive reboots?

Linwood

shbatm · May 3, 2019, 7:05am

So I was having problems with this as well. I run hass.io in Docker on a RockPi in my network room, and the physical z-wave stick runs on a Raspberry Pi MagicMirror2 by the front door. Your comment inspired me to finally implement my plan for a more robust restart connection (especially after it died from a power outage yesterday).

I’ve updated my gist here: https://gist.github.com/shbatm/1526174a9d285c342eb05c9efa35c02d

This now has a “usbipManager.sh” (basically an expanded init script) script which does a few extra things:

Before connecting: Ping the host and see if it’s available. If not, wait and retry using an exponential delay (1s, 2s, 4s, 16s, etc. to 256s). This gives time after, for example, a whole home power outage, where everything comes back at the same time, but you have to wait for the other server to come up first.
After confirming the host is there, check if the USB-IP service is available. If it isn’t, try to restart the service on the remote machine using SSH. FOR THIS TO WORK you must have Public Key Authorization set up both directions on the 2 machines. This will “fail” the script on the client, but the server will “call back” on service restart and restart the client.
If everything is good, mount the device.
After mounting the device, restart the homeassistant docker, if it’s already running.

On the USBIP server side:
The server’s .service file actually includes a line to call the client (via SSH) and attempt to restart the client’s service when the server’s service is available. It will continue on if it fails, but if it succeeds, this will cascade to re-mount the port on the client and restart Home Assistant. This is useful if I have to restart the MagicMirror for any reason… when I do, it will call the Hass.io server and tell it to reconnect and restart.

Linwood · May 3, 2019, 12:21pm

Thank you @shbatm. I had vague ideas of doing something similar but your code will save me a lot of time. I had gotten distracted with a related issue however, and wonder if you have seen it.

When I restart the service on the client, sometimes but not always, it changes the device names. On the server I have /dev/ttyUSB0 and /dev/ttyUSB1 for a Nortec stick. At first they match exactly on the client. When I just do a sysctrl restart usbip on the client side they move to /dev/ttyUSB2 and /dev/ttyUSB3. If I restart again they do not advance again, though as I write this I realize I also never change HA’s config to use the new devices, so maybe the issue is some kind of in-use condition not allowing the old device names to be reused?

I was experimenting with udev rules to force the naming of the client side usbip devices, with zero luck. It is almost as though udev is not involved in their creation. Now that I have thought of the in-use issue, maybe I can change the stop condition to always restart HA’s container and see if that releases it.

But have you seen this issue and have any insight?

So far my only solution has been a reboot of the client’s containing VM, and I am loath to script that in the service for fear some condition will just get it stuck in a boot loop. Of udev would work, even if it failed to create the device because of a name collision, my thought was the restart would fail and I could do something – dealing with a new device name is much more of a pain in terms of scripting, I would need to change the configuration.yaml script inside the docker container.

Postscript: I see you have a udev rule in there also, I’ll try yours (I was using subsystem usb as that’s how it showed).

Linwood · May 3, 2019, 2:03pm

Further to the issue of device names, it appears (e.g. the first answer here) and docker (how I’m running hass.io) does not allow symlinks (discussion here, apparently no plans to allow). So as best I can tell I need to find out why I am having shifting names.

I take it you are not using docker for hass.io? As you are using a symlink (which I can get working).