Just reading some posts claiming that this app or that app is better than the Z-Wave binding. These claims are interesting but highly unlikely to be anything to do with the change from binding to application.
A Z-Wave network runs on the actual chip inside the USB. All the application or binding does is translate z-wave serial messages from z-wave to application format. It is not feasible to take a USB from openHab and run it in another application at the exact same location and get vastly different results.
None of the logic that controls routing or communication lives in the application or binding so it just is not logical to believe that it is possible to get a different result with the same stick in the same network from the same physical location due to changing from binding to another application.
I did just that when I moved to openHAB from an openzwave based system due to better device support. for my needs in the OH binding.
One note is that the security key does live in the binding, not the controller. That means you cannot (easily?) move a network with secure devices anyway.
With two exceptions. Yes all the communications and routing exist in the controller. However:
the security key lives in the binding, not the controller so securely included devices will need to be reincluded or the old security key will need to be imported to the new software
all of the configuration parameters, sensors, and actuators any given device supports is not stored on the controller; knowing that GE Zwave switch XYZ has a parameter for when the status light comes on and it has a binary switch actuator needs to come from somewhere else. And that is why different systems that provide zwave support have a different set of zwave devices that they support.
So it is logical to expect some differences given different zwave software, particularly if the problem being solved is lack of support for a given device.
I was not talking about migration I was talking about the hope of gaining anything from the same stick by simply using it in a different application. The challenges of moving the stick is another matter but in the end it is just keys so if known to the user.
The parameters are all stored in the devices so if the device is not removed you can query them back and if the new application does not insist on setting them to defaults then they would not change but again I am not addressing migration. In truth most applications would reconfigure the device.
All I am saying is the binding does a very good job of calling the serial API. Taking that stick and putting it in another application that calls the EXACT same API on the same controller in the same network will not make a jot of difference to how well your network performs.
If you add a device I think this would be a different network. As would be taking advantage of features like S2 authenticated security rather than S0 which will perform better.
If people are seriously hoping that using a serial connection over python rather than Java will make the difference they are barking up a strange tree. Some people even think it is fun to add a docker layer and some virtualisation to the stack and even that does not totally break the serial API.
In the end it is hard to beat the openHAB binding if you can live without smart start and S2.
Your original post made it sound like you are saying that all zwave software works the same and that everything is on the controller. But that is objectively not true. Otherwise all zwave software would support all zwave devices and that is not the case. Each software supports a different set of devices. If a device is not supported, you can’t use that device with that software (until it becomes supported of course). In openHAB, that’s managed by the device database.
I completely agree that moving to new software is not going to improve range, routing, or any of the layers 1 through 5 of the zwave networking stack.
Also, if this original post is response to a recent thread, in that case the poster wanted to move the physical location of the zwave controller away from where his openHAB server was located. They were not looking to install different software and run the controller in the same location and expect better results. Physically moving the controller to more centrally located position in the mesh is bound to improve the network performance.
If devices correctly implement the command classes and correctly report their capabilities as they should then that is the case. The majority of certified devices do support the standard commands they support. It is at the edges things get strange. The database is not strictly necessary but it does solve issues where the capabilities are badly reported or messages in the exchange get corrupted.
You should read the standards at some point Bruce. It is not an easy read but start with SDS13781. And no the NIF is totally different and not relevant.
Yes for older devices and for nice annotation and screens the database is brilliant but to be certified now there are approved methods for a device to report.
