Group of 8 Z-TRM2 modes sometimes only updates part of the group

Looking over this some more, and based on this log, I’m not sure there is actually a problem at all.

Your network is VERY busy, and some devices are taking a long time to respond. This is blocking traffic. If we look at the first set of commands that come in -:

Here we see that just before the commands are received, a request (transaction 1) is sent to node 97. We don’t get the response to this for a few seconds, and then the final report is received after 5 seconds, and the next command (transaction 2) is sent. I suspect that there is quite a queue of transactions waiting, and these commands are just at the bottom of the queue.

If we look at the next set of commands -:

Here we see a similar problem - node 97 is again playing hard to get, and in this case, the transaction fails (we see transaction 3 with the NO ACK). The next transaction is again sent within a few milliseconds.

So, from this, I don’t think there’s a problem with the binding. I think that there is a LOT of traffic on your network, and some devices are slow to respond which is really killing things.

This is probably also why the problem doesn’t always appear - if the network is working ok, then there is no problem.

I would try and look over the logs to see if your system is configured properly. As I mentioned earlier, node 30 is looking like it has problems -:

Here we see a lot of humidity updates received in the space of a few 10s of milliseconds. This sort of issue may be caused by the device being incorrectly configured (maybe you have multiple associations configured - this is a common reason for multiple messages) or maybe the device needs resetting. My guess is it might be the latter as we also see a LOT of UV messages and I don’t think there are likely to be this many association groups! -:

Thanks for looking into this.
Yes, my network has grown ~73 nodes now.
I really should pay more attention to unnecessary traffic.

I power cycled node30, and grep’ed my log for ultra(violet), a sensor I don’t use at all.
I never linked that channel, but that does not stop the node from sending it.

Loggs show there were quite a lot of ‘ultraviolet’ messages from Multisensor 6’s so a changed parameter 101 from 241 to 96, and that did shut them up.

Will check other parameters I’m not using as well and report back.