When looking at the docs, did you change the option to “Latest”? This was only added reasonably recently, so you need to look at the latest docs - not the stable version (or look at the README on GitHib.
I have just one add to Zwave vs Zigbee topic. I’m still prefering Zwave despite of all difficulties as everything is compatible with everything. It does not true for Zigbee. Plus when Zwave network is set up properly this works very smooth forever.
While this is sort of correct, if you really buy Zigbee devices, as opposed to devices that use the Zigbee protocol, then it’s not really correct. The difference I try to make here is that there are a lot of cheaper (mostly Chinese) devices like Aqara etc that use the Zigbee protocol - mostly - but they often aren’t certified and often don’t fully support the standards as they are designed to work within a closed system with their own hub.
For the most part, if you stick to Zigbee certified devices, you should enjoy the same compatibility between Zigbee certified devices as Z-Wave has.
2 Likes
Thonk you I see tha now.
You may want to correct typoes ( search for HUSZBZ-1 and change to HUSBZB-1) 
1 Like
Thanks Bruce. I have another PR ready to go once I update the library and I think I fixed that, but I’ll double check.
Many thanks for the hint. I have ordered a Zigbee dongle anyway yesterday. I wanted to do it anyway this conversation was the last trigger. Just one last question. What are the main brands what’s products are Zigbee certified and trustable in your oppinion?
It is an interesting thread…
Q: How do you do Z-Wave properly?
A: Migrate to fully certified Zigbee.
That could be correct long term and I have started a Zigbee network but found the cheap devices are not great. I will take Chris’s advice to use certified devices.
Alongside this I have a very stable and fast Z-Wave setup with over 220 physical devices (over 400 endpoints) but with them split so there is a maximum of 40 devices on any network. This is using remote instances. Most instances with single UZB3 but some with 2 * UZB3 where I had a lot of reporting devices that I wanted to report small changes but not cause pauses in control of other devices. All automation on a master instance.
For large stable fast network my method is:
- do not report any values that I do not need
- do not report values more often than I need
- do not poll devices very often if they support association
- do not use poll after if the device supports association
- use a zniffer to confirm all is healthy after each change. There are some devices that I have that spam my network by default when certain parameters are set or associate to devices that do not exist in my network so I could not live without a zniffer.
- place controller(s) so routing is minimised on regularly used devices (zniffer require)
- make sure all devices are operational all of the time and there are no nodes on the controller that do not physically exist
The reasons I split my network are:
- My house is not great for RF (zigbee suffers same so it is not just z-wave). This caused lots of multiple hops and that limits the performance of z-wave significantly.
- I wanted regular reporting from some sensors but mixing this traffic in a large network was causing occasional delays.
- I wanted some automation that switched many devices at the same time. There was a significant delay first to last at times. Moving the devices to separate networks with direct connections results in no perceivable delay all of the time.
I can’t give a formula for any of this as everyone’s needs and homes are different but very happy with my z-wave network.
2 Likes
Hi @robmac,
Great insights!
One question: How do you integrate the controllers? Do you have multiple bridges in OH? Or are they connected to each other somehow?
Thanks!
HFM
Nothing clever. Just plug them into USB ports and use normal linux commands to configure. Single instance of the binding has no issue with 2 and possibly more controllers. In this case a Pi4 though it is not stressing that so a lot lesser would do.
You end up with multiple devices with the same node id but different controllers.
The ones names buffer are multiple temperature sensors (Fibaro smart implant) that I wanted more regular and granular temperature readings from. They generate a stream of reports when the temperature of my heating system is changing quickly. The lights and other devices on the other stick are not impacted. Before I split the network the lights would sometimes pause when the heating temperatures were changing quickly.
When adding devices to one controller I remove the other from the USB port. Not sure if there is a better way like disabling in OpenHAB.
I do have the USB on short extension cables about 0.5m long and they are arranged away from each other.
The main hub also has a stick and then uses remote binding to access all other devices.
If I did it again I would name them better so worth considering naming before you start. server 4 and 5 were used in my first go but I removed them when I had tested multiple z-wave USB in a single openhab.
1 Like
Just to be clarify, that is not what I’m saying. This thread diverged a long time back with questions about Zigbee as well as ZWave, and the “use fully certified Zigbee” devices was an answer to the question that Zigbee devices don’t follow standards where ZWave do.
As you rightly pointed out, ZWave works just fine (most of the time - just like anything else 
).
2 Likes
Thanks for the big explanation!
I have 70 devices and have to consider, what to do next.
HFM
Before you jump in and assume you need to split.
I used to run 150 on a single stick and it was stable but I had to make compromises to make it good.
The issues were:
- I had to reduce the reporting to below what I needed for my automation to work.
- Where I wanted to switch many devices I had to program a small delay or the network clogged and you got one almighty delay in the whole network.
- Poor battery life for some sensors. I assume because of the longer awake time due to many hops and other delays.
The second issue was most evident where some of the devices had 3 hops. A round trip could be as much as 0.3s for some of the devices. My outdoor lights had 6 devices with 3 hops a further 4 had a couple and only 4 had direct. As each device also sent a power and energy report immediately after switching the single controller could get a little busy. Without a programmed delay sometimes energy reports would be lost and a long timeout pause would be experienced.
A limiting part of z-wave is each controller has only two receive buffers (one report receiving one processing max) and can only handle one outbound command at a time. A simple calculation on my outdoor lights using data from zniffer is that it would normally be about 3s to turn on/off all of the lights if the controller was not having to also handle reports back to the binding.
This design feature is true of all z-wave sticks from all manufacturers and there is no support for multicast commands like ZigBee has.
The received reports have priority over the outbound commands to reduce the risk of reports getting lost but there is no way to prevent loss if the controller is too busy for an extended time. I have tried to understand how the issue escalates to a large timeout pause but have found it impossible to debug.
I addressed the issues by adding a second controller to handle busy sensors leaving the other to handle the outbound commands and by splitting groups commonly controlled at the same time across multiple sticks. The splitting to many servers was to reduce the number of hops as my house has very poor RF transmission.
If these are the sorts of issues you are seeing then a zniffer is definitely a very good investment at around 25 £,$ or € plus shipping using a UZB3.
The downsides to my approach before everyone jumps in and gets into trouble.
- Complexity. I will be moving some UZB so more of the servers have multiple and some servers can be retired.
- You can not associate using z-wave across different networks so more programming.
My solution is an expensive and complex way. The other way is to reduce hops by placing the controller in a good place, reduce reporting/polling and program a small delay intentionally when switching many devices to avoid a huge delay and loss of reports.
1 Like
I will say I had a similar experience with the cheap chinese Neo Coolcam Z-Wave devices even though they are certified. Avoid the cheap devices generally.
2 Likes