Since it is some days ago that I promised to write some lines regarding my journey to improve my Z-Wave network and trying out things, here it is. I was trying to make the story short 
- but it is still long and a lot to read. Sorry for that, if there are questions please feel free to ask further into details. If the moderators thinking this should go somewhere else please do let me know.
Setup before the changes:
500 series Z-Wave Network with ~100 nodes, 1 ZWave Stick in the 2nd upper floor together with Openhab server. House is with basement (so 4 floors to reach), in each floor I have active Z-Wave nodes (rollershutter, lights and smart plugs). At that time I used the Openhab-Z-Wave Binding.
I knew the placement of the ZWave stick wasn’t perfect in the 2nd floor of the house, but there was no other better positions possible easily without effort.
It was working some times good and reacted fast and some times it was quite slow in reacting when lights wanted to be switched waited for seconds, which made me think why I see this behaviour.
Actions to improve:
Try 0:
My first try was January 2025 to exchange just the stick of the 500 platform (Aeotec) against a new stick of the 700 platform (Aeotec). I was thinking: new stick/platform will be better and faster. I learnt later, the stick wasn’t the issue.
For the migration of the stick I used already a separate Home-Assisitant instance on a RaspberryPi and the Z-Wave-JS-UI plugin to use the NVM Backup/Restore function. I wasn’t setting up HomeAssistant completely, I just used it to perform the NVM backup/restore.
Besides the described workaround of this initial thread something wasn’t working correct (maybe also the NVM backup/restore wasn’t completely fine at that time - read something in forums too), since the restored 700 stick contained all nodes but these nodes were switching periodically Online/Offline in Openhab after the restart with the 500 backup-restored to the 700er stick. After some readings in forums about known firmware issues of the 700 platform (unresponsiveness and massive delays in large networks) I was switching back to my old 500 stick.
I repeated that switch several times in the first half of the year but without success.
Try 1:
Step 1:
In late sommer I used a Zooz-800 Z-Wave stick. Same approach with my separate Home-Assistant instance for NVM backup/restore. This time the approach worked and I was using the 800er stick directly with my Openhab server using the Openhab-Z-Wave binding. From the performance/reaction speed it was a little bit better, but there were still situations when it was slower than usual. I knew that also the 800 series had firmware issues like the 700 platform, but this got/gets improved slowly with new firmware versions - but is still not completely solved as to my current knowledge.
Looking into the logs I found out, that my smart plugs in the basement (i.e. dryer and washing machine) were sending quite often informations about power consumptions even I had configured them different and partially even switched off reporting. And everytime these smart plugs were switched “On” the Z-Wave network reactions got slower. Because of the massive amount of messages, which had to go through all the floors to the top floor passing probably a lot of different nodes and blocking them on their way and making the network quite slow.
Step 2:
Then I decided to give the approach of a separate Z-Wave-JS-UI instance a try and to switch to the Zwave-JS-UI binding of Openhab instead of the Zwave-Binding from Openhab. I was setting up a Raspberry with snap and Zwave-JS-UI as my Z-Wave-JS-UI server instance.
The migration in Openhab itself wasn’t that easy and quite time consuming. Since I make intensive use of scenes I needed to adapt my rules code appropriate (a lot). The Contact items of the windows needed to be re-worked using proxy-items since with Z-Wave-JS-UI binding these are just switches. And also the rollershutter were not there at that time (now in Openhab 5.1. rollershutters are available in the Zwave-JS-UI binding) so I had to change and adapt it to Dimmer at that time and accept the disadventages of this approach.
During the migration I made intensive use of the functionality to download the item definitions to clipboard, manipulating and assigning the new Zwave-JS-UI channels outside of Openhab and loading them back as Items from DSL definitions. Until all was fine it took a while but with the files I had a good basis to repeat failed exchanges easily again.
Having this sorted out and running I was placing the Zwave-JS-UI instance (the raspberry with the Z-Wave stick) to the ground floor, which gave already a better responsivness because of better positioning. And with Zwave-JS-UI it is much easier for a nooby like me to inteprete the logs and to see the amount of hops and status of the Z-Wave network. With a dedicated 800 series repeater in the 2nd floor and few priority routes defined in Z-Wave-JS-UI I got quite good response times now. Still had the known issue with my smart plugs and their reporting issue, but this wasn’t influencing the timely reactions of the Z-Wave nodes that much like before.
Try ZWA-02:
Trying out the ZWA-2 device as Zwave-Stick. (used again Zwave-JS-Ui and NVM Backup/Restore functionality). Due to the huge antenna of ZWA-2 I was thinking this would made a lot of things even better. But in my setup it was giving no better results in regards to lesser amount of hops or more stability or even faster reaction times. So switched back to the 800 series Zooz stick.
Step 3:
After some research I decided to invest into new smart plugs based on the Zigbee protocoll to take the reporting hassle out of Zwave. I exchanged some of the heavy reporting not really configurable Z-Wave smart plugs with Zigbee smart plugs and setup an additional Zigbee network using Zigbee2MQTT and the appropriate binding of Openhab.
From here both networks(Z-Wave & Zigbee) are really reacting fast and stable - all is fine so far and I am happy. (and my wife too).
Setup after the changes:
800 series ZWave Network with ~85 nodes, 1 Zooz ZWave Stick on the ground floor together with the Zwave-JS-UI server (RaspberryPi). 800 series Zwave Repeater in the 2nd upper floor with few defined priority routes in Zwave-JS-UI. Zigbee network via Zigbee2MQTT with the appropriate Openhab binding with ~15 nodes. Zigbee stick located in the 2nd upper floor serving the complete house - no issues.
Learnings:
- Reporting functions for measurement of consumptions need to be used carefully in ZWave networks. Smart Plugs with wrong firmware - when these reporting functions are not really configurable and you are not able to switch it off - might overflood your network with messages and make it slow and unresponsiveness and you don’t know or see it without deep analysis.
- The placement of the stick is quite important and can improve the network much more than a change of the stick (500 series to 700/800 series).
- The 500-series is good and stable and in big networks it might perform better than the new 700/800 series with the still existing but mitigated firmware bug, which leads to unresponsiveness and delays sometimes. (seems an issue especially in large networks). My opinion now: If you don’t need LR and you have a replacement 500 stick as a reserve there is no need to switch to a new 700 or 800 series sticks.
- The switch between different platforms is quite easy now with a NVM Backup/Restore using ZWave-JS-UI.
- With the possibilities of using Zwave-JS-UI binding in Openhab and also the Zigbee2MQTT binding and their maturity now you overcome the in the meantime slower development cycles of the native Zwave/Zigbee Openhab bindings, which does not support always the newest hardware and their features/firmware immediately.
- Installing and configuration of additional Zwave-JS-UI Instance and Zigbee2MQTT with MQTT brings additional effort for setup & configuration (just once) and maintenance activities which are higher than using the native Openhab bindings for Zwave and Zigbee.
- You need to make sure, that the Zwave-JS-UI instance gets allways online earlier and operable than the Openhab Zwave-JS-UI binding accessing the Zwave-JS-UI instance - especially in case of unforseen power outtage and restart.