But when it does not work, what is he talking about here?
Does this apply to 7(8)00 serie controllers and sub-700 devices ?
Note while it’s all talk about 700 series features such as long range, reality is that there’s 700 controllers but hardly 700 devices out there, so it is about making a new controller work with older devices.
I’d guess that any controller vendor will implement the existing 500 series code in addition to the new stuff so his great new stick is compatible with older devices, too, won’t he ?
New slave devices are compatible with older controllers. It is just new controllers that are not compatible with the z-wave binding.
That is an interesting question. For vendors who integrate the controller in a device like Homey, Hubitat, Fibaro and all, the controller you get is what they support. A bridge controller firmware is available for 500 series so it is possible to make the same software support both chips. Fibaro have done this with a 500 chip in their HC3 and 700 chip in their other controller which use the same stack.
For software like Homeseer it is more difficult to be compliant with the standard and support older controllers with a non bridge firmware so I have no idea if any commercial software is supporting everything or how z-way have made their solution.
Some have chosen to ignore the standard and built a serial interface compliant with both bridge controller firmware and static controller firmware. They are gambling that the standards agency may change their minds as they apparently want to be certified. Possibly they are correct and they will get certification.
Incidentally as you mention long range it is worth knowing that Long range only exists just now for the US frequency. The old US spec had a lower power RF but the power has been increased for LR in the US which no longer uses a mesh. I have no idea when LR firmware will be available for other frequencies. They are certainly not in the latest release so if you are not in the US it is not going to be anytime soon.
Another development is that there is no USB 800 series controller with the latest 800 development kit. Third parties might choose to build one but in the past silicon labs made a reference design for each series. The UZB-3 and UZB-7 being the ones for 500 and 700. There is not one for 800 so a 800 series USB controller will be a while.
1 Like
I tried to remove the device via OH, but “remove device from controller” it was not possible.
Step1: So I “only” deleted the thing in OH.
Step2: I started the Raspi with the above mentioned Z-Way Expert UI from image and excluded the Danfoss Devolo in the RaZberry 7 Pro shield.
—> So I had the status like yesterday evening before the whole action: the RaZberry 7 Pro shield was not aware of the Devolo thermostat.
Step3: Now I have triggered the integration of the device as desired via Openhab. Via “Things - ADD” I selected the RaZberry 7 Pro serial controller bridge and started the scan, pressed a button on the thermostat and voilà: the thermostat was visible.
Step4: Then I added the device as a Thing and a short time later I was able to read the first values like temperature and battery status via the channels…
Since the firmware update of the RaZberry 7 Pro shield in generally the communication with the Z-Wave Binding is ok, but not all is tested…
I have made screenshots of all steps, pls see PDF attached
Cheers, Nick
Razberry7 compatibility with Z-Wave Binding screenshots.pdf (786.3 KB)
After above described firmware update of RaZberry 7 PRO shield to 7.16.01.02 (2021-12-08) I was able to include the z-wave devolo thermostat without the zway-Software. Today i found the z-way software is also neccessary to exclude devices from the RaZberry 7 Pro shield - this doesn´t work with the Z-Wave binding…
to be sure I have successfully connected to RaZberry 7 Pro a completely box-new and virgin Devolo (Danfoss) z-Wave thermostat, that has never been used before. And again, there was no big problem with the z-wave binding and adding the device via OpenHab…
I only had to correct the “Wakeup Interval” from 0 to my default 300 (but maybe I have not been able to wait and see if the value comes later 
)
ah… and the wakeup node under Thing settings is “0” … thats also incorrect. But i think this is a zwave binding issue and not a compatibility problem between ZWave Binding and RaZberry 7 Pro…
<…>
So, I have now made another test. I excluded both radiator controls (via the described way), deleted the Z-Wave things and then uninstalled the Z-Wave binding. So everything is now completely reset.
After the OH start I installed the Z-Wave Binding and included as thing. Then via “Add devices” searched for the radiator controls, found and also integrated as a thing. They were immediately recognized with the correct node ID MT02650 Devolo thermostat (09356). I also added this as a thing and added new items in the channels. Voilà, the values are transferred and I can at least read the values. Whether I can also set which, I will still test on the weekend…
FYI: Tested 2022-02-08 with
- openHAB 3.3.0-SNAPSHOT - Build #2733
- Raspberry 3 Model B+
- RaZberry 7 PRO shield (z-wave.me) FW: 7.16.01.02 (2021-12-08)
- Devolo (Danfoss) Radiator Control MT02650 FW: 1.0
In 9 from 10 cases I did not get excludes devices from network with teh 500er RaZberry 
(So there may be an generall issue?)
Can someone provide the “Thing Properties”-Count for " “Devolo (Danfoss) Radiator Control MT02650”, so that Griswold could compare? In my cases when inclusion was to fast the Inerview was not fullfilled 100% and the indication were:
- 20/23 “Thing Properties” present (sometimes even less; I got the value “23” from over 13 well included devices)
- The Button “Reinitialize” was not present
Most of the Time I cound fix this with some “heals” directly after inclusion (and pressing something on the devie; not sure if that was neccessary)
If that dip not help: I marked the device “as failed” + “removed from controller” (not sure if it was really removed) and started inclusion again (that time the device was even faster there and get full name some seconds later)
[Not sure if such has to be mentioned here: superiorly in a tutorial section for slow inclusion; but as you can see, I am unsure in some steps and dont want to propagate half-truth-stories]
I know this workaround and posted it here some times for people having trouble to include z-wave devices under OH 1 and 2. Back then I always used HABmin to start inclusion several times while repeatedly pressing the connection button on the device, leading to a “step-by-step inclusion” of otherwise not including devices.
Thank you so much for your postings on the new Razberry. I am about to switch to my new OH3-Installation on a new Raspberry 4 and still think about the migration of my z-wave devices. I would love to keep the old installation “untouched” in case of a necessary rollback. A new Razberry - even the new model - and the backup and restore feature of the z-wave.me software would be a good chance to realise this. Good to hear that the new model will work with OH3 and will allow to add new z-wave devices.
I have just tested exclude on 3.3 M1 and both uzb-7 and uzb-3 exclude from openHAB but did not remove the thing. I would need to do more testing to see if there is a PR needed but the thing had a very clear error that the node was not found on the controller after I paused and enabled the controller. Manual deletion of the thing was not a big issue anyway.
Again it is very useful to have a zniffer to see the protocol transfer and request exclusion/node info messages for inclusion and exclusion.
Many slave devices are a bit temperamental about entering inclusion or exclusion so it is often the slave device did not enter and send the appropriate messages. On the add the most common error people make is to think it is not added and manage to add and remove all in one. With no zniffer you will know you have done this by a missing node ID. With a zniffer you see the message so stop clicking.
Good question! I just assumed it.
I am sure they will answer you if you ask.
The architecture of the chip is so different the file would need to be rewritten which would be very involved and clever thing to do but they are smart people so they might have done it.
I would also hold your horses until someone has really proved compatibility before getting one if you want to stick with openHAB binding. It would be fantastic if these were compatible but more devices working and some explanation of what the firmware is would help.
Great news, today in addition to my first attempt with the devolo Radiator Control I successfully paired a box new Fibaro FGWPF-102 ZW5 v3.2 230V Wall Plug with the RaZberry7 Z-Wave shield for the Raspberry.
The binding is running, the wall plug can be switched out of OH and I also get the power of the consumer transmitted.
The binding process was straightforward, after starting the scan via the official OH Z-Wave Binding and pressing the button on the Fibaro Wall Plug 3 times, a new Z-Wave Node was detected and after about 15 seconds the name came up: “Z-Wave Node 0006: FGWP102 Metered Wall Plug Switch”.
I added it to the house model via “Create Eqipment from thing” and my test lamp could be switched on and off immediately via the item. Likewise, the power consumption was also immediately displayed to me.
The communication in both directions works.
Cheers, Nick
…and the box new Devolo 014G0160 Room Thermostat could be integrated just as easily with RaZberry 7 Pro ZWave 700 shield. Sensortemperature, Setpointheating, Setpointcooling and BatteryLevel… all there… 
FYI: Tested 2022-02-16 with:
- openHAB 3.3.0-SNAPSHOT - Build #2733
- Raspberry 3 Model B+
- RaZberry 7 PRO shield (z-wave.me ) FW: 7.16.01.02 (2021-12-08)
- Devolo (Danfoss) Radiator Control MT02650 / zwave_version: 1.0
- Devolo (Danfoss) Room Thermostat 014G0160 / zwave_version: 1.0
- Fibaro FGWP102 Metered Wall Plug Switch / zwave_version: 3.2
This is not correct. Z-Wave.Me RaZberry 7 has Static and Bridge mode. The simplest way to switch it to the Static mode (supported by the OH3) is to use it once in Z-Way (Z-Way will switch it to the Static mode). We can provide a simple bash command to do it without Z-Way if needed.
And of course, we suggest the new firmware from February (7.17) since it fixes many issues in the SiLabs SDK itself.
Sounds brilliant but Z-Wave.Me is sadly no longer something I will buy until current situation is resolved.
Sad to hear that. We (as the Z-Wave.Me team members) were never supporting the current regime, were battling against election falsifications, repressions, and militarism. And now we are a prisoner of both sanctions (by US, EU, and you personally) and our own government restricting our work in EU and US. You should do the opposite - support people you like to help them do a better world around you.
Anyway, Z-Wave.Me will continue to provide the best tools in the Z-Wave world and make homes peaceful, eco-friendly, and safe places for living.
1 Like
Replying about the backup & restore: yes, with Z-Way you can restore a 3rd or a 5th gen board on the 7th gen. We provide a smooth experience to our customers migrating to the new version.
1 Like