Great. I’m getting blind. No country for old men…
Hallo chris,
is there a build available with this?
Im looking for this and need it because i want to host my openhab in the cloud
No - the build is not currently working within CI. It works in my local system, but fails with CI. I will take another look at this over the weekend.
1 Like
Hi Chris, build #609 has this feature now yes? Has anyone tested this
For anyone that wants to use the ser2net/socat solution with a docker container: I have it working with the docker-compose.yaml file quoted below. I run openHAB in a docker container on my synology NAS. I use socat to add the device /dev/ttyZWave which is linked to a Z-wave stick in a raspberry pi. I first tried to access the /dev/ttyZWave via devices in docker, but that does not work (although the device is visible). When using a simple volumes: mount of the device, it works (although it is a symbolic link to a /dev/pts/xx). I hope it helps someone because it took me some time to get it working.
version: '3'
services:
openhab: #name of the service
container_name: openhab
image: "openhab/openhab:latest"
restart: always
network_mode: host
volumes:
- "/etc/localtime:/etc/localtime:ro"
- "/etc/TZ:/etc/timezone:ro"
- "/volume1/docker/openhab/addons:/openhab/addons"
- "/volume1/docker/openhab/conf:/openhab/conf"
- "/volume1/docker/openhab/userdata:/openhab/userdata"
- "/dev/ttyZWave:/dev/ttyACM0" # for Z-wave stick
environment:
USER_ID: "1035"
GROUP_ID: "65539"
OPENHAB_HTTP_PORT: "18080"
OPENHAB_HTTPS_PORT: "18443"
EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Amsterdam"
2 Likes
The latest binding has support for the rfc2217 features added. As I’ve said in the past, I don’t personally use this, so I’m not really able to help with configuration and you should check the ESH discussions I’ve referenced previously.
Unfortunately it still doesn’t work. I am on Snapshot 1567(?) (at least that is the one I downloaded, but is displays 1566).
There is some progress, if I put my Z-Wave controller in a file based configuration as a thing
Bridge zwave:serial_zstick:controller "ZWave Controller" [ port="rfc2217://192.168.178.80:7000", controller_softreset="false", controller_master="true", heal_enable="true", security_networkkey="11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 00" ]
then I can see in the logs of my rfc2217 server that a connection is established and communication takes place (so far, so good).
However, the controller is always shown as offline in OH (PaperUI and Habmin) and it is not possble to start a device discovery for my Z-Wave nodes
So at the moment it is still not possible to use a controller connected via rfc2217 ip connection.
It is also still not possible to specify the comport in the UI based configuration as both UIs (Paper UI and Habmin) will only accept the physical COM ports in the dropdown list.
1 Like
Hi,
A slight parallel to this so I hope you do not mind.
As the 700 series is looking like it will be a bridge only controller (certainly no static controller in the SDK), is anyone working or interested in working on Z/IP or zware bindinging for the future?
Of Course you could also try to convert some of the serial calls to the bridge version but it may get more difficult if Silicon labs only pursues Z/IP or zware and breaks the serial interface even more as it is not an intended integration point.
A binding on Z/IP or Zware would solve the underlying issue that triggered this thread. i.e. have the zwave usb in a remote raspberry pi and openHab in a virtual server with communication over IP.
I am sure there is not any need to rush to do this as the current binding works well but at some point it will be hard to get hold of zwave static controllers.
Robert
I’m not super sure what to say - the binding uses the ESH framework for the RFC2217 functions - all that has changed is to use these new classes.
I’ve looked at this, and also discussed this with Silabs in Austin at the end of last year. IMHO Z/IP is not so nice, and I was hoping that now that they have an M4 rather than the 8051, that they could do something different. Unfortunately I suspect it’s heavily driven by the Sigma work that was done prior to Silabs takeover.
The first problem is that Z/IP requires Linux, so it makes a Java application difficult as it forces a distributed system which becomes more difficult to maintain for the majority of users.
This is probably the direction I’ll need to take as ZWAs statement is that they won’t be certifying any products that don’t go down this path. Maybe this will change, but I’m not hopeful.
That doesn’t really matter - the bridge controller is fundamentally the same - there are a few small changes, but nothing major.
That is sad as it does seem a lot of work for little gain. I looked at Z/IP a while ago and was not that impressed with how it ran. I have been testing again with a UZB-7 and even with local install on a RPi 3+ and three nodes there is a lag. I know they think this is TLS overhead but it does seem slow.
I was thinking the same but can not get it to be reliable. I thought if I changed the calls from sendData to sendDataBridge etc as a starter but there is something more fundamental with how UZB-7 behaves compare to UZB-3 bridge. Possibly just early firmware glitches. Have you had more luck?
Thanks for the feedback.
Has anyone successfully used the Zwave Binding with the new serial/esh changes to remove socat from the solution now?
Did you ever try it yourself and got it to work?
No - this was something that was written as part of ESH. I believe it is working, but can not test it myself. What I have tested is that the serial port functions work correctly - the RFC2217 part is embedded within that so is totally outside of the binding and I can’t test this part.
Please see -:
Yes, I can confirm this part. The normal serial ports work fine and also the “virtual” serial ports as long as I use other third party tools for the COM-to-IP-Part. I do have one Aeon Gen5 stick connected via RFC2217 protocol which actually works fine if I use com0com and hub4com on Windows (com0com emulates the COM port on my OH machine so it acts like a local COM port).
However, if I try to directly connect to the RFC2217 stick via OH I can see some traffic in the RFC2217 logs (so something seems to happen), but the Z_Wave stick thing will always be displayed as offline by the Z-Wave binding.
I’m not really familiar with the different incarnations of serial-over-ip, so I’m not really able to comment on this (or even understand the differences 
). This is all managed external to the binding and in a centralised way, so if there are improvements that are required, it needs to be done there (and will then benefit all users of the serial system).
That said, I’d be interested to learn more about the exactly how this all works under the hood, so I’ll see what I can find out.
1 Like
I am aware of that. But I would really be interested to know if anybody got it to work as I read no success stories so far.
Thank you for any help on this. I would also be interested to know how you would do the configuration for the RFC2217 COM Ports as a user. I can NOT define/select it in Habmin or PaperUI. So is it intended to have it only by thing config files? How do other bindings with support for RFC2217 handle this?
I wonder, why even bothering RFC2217? It’s just a memo and still experimental. Just because it’s there?
Beacuse it is working very stable and at least standardized. I am using it with com0com/hub4com on a Windows Platform. I am running 3 RFC2217 servers for my Z-Wave sticks. At the moment I still need to run additional client software on the OH machine to map the remote stick to a virtual local COM Port. It would be nice to just link to the remote stick via RFC2217 directly from OH.
1 Like