OpenHAB 4.1.1 deb packages
Raspbian 11
ZWave Controller Zooz Zwave 800 Series Controller ZST39
Pi4b 4GB
This controller has ZERO buttons, it uses the Serial API to activate inclusion/exclusion modes and as near as I can tell the ZWave binding doesn’t do it. Am I mistaken? I know you cannot perform an NMS backup of the Aeotec Gen5 or any other 500 series and restore it to the 800 series without bricking it because the 800 series has 8k smaller NMS by spec. So I’ll likely have to set up a temp OpenHAB server to include the 800 to the existing zwave network thus copying said network. But then how do I tell teh 800 series to join? I know how to set the Aeotec to include mode, but since the 800 needs the serial API to issue the join/pair command as a SUC how can I do that?
You are mistaken. From the docs:
When the discovery process is started, the binding will put the controller into inclusion mode for a defined period of time to allow new devices to be discovered and added to the network.
If you need to exclude devices, you would do so from the thing for your controller.
Saying all of that, I’m not sure if 800-series controllers are supported by the 4.1.1 binding. You may need to update to a snapshot. @apella12, can you comment on this?
You could alternatively try Zwave-JS-UI (also thanks to @apella12’s efforts).
This kind of highlights why the inclusion buttons on Aeotecs can be problematic. We would generally recommend starting inclusion from the binding, but many Aeotec users never learn this since the button is more convenient. That’s fine until they change controllers or try to add a door lock, because secure inclusion only works if initiated by software.
It is hard to tell, but I’m guessing you want to transfer your 500 stick network to the 800 controller without bricking it. I wrote this up earlier from my experiences.
Transitioning a network from 500 chip.pdf (235.8 KB)
Yes I will look into that tonight along with that ZWaveJS-UI
Missed this on the first look. 800-series are supported in the OH zwave binding starting with 4.1.0. I tested the OH4.1 zwave binding with a Zooz zst39. The only caveat is that the LR mode is not supported, but the zst39 will work fine in “classic” zwave. FWIW this is the same situation with Zwave-js-ui at this moment. Something else I wrote;
Starting with OH4.1M4 700 and 800 chip Zsticks should work in the OH ZWave. The biggest beneficiary will be the new OH user as the 500 chip controllers are hard to find and cost more. For current OH users with 500 chip controllers, observed gains from 700/800 controllers may be modest. The top speed of 100KB/sec is the same. There may be a few more devices are in direct communication with the controller and the chip processes messages a bit faster. Your results may vary.
The 800 chip “Long Range” capability is misleading. Long Range Zsticks have dual frequency ranges. One set of frequencies are for “classic” Zwave and have the same range as 700 chip (and 500 chip) controllers. Long Range uses a separate set of frequencies with a spread spectrum technology that allows for higher power. I found this on the Silabs website and the summary below is extracted from my understanding. To achieve the higher power Long Range capability, the device must be included with the following requirements (these could change over time?):
1) Long Range nodes have 12 bit addresses (vs classic 8 bit) starting at 256. This would require a major refactoring on the binding.
2) Long Range inclusion requires Smart Start. This is not currently coded into the OH Zwave binding.
3) Long Range inclusion requires S2 security. The OH Zwave binding currently only supports S0 security.
4) Long Range is currently only permitted in North America.
5) Long Range nodes only ‘talk’ to the controller (no mesh) so the binding needs to relay messages to other nodes (No Association Group messages).
6) Without all the Long Range requirements nodes will automatically be included in classic mode.
Awesome. Maybe it would be worthwhile to add a “Supported controllers” section to the docs?
I did add a note to the GitHub.md, but it was after the 4.1 release, so is in the 4.2 docs. 