There are different levels of specification - the command classes are specified, but the low level API isn’t. Yes, you are right though - it’s always possible to decompile software, or look at data on the serial port to find out how something works. This is reverse engineering, and it’s how the binding was effectively written around 10 years ago as the API was not released.
This is however very time consuming, and error prone and as I said above, I’ve not had the time to sit down and try to work out what has changed in the 700 series API.
I don’t think it’s anything to do with Z/IP. It’s just that the maintainers seemed to not have time to continue the project and there has been no significant activity since about 2019. Most projects that used openZWave have now moved to other libraries from what I can see.
Are there any news regarding Z-Wave 700/800?
Currently I have a “Razberry” (Z-Wave 500). But if this will die in future, maybe there are no old controllers to buy anymore. Already at this time it seem to be harder to get an old one. So I’m a little bit afraid and hope there will be support soon, because I plan to invest even more in Z-Wave devices.
Also since I had a hand in the PR, I have run with 700 controllers in OH for several months. (There was a late change during the review that wasn’t tested long, but seems okay.) It would be good to get feedback before OH4.1 in case something needs to be fixed.
Great to hear and thank you very much for your effort!
I read on GitHub that there might be issues when using both types of chip with one instance of the Binding:
Although unlikely, if using two zsticks of different chips (500 and 700) with one instance of the binding, there could be problems with this jar?
How will this issue look like? Just want to know before trying to migrate.
Any other things you might have feedback on when testing?
FYI:
I’m currently using 2 Sticks (500 and 700) as i started migrating to a 700 Stick some time ago as i was expecting some more performance and stability than my old 500 stick.
I’ve done this using zwaveJS and mqtt. I only did some devices until now as i found it pretty anoying using another tool for z-wave and creating all the mqtt topics in OH.
Currently everything is running on the same VM. I just need to stop zwaveJS and add the 700 stick to OH. I’m using the Aeotec 700 Stick.
That possibility was pointed out in the review by the developer, so I added it to the comment section on my personal github. However, it was addressed (fixed) in the official binding.
I also have since deleted that jar from my github website to avoid confusion.
I tried using the Aeotec Gen7 Stick. The Nodes are already added to the controller. I stopped zwave-js-ui and added the Gen7 Stick to OH. The Stick got online. Yeah.
I then tried to add the Nodes. The nodes showed up in my inbox but didn’t show any further informations. Even the name did not change and all nodes showed up like “Node 7”.
I added some Nodes for testing but they wohn’t get online.
Here are the logs when Scanning on the Z-Wave Network with only the Gen7 Stick enabled: gen7Debug.txt (13.7 KB)
Maybe you have an idea.
I also tried Including a new device. But it doesn’t even show up when in include mode.
I restarted zwave-js UI right now. And the recently added device using OH now shows up in zwave-js.
Inclusion seemed to work even the device did not show up on OH
I don’t see any errors. What I’m guessing is the xml files are missing. Normally when inclusion is in OH there is an xml file in var/lib/openhab/zwave. It is equivalent to the “store” in zwave-js-ui. So the devices are on the zstick and discovered, but not configured in OH. Unlike zwave-js-ui, I do not think OH automatically starts to interview
Do you get a “Reinitialize device” option on the UI page for the node?
Edit: also is there anything in the zwave folder noted above? (Also Userdata/zwave in Samba)
EDIT2: I have gone from OH to ZUI, but not tried going back to OH with devices that were discovered in ZUI, so I’m not sure here.
Edit3: Thought of one more idea while out. Try pressing the include button on the slave devices (likely in Scan mode). That sends a NIF (Node Information Frame) that might trigger device configuration messages
i tired some situations with setting the device to inclusion mode and so on. There was no option to “Reinitialize the Device”.
Then i resarted OH and all of sudden the devices in the inbox changed their names to the right name. Only some battery driven devices stayed there with the “Node x” name. After waking them up most of them came up.
I added them. Everythin fine.
Only issue I found: when adding the Device with “custom ID”, the devices don’t disappear from Inbox. Even after restarting OH. I ignored them for now.
Adding without “custom ID” workes like expected.
I also can communicate with the devices that are added as Thing with custom ID. They show up under THINGS and are also still in the INBOX. But i can set values and receive Data from the devices.
I tried scanning again. Nothing changes. If i remove them from inbox, they show up again as soon as i SCAN again.
I had never tried that before, but just tested it and you are right. I believe the Zstick has them named as “nodes”, so they will still appear. To them out of the inbox you can add with the default ID (and delete the custom ID); I noticed that in the /zwave folder only the default XMLs are there. It not a 700/800 issue, my test was on a 500 controller.
I don’t see the value in the custom ID as you can Name your thing anything you like (and unlike the ID) change it if you like. What are you trying to do with that?
Edit: Found this in the docs; you can’t use custom ID with discovery. Need to use text configurations.
You might have noticed that if you don’t define your device via a .things file and instead use dynamic discovery the device’s UID will be zwave:device:controller:node1. Why the difference? During dynamic discovery the binding inquires about all existing Z-Wave nodes. But all the binding receives immediately from the controller is a list of node ids. Additional details about device types are retrieved only subsequently and require a significant amount of time (seconds or longer). To provide quick feedback to the user during dynamic discovery the binding has no choice but to create a UID that doesn’t depend on any device details.
thanks. i double checked and you’re right. All my 500-controller devices are also using the standard nodeX ID. I thought i used customIDs as I’m using these pretty often. But i think that wasn’t possible using OH3 (or 2) where i added all these devices.
Do you know if it’s possible to forbid using customIDs in MainUI? If yes this might be forbidden in the binding.
