(EDGE Driver-Mc) Custom configuration for report interval attributes of the IASZone and OnOff clusters

Custom configuration for report interval attributes of the IASZone and OnOff clusters

Drivers modification to reduce the ReportAttribute zigbee messages traffic on the devices and also try to reduce the battery consumption of these types of devices.
It also reduces the work of the hub to handle these messages and emit the events repeatedly.

I have created new drivers versions with a custom configuration of the maximum reporting intervals for:

  • attribute: zcl_clusters.IASZone.attributes.ZoneStatus.ID
  • attribute: zcl_clusters.OnOff.attributes.OnOff.ID.

This default setting of 300 sec generates a lot of traffic and load for the hub since they are used in most devices (80% ??) in a standard home automation installation, Motion Sensors, ContactSensors, waterSensors, switches, multi-switches, dimmers, plugs, bulbs and others.

As the devices already in use are configured with the default values, I have created a preference with the default value equal to the default value of the libraries, 300 sec and a range from:

  • 300 sec to 3600 sec for IASZone.attributes.ZoneStatus
  • 300 sec to 1200 sec for OnOff.attributes.OnOff
    This is used to custom re-configure the devices configuration without having to uninstall and reinstall them.
    (The maximum range of 1200 sec in the on-off attribute is because the hub firmware has a routine that reads this attribute approximately every 21 minutes before marking it offline and makes ranges higher than 1200 sec useless.)

Some battery-powered models must be woken up to accept the new configuration, others, such as the Samjin, always accept it at any time.

I have tested and observed the logcat drivers of contactSensor, Motion, bulbs, switches, multi-switches with ranges of 1200, 1800 and 3600 sec for 4 weeks and everything works perfectly, without showing itself offline at any time and trying hub and driver resets .
It has also worked correctly after several updates to the Hub’s beta firmware, 49.9, 50.6, 50.7, 50.8 and 50.9

The values of the monitored attribute are also modified with custom values so that the Health Check continues to function correctly with 1.5 times the maximum configured interval.

The use of this custom configuration is completely optional and voluntary. When the new version is installed, it continues to work with the default values that the device already has configured.

This custom configuration is intended for those users who:

  • They have many zigbee devices and their network can be slow due to the number of periodic report messages they support and the hub is overloaded with work processing many repetitive messages and events.
  • They have devices, contact sensors, movement, that consume a lot of battery and they want to try to see if their duration improves.

When modifying the value of the reporting interval, try to modify each device of the same driver, waiting approximately 1 or 2 minutes between changes so that all devices do not report at the same time and then all are silent at the same time.

It is also not mandatory to change all the driver devices, only the ones we want and each one can be modified to a different value.

I have tried several different intervals, they have all worked perfectly and I have left them all at the maximum intervals to reduce traffic and battery consumption as much as possible.

My Samjin multipurpose batteries last about 6 months, the Samjin motion sensors last approximately a year and a half, we will have to wait and I hope they improve

In the preference I have put a warning and how to use it.

β€œIF YOUR DEVICE & NETWORK WORK FINE THEN DON’T TOUCH. Set Device Interval Report (300 to 3600 sec). Smartthings Default=300. Longer intervals reduce zigbee Network traffic, Hub work and Battery consumption. NEED WAKE UP DEVICE WITH Open-Close TO ACCEPT NEW VALUE. Restore default before Driver Change”

It is important: If you are going to change your device to a different driver and you have modified the reporting interval, then it is desirable that before changing to the new driver you modify the reporting value to the smartthings default (300 sec) so that it works correctly in the new one. driver.

Theses are the new driver version published that will be updated automatically.

I still have to implement it in water leak sensors and smartthings button, I don’t have devices to test, but I will do it.
The smoke and CO sensors also report very frequently, 180 sec, I will implement it with a smaller range, 180 to 600 ?? and I will test it a lot before implementing it

Any questions or errors please tell me.

I hope it reduce the load of the hubs with many devices and zigbee drivers

────────────────────────────────────────
  Name Zigbee Contact Mc
  Version 2023-10-07T12:52:04.211502651
────────────────────────────────────────
────────────────────────────────────────
  Name Zigbee Light Multifunction Mc
  Version 2023-10-07T12:52:37.80597446
────────────────────────────────────────
────────────────────────────────────────
  Name Zigbee Switch Mc
  Version 2023-10-07T14:07:04.934961209
────────────────────────────────────────
──────────────────────────────────────── 
  Name Zigbee Motion Sensor Mc
  Version 2023-10-07T14:07:28.346553877
────────────────────────────────────────
────────────────────────────────────────
  Name Zigbee Multi Switch and Child Mc
  Version 2023-10-07T15:03:58.666025839
────────────────────────────────────────
────────────────────────────────────────
  Name Zigbee Switch Power Mc
  Version 2023-10-07T17:20:57.666203355
─────────────────────────────────

@Subramanian_Swaminat
This version of the zigbee switch power Mc has a new profile with a preference to choose the reading interval from 30 to 180 sec, assigned to devices that need a periodic reading of power and energy.
On these devices you cannot increase the On-Off cluster report interval, since this 300 sec report is needed to restart the periodic reading interval and it does not have that preference in the profile

4 Likes

Many thanks @Mariano_Colmenarejo, you are a star. I have set it to 30 though I preferred to have it less than 30 if possible. I can live with this, thanks.

Modified range from 5 to 180 sec

───────────────────────────────────────────────────
 Name         Zigbee Switch Power Mc
 Version      2023-10-07T17:20:57.666203355
───────────────────────────────────────────────────

@Mariano_Colmenarejo, All good, thank you very much. Sorry to ask but if we start from 5, will it be ok?

As Mariano said, in a previous post:

The shorter the reporting interval, the more traffic you will have on your network which can cause other devices’ messages to not be able to get through. And the more battery you will use up on the device that is reporting.

As a separate issue, if you set the reporting interval to be shorter than the cooldown interval on a motion sensor, that can get everything out of whack.

It’s up to you, but honestly zigbee and zwave devices on mesh networks are just not designed for frequent reporting. (The official Z wave standard says one command every 30 seconds is the minimum.) If you really need five second intervals, it’s better to look at Wi-Fi mains powered devices. Just sayin’ :man_shrugging:t2:

(I have seen people put themselves into a doom loop because the intervals were too short. Device A isn’t reporting the way they want, so they drop its interval to 10 seconds or less. The increased traffic on the network means that other messages aren’t getting through, so now device B looks like it’s not reporting effectively. So then they drop the reporting interval on device B as well. Now they have two devices flooding the network and the QOS on other devices starts going down. Eventually they have a network where almost no alert messages can get through. :disappointed_relieved:

There’s no problem with wanting frequent interval reporting from a device, as long as you use a protocol that supports that well. Like mains powered Wi-Fi.)

4 Likes

@JDRoberts, Understood and thanks - Will stick to the 10 seconds till I get a Wi-Fi plug.

1 Like

I wish some of the drivers had this functionality. I definitely have one device which is reporting information way too often, but its not exposed in the ST driver.