You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently being a bit puzzled by the lack of monitoring information of zigbee networks that's readily available to the non-expert. Every time you have a problem with a device, community help points to potential issues with your zigbee network (e.g. congestion, routing errors, interferences) as a potential source of the problem but, in most cases these issues are extremely difficult to discard or confirm.
I don't know about you (am I missing tools?), but for me the only source of information is the zigbee2mqtt/log directory. This has proven useful (though very time consuming) for debugging specific occurrences like "I pushed this button at 19:47 and the lights didn't come up; clicked again and it worked", but I find two issues with this approach: 1. you still find issues where two identical commands produce two different effects and 2. this is a very narrow view of the network quality itself.
I would like to be able to see a bit more of my network. Would it be very difficult to add some counters with some time series statistics? These could be recorded as sensor data in HA and displayed in widgets:
How many messages per second are flying around?
How many of these are errors or warnings?
Which ones are the last (e.g.) 20 errors?
(if they exist) How many packets are being dropped and resent?
(or any other that makes sense)
I suspect these might be relatively easy to add, with very low impact on performance, and one could write a whole chapter about which values are reasonable and which ones are clear signs of issues.
What do you think?
I suspect part of this could be pushed to MQTT itself, but please consider that an MQTT broker might be used for non-zigbee devices, and it might be too late for MQTT to detect dropped messages, for instance. One could also create an automation that's triggered for each message and do statistics there... but that would be A LOT of automation triggered, slowing down the whole thing.
Just to add a bit here.
For past 2-3 days I was having some issues with zigbee devices. They worked but there was quite a lag. Restart of Z2M didn't help, mqtt broker seemed great. After staring for a while at home view I realized that one of temp sensors shows there way to often. I got to Settings/Health and saw that it was spamming the mesh. As soon as I took it down that lag was gone. I've been trying to figure out some way of checking this and possibly notify me but... I don't see that health info exposed either to HA or MQTT (yet Z2M clearly knows this as it can show m/s value in red).
So yes some kind of health related info should be exposed somehow (too bad I'm not familiar with TS/JS to try to fix that)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all,
I am currently being a bit puzzled by the lack of monitoring information of zigbee networks that's readily available to the non-expert. Every time you have a problem with a device, community help points to potential issues with your zigbee network (e.g. congestion, routing errors, interferences) as a potential source of the problem but, in most cases these issues are extremely difficult to discard or confirm.
I don't know about you (am I missing tools?), but for me the only source of information is the zigbee2mqtt/log directory. This has proven useful (though very time consuming) for debugging specific occurrences like "I pushed this button at 19:47 and the lights didn't come up; clicked again and it worked", but I find two issues with this approach: 1. you still find issues where two identical commands produce two different effects and 2. this is a very narrow view of the network quality itself.
I would like to be able to see a bit more of my network. Would it be very difficult to add some counters with some time series statistics? These could be recorded as sensor data in HA and displayed in widgets:
I suspect these might be relatively easy to add, with very low impact on performance, and one could write a whole chapter about which values are reasonable and which ones are clear signs of issues.
What do you think?
I suspect part of this could be pushed to MQTT itself, but please consider that an MQTT broker might be used for non-zigbee devices, and it might be too late for MQTT to detect dropped messages, for instance. One could also create an automation that's triggered for each message and do statistics there... but that would be A LOT of automation triggered, slowing down the whole thing.
Beta Was this translation helpful? Give feedback.
All reactions