I will test this weekend. Many thanks for your work, @wborn!
May I ask how the reliability is? Even in the event of a power failure or reboot of the server or client?
I would like to pass my Zwave Stick to OH on Proxmox and hope that this also works if OH changes host.
At the moment I’m using USBIP, but it doesn’t reconnect automatically when the USBIP server is gone.
Actually rock solid, when the openHAB server reboots, remote serial ports are reconnected again and when I reboot the satellite running ser2net the connection is obviously lost but immediately reconnects and the connected devices are online and reporting again as can be seen from below log. This is running on the latest stable (2.5.9).
2020-10-20 08:12:30.062 [hingStatusInfoChangedEvent] - 'zwave:serial_zstick:173f800265d' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Controller is offline
2020-10-20 08:12:30.063 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node5' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-10-20 08:12:30.065 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node2' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-10-20 08:12:30.066 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node3' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE): Controller is offline
2020-10-20 08:12:30.067 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node4' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE): Controller is offline
==> /var/log/openhab2/openhab.log <==
2020-10-20 08:13:17.978 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2020-10-20 08:13:17.979 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2020-10-20 08:13:17.983 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 2: Not initialized (ie node unknown), ignoring message.
2020-10-20 08:13:17.988 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 2: Not initialized (ie node unknown), ignoring message.
2020-10-20 08:13:17.992 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 2: Not initialized (ie node unknown), ignoring message.
2020-10-20 08:13:17.997 [WARN ] [nal.protocol.ZWaveTransactionManager] - NODE 2: Not initialized (ie node unknown), ignoring message.
==> /var/log/openhab2/events.log <==
2020-10-20 08:13:21.302 [hingStatusInfoChangedEvent] - 'zwave:serial_zstick:173f800265d' changed from OFFLINE (COMMUNICATION_ERROR): Controller is offline to ONLINE
2020-10-20 08:13:21.307 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node3' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2020-10-20 08:13:21.309 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node2' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2020-10-20 08:13:21.315 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node5' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2020-10-20 08:13:21.315 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:173f800265d:node5' has been updated.
2020-10-20 08:13:21.316 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node4' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
2020-10-20 08:13:21.316 [me.event.ThingUpdatedEvent] - Thing 'zwave:serial_zstick:173f800265d' has been updated.
2020-10-20 08:13:21.331 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node3' changed from ONLINE to ONLINE: Node initialising: PING
2020-10-20 08:13:21.342 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node5' changed from ONLINE to ONLINE: Node initialising: PING
2020-10-20 08:13:21.351 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node2' changed from ONLINE to ONLINE: Node initialising: PING
2020-10-20 08:13:21.362 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node4' changed from ONLINE to ONLINE: Node initialising: PING
2020-10-20 08:13:21.392 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node3' changed from ONLINE: Node initialising: PING to ONLINE: Node initialising: REQUEST_NIF
2020-10-20 08:13:21.547 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node5' changed from ONLINE: Node initialising: PING to ONLINE: Node initialising: REQUEST_NIF
2020-10-20 08:13:21.937 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:173f800265d:node5' has been updated.
2020-10-20 08:13:23.600 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node5' changed from ONLINE: Node initialising: REQUEST_NIF to ONLINE
2020-10-20 08:13:23.836 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node2' changed from ONLINE: Node initialising: PING to ONLINE: Node initialising: REQUEST_NIF
2020-10-20 08:13:24.140 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node3' changed from ONLINE: Node initialising: REQUEST_NIF to ONLINE
2020-10-20 08:13:24.438 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node4' changed from ONLINE: Node initialising: PING to ONLINE: Node initialising: REQUEST_NIF
2020-10-20 08:13:24.514 [vent.ItemStateChangedEvent] - PoolhousePM25 changed from 18 to 15
2020-10-20 08:13:25.800 [vent.ItemStateChangedEvent] - PoolhouseLoudness changed from 60 to 57
2020-10-20 08:13:26.399 [vent.ItemStateChangedEvent] - PoolhouseTemperature changed from 8.4 °C to 8.5 °C
2020-10-20 08:13:27.587 [vent.ItemStateChangedEvent] - PoolhouseVOC changed from 0.006 to 0.008
2020-10-20 08:13:28.887 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node4' changed from ONLINE: Node initialising: REQUEST_NIF to ONLINE
2020-10-20 08:13:35.406 [vent.ItemStateChangedEvent] - PoolhouseCO2 changed from 437 to 441
2020-10-20 08:13:35.417 [hingStatusInfoChangedEvent] - 'zwave:device:173f800265d:node2' changed from ONLINE: Node initialising: REQUEST_NIF to ONLINE
2 Likes
Hi all, Thank you for this very usefull discussion.
I achieve to get my openhab docker hosted in a NAS communicating with a remote zwave controller (Razberry) using ser2net and socat.
But like some of you, the controller will stay offline when the connection between the docker and the razberry is lost. A restart of socat solve the problem. As there is no systemctl on my docker i cannot achieve to monitor and auto-restart socat. May be I haven’t found the final solution in this long discussion, but have someone get a stable solution in a docker environment to maintain socat connected ?
I’m trying to solve the problem using the following rule :
rule "maintain zwave"
when
Time cron "0 0/1 * * * ?" // every minute
then
var Status = getThingStatusInfo("zwave:serial_zstick:3233e118").getStatus()
logInfo("b_zwave", "serial_zstick " + Status)
if (Status.toString() == "OFFLINE") {
var retval = executeCommandLine("/usr/sbin/service socat-zwave restart",5000)
logInfo("b_zwave", "Restarting socat ("+retval+")")
}
end
but openhab has no right to restart the service. So i’m still block on that way and at the limit of my knowledge with docker (no sudo, no systemctl, must not make change on system side as docker should be updated easily (no change outside /openhab folder…)
Any help ?
You can’t do that from within Docker. The command must be run on the host. One of the main points of containers is to prevent software from doing that sort of thing. You will have to create some sort of service or script that runs outside the container that you can send a message to (e.g. MQTT) and that script will execute the command. Or you will have to install openHAB on the host and not use containers.
I’ve been trying to extend zwave coverage into a steel outbuilding and have finally had some success. I need to summarize some of my findings for the next person trying to piece together what I’ve done and maybe for others to chime in with improvements I could make. I’m choosing to post to this 4 year old thread rather than a new thread because a lot of info and search results consolidate here.
-
OH rfc2217 support.
It will take you most of this thread and parts of others to confirm (i.e. buy into going down the path): OH3 supports rfc2217 natively, seems to work really well. This means you likely won’t need socat unless you have special requirements.
'Controller Thing - Controller serial port:'
rfc2217://extendzwavepi:3333
-
ser2net yaml.
ser2net has updated to yaml for config, with deprecation warnings for the conf file configs. Here’s a working example so you don’t have to bounce through threads to piece together:
#add this to /etc/ser2net.yaml
connection: &Zwave
accepter: telnet(rfc2217),tcp,3333
connector: serialdev,
/dev/zwavestick,
115200n81 local
-
ser2net systemd service definition
Still experimenting with this but it seems ser2net tries to start a bit too early and will have errors if you check it’s status, when it’s in this state the controller Thing in OH will show an error/disconnected state.
sudo systemctl status ser2net.service
Cannot confirm this is a fix but I’m attempting to have the service wait until all networking is up:
/usr/lib/systemd/system/ser2net.service
[Unit]
Description=Serial port to network proxy
Documentation=man:ser2net(8)
After=systemd-networkd-wait-online.service
Wants=systemd-networkd-wait-online.service
You’ll need to make sure those units are enabled in systemd:
sudo systemctl enable systemd-networkd.service systemd-networkd-wait-online.service
Reload the systemd manager configuration after enabling the units and updating the ser2net conf:
sudo systemctl daemon-reload
-
Getting results.
Here’s where I’m unsure of my end result - seems janky but works
Factory reset my secondary zstick with zensys tools and put it in inclusion/learn mode while starting discovery through OH with the primary controller. Secondary zstick is now both a controller in OH and a Thing belonging to the primary controller.
jank: all primary devices show in the Inbox a second time coming from the secondary controller. (at one point I thought I could ignore these secondary devices and the secondary controller would just be acting as a repeating node, inside the steel building, for the primary (only) zwave network.) -
Add secondary things to items.
I started to realize my idea about the secondary controller just being a repeater must be incorrect. So I added the “secondary Thing” for the steel building zwave node to the steel building Item that has been problematic to control. Instant result
It may be a bit cleaner Thing-wise if I just created a second zwave network but I do have neighboring nodes that can and do reach the steel building node and that redundancy may be valuable at certain points.
For extra fun, my rpi running the secondary controller is on PoE making it easy to power cycle from unifi if everything needs to get bounced. I also had to solder a new resistor on my old gen5 Aeotec stick in the middle of all this so my rpi4 (wanted PoE) would recognize it (https://olausson.de/news/2-misc/26-aeotec-z-stick-gen5-raspberry-pi4-mod).
Again, not trying to resurrect the thread but Rich points to it from several “out building??”-type threads and this thread does have tons of info but it spans so many posts it gets hard to gauge the current state of things. I feel like I’ve covered all the things I couldn’t directly piece together from old posts.
7 Likes
An alternative to ser2net is USB/IP. RUDY wraps USB/IP in a Docker container, maybe interesting here.
I think I heard that OpenHab 3 has built-in support for achieving the same end result without having to use USB over IP? Is that true? If so, where can I find information on that. Planning to upgrade from 2 to 3.
Are you thinking about the Remote Openhab binding?
Yeah, but now that I understand it more, it seems that I would have to run a full copy of OpenHab server on the Raspberry Pi. I think for now keeping it lightweight and continuing to use ser2net makes more sense.
The ser2net + socat approach has been okay. Only main issue I’ve come across is that anytime the connection between ser2net and socat is lost, I have to restart OpenHab.
I think he means that originally the sharing of a dongle over IP was achieved by installing ser2net on the machine sharing the dongle and socat on openhab machine.
Then, not sure when exactly, the zwave binding has been extended to support the configuration of the serial port like this:
rfc2217://192.168.101.xx:nnnn
basically removing the need to install and configure socat on the openhab machine.
That does seem to make it way better, very Interesting. Found a forum topic on it here: [SOLVED] [Zwave, Zigbee, ...] RFC2217 remote serial port HowTo? Seems to have been added since 2.4/2.5. Unclear if it’s working in 3.x, but I’ll try it out soon.
Also nice to see RFC2217 is a thing, didn’t know that.
EDIT: ah… just saw the info 2 posts above my original, I completely missed that.
This worked perfectly for me. Thank you for this!
1 Like
Awesome, glad it helped someone!
Could this be used to expose an Insteon PLM and share it with another sytem say for instance Home Assistant so that both openHAB and Home Assistant could control the associated switches and dimmers?
I wanted to note this here (for myself and others) that in order for rfc2217 to work from OpenHAB, the ser2net.conf config file must be setup to use telnet and not raw.
For example, this is what I have for FreeBSD on a Raspberry Pi with a Z-Wave Plus USB stick:
3333:telnet:0:/dev/cuaU0:115200 8DATABITS NONE 1STOPBIT
In OpenHAB I have:
Yes, you can now have multiple:
FreeBSD run on an RPi? One learns something new every day. I’ve always had a fondness for FreeBSD.
Didn’t want to give my two cents to this topic, until I tested myself:
So for me ser2net is working great for OH and zwave-js-ui. “rfc2217” instead of “tcp” might be only possible in OH (not zwave-js-ui)
Usind socat after all to create a virtualDevice makes no sense for me. (see tcp://)
I can also say that unplug and replug USB and LAN-Cable is catched by ser2net, what might it make realy stable and I am going to test this now over multiply househoods. (Saving money for Server 