Zigbee end device publishes too frequently

[MattPellegrini]

I have recently added a Sunricher Dimmer to my network and it floods the zigbee2mqtt service log with messages such as shown here.

When the state of the dimmer is "OFF" the messages are published about every 10 seconds and when the state is "ON" the rate increases close to messages every second.

This is the first device I've added to my network that publishes messages at such a frequency, so I have some questions/ concerns. (For what it's worth, I also have many hue bulbs, trådfri bulbs, aqara motion sensors and temperature sensors and door contact sensors on the network.) The messages seem to be triggered by voltage changes, but sometimes no state changes, such as in the below, so it may just be periodic.

Dec 28 08:28:14 zigbee npm[2799]: Zigbee2MQTT:info  2020-12-28 08:28:14: MQTT publish: topic 'zigbee2mqtt/kitchen_counter_dimmer', payload '{"brightness":117,"current":0,"energy":0.79,"linkquality":6,"power":0,"state":"ON","voltage":6.8}'
Dec 28 08:28:14 zigbee npm[2799]: Zigbee2MQTT:info  2020-12-28 08:28:14: MQTT publish: topic 'zigbee2mqtt/kitchen_counter_dimmer', payload '{"brightness":117,"current":0,"energy":0.79,"linkquality":9,"power":0,"state":"ON","voltage":6.8}'
Dec 28 08:28:14 zigbee npm[2799]: Zigbee2MQTT:info  2020-12-28 08:28:14: MQTT publish: topic 'zigbee2mqtt/kitchen_counter_dimmer', payload '{"brightness":117,"current":0,"energy":0.79,"linkquality":9,"power":0,"state":"ON","voltage":6.8}'
Dec 28 08:28:15 zigbee npm[2799]: Zigbee2MQTT:info  2020-12-28 08:28:15: MQTT publish: topic 'zigbee2mqtt/kitchen_counter_dimmer', payload '{"brightness":117,"current":0,"energy":0.79,"linkquality":9,"power":0,"state":"ON","voltage":6.8}'

1. Should I be concerned about this frequency of publish on the zigbee network?

2. Should I be concerned about this frequency of publish on mqtt?

3. Could either 1 or 2 above slow down the network as a whole? I seem to notice sometimes there is increased latency between light switches and bulbs where the call traverses zigbee2mqtt, but I'm unsure if this is related or not. I'm curious to learn what more knowledgable people think.

4. Can the publish rate be modified?

I'm a competent developer, but new to zigbee and mqtt.

[Koenkk]

The publish rate can be decreased indeed. Can you provide the debug log of this?

To enable debug logging set in configuration.yaml:

advanced:
  log_level: debug

[MattPellegrini]

https://pastebin.ubuntu.com/p/x2S8hzJMTM/

Captured everything from the restart, but here are some useful line numbers:
0: start-up
599: Calm after restart, shows only the dimmer messages, while the dimmer is "OFF".
614: Turn the dimmer "ON", messages increase in frequency.

Let me know how I can help further and thanks for taking a look.

[MattPellegrini]

I notice the zigbee messages seem to roughly loop through attributes and the mqtt publishes the full set of attributes each time.

@Koenkk When you say the rate can be decreased, do you mean the mqtt messages or the zigbee messages?
Do you know if this frequency of messages a cause for concern on the zigbee network? I'd like to buy more of these dimmers, but not if having ~5 of them on the same network causes too much noise.

[Koenkk]

@MattPellegrini the zigbee one. This can now be done much easier with Zigbee2mqtt 1.17.0. Open the frontend (https://www.zigbee2mqtt.io/information/frontend.html) and click on your device. Next go to reportings (if this is empty clear the "gears" icon in the about tab once). Now start changing the min rep change until it stops spamming.

[MattPellegrini]

Thanks very much. This was helpful to the point of resolving the issue.

Do you have a good reference for learning some of the zigbee protocol? Google searches lead me to the very dense pdfs, the most comprehensive of which is probably the zigbee alliance protocol spec, but I'm curious if there's another, more accessible resource to start learning about clusters, attributes etc.

The UI works well, it was my first time seeing that. It would be nice to add a mouse-over explaining each of the columns, but I think I've understood, correct me if I'm wrong, I've printed these below for others.

I now also understand this is a generic zigbee issue, so I'll rename the GitHub issue to reflect that in case it's useful to others searching for similarly noisy logs.

For posterity, here are what each of the columns mean in case someone else is looking for a fix here:

• Min rep interval - The minimum number of seconds that should pass before publishing another message for this attribute.
• Max rep interval - The maximum number of seconds that should pass before publishing another message for this attribute.
• Min rep change - The minimum amount the attribute should change by before publishing a message for this attribute. Not that this is the byte value and so not necessarily corresponding to the implied units of the attribute.
  • e.g. If the attribute is voltage. To make a required change of 10v, you need to know what value your sensor uses to represent 10v, likely it's measuring to 1dp accuracy at least, so 100 would be a good start. You can see the value sent by your sensor and the corresponding 'parsed' value in the debug logs. Finally, you can set this to the max 2-byte value 65535 to disable reporting of this attribute since a change by this amount would not possible.

[timoline]

I was also very curious what these values ment...
This is a good starting point for some documentation