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.
I am looking for the same result with docker. Did you figured it out ? I consider running a service in the docker container but Systemd is a pain to run within a container at least for me. Or with supervisord like suggested in https://docs.docker.com/config/containers/multi-service_container/ … I am still trying…
Sadly, no I was not able to “solve” it with a general solution to the problem. I found another guy on the docker forums, but he also told me he couldn’t solve it.
For a while I always manually started socat after running the container (really bad solution). The way I “solved” it was to ask the maintainer of the binding to allow tcp connections to the bridge and not just serial connections. Luckily he was super helpful and implemented it in no time flat.
Now I can just add the bridge via an IP address and port and not worry about starting socat at all.
If you are trying to do this for z-wave, I guess opening a ticket for TCP support could be a way to handle this.
Good luck!
Thanks for your answer I will check it. But I needed to do it with Bluetooth as well. For now I just made socat and openhab 2.3.0 amd64 Debian with my own image and supervisord https://hub.docker.com/r/clempat/openhab-socat/ but could not find a Bluetooth binding working with it.
But for zwave I will definitely consider your solution too.
Hey, with the docker image I shared in the previous message and adding some options for the supervisord configurations:
[program:socatZwave]
command=/usr/bin/socat -d -d pty,link=/dev/ttyZWAVE0,raw,user=openhab,group=dialout,mode=777 tcp:192.168.178.25:3001
autorestart=true
startsecs=3
stopsignal=KILL
I get similar error than you and @Matt77 when socat restart I guess. A soft reset on the zwave bridge brings all back to normal. Do you know what do I miss to make it works ?
Do I need to implement a script like there: Z wave - can openhab control a remote (Rasp Pi) z wave stick - #2 by naador
For your information I install fresh installation on my raspberry pi and it is now some hours up without trouble. Let’s see how it is going…
I just had to reboot the VM with OH2 and it looks like le socat did not start on its own.
Anyone can give me advice what is the The Right Way to make it autostart on Ubuntu 16.04 and to do it preferably before the OH2 starts.
As I started it manually I still needed to restart OH2 to make zwave work properly.
TIA
For anyone trying to do this using the RFXTRX USB dongle then the settings are like this:
1001:raw:0:/dev/ttyRFXtrx433:38400 NONE 1STOPBIT 8DATABITS