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

Developer Programs Writing Edge Drivers
1

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.

Screenshot_20231007-145852
Screenshot_20231007-145852864×1920 150 KB

Screenshot_20231007-145930
Screenshot_20231007-145930864×1920 146 KB

Screenshot_20231007-150000
Screenshot_20231007-150000864×1920 147 KB

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

5 Likes
2

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.

3

Modified range from 5 to 180 sec

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

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

5

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
6

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

1 Like
7

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.

8

How to force the device to be configured with the values established in user preferences in the Mc zigbee drivers:

Because there are devices that only accept configuration changes during pairing or that are powered by batteries and are asleep, there are times that we make changes to preferences that affect the configuration of the device, such as temperature reports, humidity, OnOff, IASZone and others that can be customized in preferences and are not accepted by the device.

Procedure:

  • Set the custom values in preferences that we need.
  • In the App, open the Hub settings menu and set Secure Mode to disabled.

1000013562
1000013562864×1920 45.4 KB

  • In the App click on Add new device and the option to search nearby

  • Put the device in pairing mode.

  • The device will pair with a different network ID, but with the same Name, same device ID and in the same location. No routine or scene will be missed or disabled and the device will be configured with the values established in custom preferences.

  • This would also be valid for devices that do not use Mc drivers, but it will be configured with the default values, if the driver does not have a custom configuration established.

29 Mar, UPDATE:

I have seen that reinstalling the device without uninstalling it first does the configuration but I don’t see that it calls the init and added lifecycle. It only performs infoChanged and doConfigure.

This can be a problem in devices that need to perform procedures in those life cycles, for example, the Aeotec multipurpose sensor configures the acceleration cluster and its attributes in the added life cycle and therefore when performing this procedure it is not possible configure those attributes and it becomes inoperative to show acceleration and three axes.
Others devices perform battery voltage configuration or assignment of end points and components in the init lifecycle.

To solve this it would be necessary to perform a driver change, to zigbee Thing Mc, for example and then return to the original driver.
With this, the added and init life cycles will be re-performed, even if the configuration is not carried out, it will retain the one made in the reinstallation.

You won’t miss any routine or scene

@nayelyz Is this behavior expected or perhaps it would be better not to allow the reinstallation of devices without uninstalling them first, as happens with zwave.? With the risk that the device will partially inoperative.

Activating secure zigbee mode on the hub does not prevent the devices from being reinstalled without uninstalling them, it works exactly the same.

3 Likes
9

Hi, @Mariano_Colmenarejo. In this procedure, users need to factory reset the device but not delete it from ST and re-pair it to execute doConfigure, right?
Also, it is to make the new configuration come in, but not in case the device has an issue, correct?

Are you referring to the ST drivers here?

1 Like
10

Hi @nayelyz

Yes, it is a procedure that has always been used in zigbee devices, which allows devices to be reinstalled without having to uninstall them.

I am referring to a specific device, which is configured the custom attributes in the added life cycle, but there are more cases.

Edit:
In the multipurpose sensor it has already been changed fron added to doConfigure in the stock driver

In fact yesterday I saw a PR for aqara motion sensor, which configures custom attributes in the added lifecycle and they ask if could change it to doConfigure due to this same problem

2 Likes
11

Thanks for the reply, @Mariano_Colmenarejo
I asked the engineering team and they confirmed the following:

  1. It is expected that you can reset and rejoin a device without deleting it first.
  2. Only infoChanged and doConfigure are expected to execute in this scenario
  3. added or init won’t execute because the device instance already exists
  4. To avoid inconveniences, it’s suggested you set up all configurations for the device in the doConfigure lifecycle
2 Likes