I noticed two differences between your z-wave network and mine, which might be comparable, because I also have a small house.
While most of my devices are z-wave, they have many more neighbors - so I have more powered devices that function as repeaters.
There are very few route changes in my devices.
These two combined seem to make my response times much faster, which is why I am in no hurry to replace my z-wave devices with newer z-wave+ versions ....
Here's a small snapshot from my z-wave table just focused on non-repeating sensors (FLiRS devices):
There's definitely some sort of weird interference going on but hard to diagnose over a forum. Curious what your line voltage looks like over time. Could be causing momentary blips as the voltage drops which throws the mesh into chaos. Something is triggering all those route changes. You're using the stock power adapter that came with the hub right?
yes, standard. I do not like to change anything, as the manufacturer clearly takes into account more factors that affect the operation of the device than I can detect due to limited knowledge.
and yet the problem is not the position. half of the devices are not responding today. in the image below, you can see that polling them does not result in a response. the photo below shows the z-wave module for the raspberry. the antenna module is represented by a short corner-shaped track with a 3.5 cm long edge. in this case, all devices are polled directly. yet I think the problem is in the hub itself. I'm desperate already. will have to change the system.
friends, thanks to all who responded. i found the problem. the problem was in the thermostats. they had to report the position of the peregory if she changed position by more than 10%. everything worked fine until the partition takes position 0! thermostats start reporting position 0 every minute! they occupied the entire transmission channel and the network fell. after disabling this function, everything works like clockwork. in general, Eurotronic devices have many problems, I informed the manufacturer, but they ignore me. thanks to your tips, I found the problem, although I was desperate.
I have 3 pcs Eurotronic TRVs and my HE z-wave network problem is very similar to yours. But I don't see the in the z-wave logs extensive communication to the TRVs when the valve is closed.
if the settings for the message about the valve position is 0, then this function is disabled, in your case it is already disabled, do not worry. I would advise you to watch the messages on the network, some device takes up the entire airwaves and other devices lose connection. there are many reasons for this. for example, air quality sensors from Eurotronic also occupied my air. if they have an association - with a thermostat - the network will fall. if they have the maximum sensitivity set to all values (temperature, humidity, carbon dioxide, vok) - the network will fall. since the sensor cannot be determined at the limit values and sends a lot of telegrams. I have already reported the problem to the manufacturer. this is what i found from me. The way out is to use the rule machine and my driver with the temperature reporting function to associate the sensor and thermostat. set the maximum sensitivity for temperature on the sensor and organize a delay in sending to the thermostat. Decrease the sensor sensitivity for the rest of the parameters by one step. this is what helped me. The network has not fallen for a very long time and everything works fine.
No.
The TRV's automatic valve reporting has been working ON ( 1% change!) in the last 2-3 years.
Valve position is a key parameter to monitor for me, looking at the graphs I see how the TRVs are performing, is the regulation in the 'active' zone ( in cold wether never be 100% or 0% opened).
I disabled the TRVs automatic valve reporting this morning to test whether it will affect the terrible z-wave performance that I suffer in the last 2..3 weeks.
My hub Z-Wave logs page does not show any excessive network overload. I don't know whether there is no z-wave network congestion, what I am saying is that i do not see it on HE z-wave logs page.
In addition to the 3 x Eurotronic TRVs, I have also 1 x Eurotronic Air Quality sensor and 1 x Eurotronic temp/humidity sensors (all z-wave). The communication activity that I see on the z-wave live logs is nothing, I would say z-wave net is silent if compared to my Zigbee network activity when I made stress-tests using the infamous Tuya Air Quality thing (1-2 spammy messages per second !) And despite the overload, there are no noticeable delays in processing sensors signals (motion sensors) and actuators (zigbee switches).
The only logical explanation for me is that there may be a lot of Z-wave packets that we do not see on the HE z-wave logs page
So I suppose as a next step I will need a z-wave sniffer or even an SDR dongle, at the moment I am 'blind' in regards to what happens on 868.42 MHz. Z-wave performance can't be so bad, no matter the relatively frequent reporting intervals setup for temperature and humidity and air quality sensors.
zigbee network is not sensitive to channel congestion, according to my observations, unlike z-vave. I do not claim that I am 100% right, this is just what I saw and what helped me. before that, I was in despair and even wanted to change the system to a hotematic, but after observing what was happening, I found these patterns, after correcting which there are no problems from the word at all. the biggest problem was the associations of air quality sensors, they lay down the network for several hours, and the thermostats still did not receive data from the air quality sensors. this forced me to implement the transfer of the temperature value from an external sensor through the thermostat driver. then I noticed that the air quality sensors very often send measured values, as they are at the border of the measurement, for example 23.5 after 4 seconds 23.6, after 5 seconds again 23.5, etc. accordingly, the driver sent data to thermostats, the delay in sending again improved the quality of communication, but the network still fell once every 2 weeks. further observation showed that the thermostats were active at damper position 0 - the thermostats were sending a value of 0 every minute. when the damper of many thermostats was in position 0 for a long time, the network was loaded with these messages and the network first became slow and then fell. after turning off the throttle position message - everything is fine. It's been a month and everything is working flawlessly.
I believe you're right, this is what happens when an Aeotec aerQ is sending a temperature report to 3 Spirit TRVs, which are associated directly. Not a trace of it in the hub's Z-Wave logs.
The same here, even if the temperature did not change at all it sometimes spams multicast in a high frequency.
The reporting threshold I set for the aerQ is being completely ignored, it only seems to work for the reports to association group 1, have no idea why.
)
