Your socat.conf seems fine…for reference see the content of my own production socat.conf below:
OPTIONS=“pty,link=/dev/ttyUSB0,raw,user=openhab,group=dialout,mode=777 tcp:172.16.11.5:3333”
after some testing i figured out what the actual problem was, it seems that the PI got restarted and even i restarted the ser2net and the socat service the problem persists. after i restarted the OH2 everything came back to normal.
so the question is now how to ensure that this will not happened again, i guess i need a kind of script which will ensure that all services get restarted if the remote PI-Zwave was not reachable for a certain time.
For Windows users, this is the equivalent:
If you’re using the systemd service file above, add a “Restart=always” line to the Service section. When systemd sees socat exit, it will restart the service automatically.
This doesn’t seem to be happening. I disconnected the server (reboot), socat died on OH2 and didn’t start back even after z-wave controller server was back up.
I had to make these modifications to get it to work:
[Unit]
Description=Multipurpose relay (SOcket CAT)
After=network.target
**StartLimitIntervalSec=0**
**StartLimitBurst=3000**
[Service]
**Restart=always**
**RestartSec=3**
EnvironmentFile=/etc/default/socat-%i.conf
Type=simple
PIDFile=/var/run/socat-%i.pid
ExecStart=/usr/bin/socat -L/var/run/socat-%i.pid $SOCAT_DEFAULTS $SOCAT_CONNECTION
ExecStop=/bin/kill -SIGKILL $MAINPID
[Install]
WantedBy=multi-user.target
NOTE: Remove **
This is what the netstat looks like:
tcp 0 0 openHAB2-IP:35514 Z-WAVE-Controller-IP:3333 ESTABLISHED 2133/socat
<reboot z-wave controller>
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 1 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 SYN_SENT 2192/socat
tcp 0 0 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 ESTABLISHED 2192/socat
tcp 0 0 openHAB2-IP:35521 Z-WAVE-Controller-IP:3333 ESTABLISHED 2192/socat
1 Like
Short question.
I know. A RaspPi3 isnt expensive. But i have 2 RaspPi first generation lying around.
What you think. Worth a try? Or should i buy a RaspPi3 to be save?
I hate to have unused hardware lying around and buy new stuff…
[EDIT]
Btw. I plan to use a Aeon Labs USB Stick for that.
Regards
Capo
If you are planning on running the z-wave dongle on that then a RPi1 is plenty powerful enough. If you are planning on running OH on it, you will be better off getting a RPi3
2 Likes
My Openhab runs on a ESX Server on Docker. So the Pi will only be used to forward the z-wave dongle.
Thanks for you input. I give it a try.
Would this work for zigbee USB dongles too? I have a zwave/zigbee combo connected to a raspberry pi 3 B?
Yes it’s applicable to any usb serial device
thx for this great guide. I will test this for sure the next days/weeks when I have time
I have had this running for a while for development testing, but now I wanted to get this running on my production environment.
This production environment runs inside a docker container.
When I add the virtual USB device to the docker container using --device it also shows up in the container.
However, OpenHAB doesn’t seem to like it and doesn’t allow me to choose it for bindings that require serial devices.
When i look at the devices on the host they look like this:
ls -lah /dev/tty*
crw-rw---- 1 root uucp 188, 0 May 20 20:44 /dev/ttyUSB0
lrwxrwxrwx 1 root uucp 10 May 23 11:18 /dev/ttyUSB2 -> /dev/pts/6
Inside the container like this:
ls -lah /dev/tty*
crw-rw---- 1 root uucp2 188, 0 May 23 11:55 /dev/ttyUSB0
crwxrwxrwx 1 root uucp2 136, 6 May 23 11:55 /dev/ttyUSB2
The ttyUSB0 is a physically connected EnOcean USB300 that works fine inside the container, the ttyUSB2 is the virtual one, which does not work.
Any Idea what is going on here?
You cannot mount volumes inside Docker containers that contain symbolic links. Or put more correctly, symbolic links created on the host do not work inside containers. I fought this dragon awhile back when trying to get the LetsEncrypt certs into a couple of my containers.
I suspect the same is occurring here.
A symbolic link is just a tiny file containing the full path to whatever it is that the link points to. When you are inside your container there is no /dev/pts/6 because you haven’t passed that device into the container. So the link doesn’t point at anything.
I’m not certain, but I suspect that it wouldn’t work even if /dev/pts/6 did exist, though that would be an interesting experiment.
Thanks for your reply, Rich!
So your answer is pretty obvious if you think about it. Stupid me, I had that problem before when using volumes. I had just not thought of this because I thought the --device flag worked differently than volumes.
I am not sure what the difference is, really.
So now I tried to directly provide the device via the /dev/pts/6, but that also doesn’t work.
Do you have any advice on how to make this work without creating my own docker image?
I’m afraid I don’t. I only know enough about Docker to be dangerous. I suspect you will need to troll the Docker forums and stackoverflow to find an answer.
2 Likes
Hm, do you happen to have a tutorial handy that one can follow? I know there are lot’s out there, but which one to follow isn’t that obvious to me 
Given I never got it to work the answer is unfortunately no. I’m not current exposing anything to the outside Internet directly so my need for LetsEnrypt certs has gone away. I’ve bee using OpenVPN to connect to everything instead.
I am running openHAB in a docker container, with certificates from letsEncrypt. The certificates are picked up from the /userdata/etc/keystore file, which I have mounted from outside the container (using the -v option). As such, I didn’t need to get the certificates into the container.