But can this device also be used with other HA systems than homeseer? I always thought that the communication protocol between a Z-Wave Stick and a computer via USB is also a standardized one by Z-Wave alliance. I am not sure if communication via LAN is also standardized an global Z-Wave level with support for multi manufacturers.
I’m follwoing this thread out of sheer curiosity.
Mostly i’m struggling to see the benefit of a device that purely translates z-wave to ip.
To my knowledge - having more controllers in a z-wave networkcould help heaps with signal stability, responsiveness and would allow to either cover big distances or really many devices, and ALSO let you CHOOSE where to run your automation rules to spread the computing load and don’t leave you stranded in case of failure of “THE” main controller,maybe even plan redundancies!!! (!LUXURY!) etc.
The post by @chris in date 20 oct replying to @kentann
feels to me like the following example
All printers used to run on serial, then either serial or usb connection, and you needed a chapo print server to connect them at a distance or share them if you needed to, at home or in a small office. It was cumbersome.
one says: “Nowdays you have a wealth of convenient printers with wifi and lan connectivity built in.”
the other: “Yes but i REALLY want a cheapo print server.”
Really curious to see where this goes. There might be unexpected use cases and developments ahead, despite my prior convictions, 
PS- print servers don’t need to be cheap, but neither you need to run multiple z-wave controllers on raspberry pies. There are plenty mini pcs that could run a sata ssd and come well boxed with fcc and ce certificates etc, and really cheap UPS can keep SBC based systems+ routers running for ages…
The zwave controller need not be in the same place as the openHAB host box. It can be in a different building on a campus. Or in a different country, over VPN.
If you’re thinking about resilience, a remote zwave controller can be used in a primary/failover hosts situation.
But this is achievable also with multiple controllers, over vpn, with mutual checks between them, without exposing all the network heals etc that happen via z-wave (that you would otherwise need a Zniffer to catch) over either lan or vpn - instead transmitting just the relevant info… isn’t it?
This concept of using an off the shelf USB device server is great! For $80 (same price of an RPi + power + chassis + SD card) you’re operational quicker with better reliability. Love it.
How does one complete the link the Silex DSxxx on the Openhab side? With socat?
Actually there is a specific Silex Software (called SX Virtual Link, downloadable on their website) . However I am nut sure if they also provide support for linux ( I am running on Windows).
And perhabps one more comment from my side: I meanwhile changed my setup an do not use the Silex solution anymore but I indeed switched to Raspi and ser2net. The problem with the Silex software was that when the LAN/WLAN connection was lost for a short time the virtual COM Port on my OH machine disappeared and reappeared after a short time. But OH was not able to recover the connection and my Z-Wave network stopped unless I restarted the binding manually.
With ser2net on a Raspi as serial device server and com0com and hub4com as serial device client software on Windows it works more stable. The COM port is alwasy present even if the connection is lost for a short time. So as soon as it reconnects OH will continue to work. For these reasons I would recommend the ser2net solution with the Raspi.
I’ve been trying to accomplish this myself. I m going to try out ser2net, any advice before I begin?
I think it depends on which platform you are running OH. As I am running OH on Windows I can only give advice for that combination with com0com and hub4com as Software on the client side. If you are running on Linux I think the client software is called Socat but I never used it myself.
HI good afternoon! I’ve been fighting with OpenHAB 2 (2.5) and trying to put two z-wave controllers -and I am thrilled to hear you have a configuration with 3! Amazing! Are those individual z-wave networks? (masters of their own networks) - Can you use Habmin to add the controllers and the devices or do you need to add them manually? Sorry I have some many questions and your post gave me some hope after fighting with this issue for a very long time…
Thanks!
Yes, those are 3 individual Z-Wave networks with own master only integrated via OH. So it is not possible to have Z-Wave associations directly between the devices of the different networks, but you can integrate them via OH, e.g. by rules.
Yes, you can use Habmin or PaperUI to integrate the controllers and also new devices. For controllers you have to add them manually and specify the COM Port of course.
However, there is one point to consider: When you start a network search for new Z-Wave devices then Habmin (or PaperUI) will trigger the inclusion mode for all 3 networks simulaneously. So you have to make sure yourself to include the new device in the correct network (e.g. by positionning it very close to the intended master controller). Otherwise it can happen that one of the other controllers picks it up first.
The architecture of the OH Z-Wave binding explicitely supports multiple controllers and it works very smoothly in daily operation.
However, if I had to start my smart home project again (my installation is from 2015/2016) , I am not sure if I would still consider Z-Wave as the technology to go. For most wired devices (e.g. swiches, dimmers, raffstores) the Shelly devices are meanwhiloe the much better choice from my perspective. They just work over WIFI which is much more easy to extend (no need for different master networks and all the stuff) , are just as small as the Z-Wave devices, support open standards (like MQTT), support easy configuration and over-the-air firmware updates via WebUI (which is not true for Z-Wave devices). And the best: They cost about only 40% compared to similar Z-Wave devices.
So I slowly started to replace my Z-Wave devices with Shellys, everytime I have to replace a device I do not buy a new Z-Wave device but install a Shelly device for it.
Another alternative is go to silicon labs and download Z/IP. The latest version works reasonably well but however you approach this it is more hardware and more integration.
Z/IP gives you S2 security also known as some security as opposed S0 or better known as not a lot of security so if security is important another reasons you would like this. Also a few other things.
The Web API is simple enough and well documented.
I did start wrapping the web portal API to make a binding but @Bruce_Osborne pointed out just wrapping in MQTT would be more generic. That is an alternative as the openHAB end is a fiddle in comparison and the solution would be more portable.
Interesting. But how would an architecture with Z/IP look like? What is exactly the intention behind it?
Z/IP is (or was?) a middleware layer. Sigma started pushing this as the solution to problems surrounding documentation, and the release of information to the public. It provides an interface between IP and the serial API that dongles use.
Now that everything is being opened up in ZWave (possibly late this year or into next year) this requirement will disappear and I suspect that Z/IP may be obsoleted (although I’m not 100% sure about that at the moment as Silabs are still discussing their strategy.
Note that Z/IP will not work with the binding - it would require pretty much a new binding. When Z/IP was the only way forward for certification, I did look at this, but it’s not an insignificant amount of work as it conceptually works differently to the current binding.
The other downside about Z/IP from a Java / OH perspective is that it requires a separate server to be run which can’t be included in the binding, and is obviously host dependant, so it causes issues with OH portability.
1 Like
Thank you very much for clarification!
Hi good morning! Thank you for this extra info.
The problem that I have is with the discovery of those devices. Since they come from different z-wave networks, I have two nodes that are node 2 (with different masters) and discovery seems to be overriding with the other node 2 (one is Gocontrol HVAC one, and the other is a light switch)
I’m in openhab 2.5.2-1 and Debian (real server)
What version of OpenHAB are you using? Do you use auto discovery or you have .things file for the zwave devices?
Thank you for your help, I appreciate it very very much
Adrian
I am using the functionality since 2017 (I think it was OH 2.1?), so there is no problem with the version.
There is also definetly no “override” with same node numbers as the binding stores for each node the network id and the node number. I have for example a node 48 in all of my 3 Z-Wave networks. Here you can see the 3 xml files generated by the binding:
The id behind network_ is the Home ID of each Z-Wave controller stick. So the binding clearly can distinguish identical node numbers within the networks.
I use auto-discovery for most of my zwave devices. Exception: I have some battery operated door sensors which wake up very seldom (only all couple of months) and as I do not like to wait for this moment or to trigger the button manually I have them in a .things file. Like this they work immediately after a fresh OH install.
For my items I am using .items files. In these file you can specify the channel for the Z-Wave devices including the thing id of the controller and node number:
Number EN_HWRA_WA "EN_HWRA_WA" <energy> (sumkwh_hhdev) {channel="zwave:device:ZWUG:node15:meter_kwh"}
Number EN_KOCH_BL "Bora links(kWh)" <incline> (sumkwh_hhdev) {channel="zwave:device:ZWOG:node83:meter_kwh"}
So in the above example you see the controller UID info between device: and the node number (in my examples ZWOG and ZWUG).
You can specify that UID when you manually include the stick for the first time:
As I like to have my items file simple I choose manually a shorter UID instead of the long hex value proposed by OH.
Hope that helps!
2 Likes
Thank you! Do you mind sharing with me the .things for your battery operated devices? I think I’m facing a similar issue with my Gocontrol gctbz48 devices… that might be fixed with manual initialization (instead of discovery)
Thank you # 2
Adrian
Here is the example for my Fibaro door/window sensors FGK101:
Thing zwave:fibaro_fgk101_00_000:ZWAB:node35 "Z-Wave Node 035: FGK101 manual" (zwave:serial_zstick:ZWAB) @ "ATOI" [ node_id=35]
Please note that the correct syntax is different for different devices and versions of the device.
There is a good post here.
That is good but do you have also in the .things file for your bridge?
This is what I have on my zwave2.thing file
Bridge zwave:serial_zstick:SZwave "Z-Wave Serial Controller-South" [ port="/dev/ttyACM0", controller_softreset="false", controller_master="true", heal_enable="true", heal_type=2, security_networkkey="..." ]
{
Thing zwave:linear_gctbz48_00_000:SZwave:node2 "Grade 8 HVAC - node 2" (zwave:serial_zstick:SZwave) [ node_id = 2 ]
}
But I get a lot of errors and when I try to modify the temperature target for example, I get an error on the openhab.log file:
2020-03-02 11:21:04.433 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.zw
ave.handler.ZWaveThingHandler@2f917aa0’: null
java.lang.NullPointerException: null
at org.openhab.binding.zwave.internal.converter.ZWaveThermostatSetpointConverter.receiveCommand(ZWaveThermostatSetpointConverter.java:148) ~[?:?]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.handleCommand(ZWaveThingHandler.java:1181) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy188.handleCommand(Unknown Source) [?:?]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:74) [bundleFile:?]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Could you avoid this situation by simply disabling not used controller during inclusion?