Zigbee Edge Device Driver Removing Reporting Configuration

Should “remove_configured_attribute(cluster, attribute)” remove any existing reporting configuration already sent to a device?

Consider a preference in a device driver called “enable power reporting” which is set to true by default.

During lifecycle events, the reporting configuration is set up using “add_configured_attribute(config)” and sent to the device - all’s well.

The user changes the preference to false, so naturally you call “remove_configured_attribute(cluster, attribute)” which removes the cluster / attribute so that it is no longer sent to the device in subsequent calls to device:configure().

But the device is still configured with the previous reporting configuration, it is not removed, so it continues to send those reports.

I think that it is a reasonable assumption that a call to “remove_configured_attribute(cluster, attribute)” should actually remove the reporting configuration from the device as well?

add_configured_attribute and remove_configured_attribute only take effect when the device is later configured with device:configure()

That is, when you perform the configuration, then before sending the configuration of that attribute, the libraries look in the added attributes table and if it is there, the default configuration values or the one specified in the table when add_configured_attribute was executed will be sent.

If the device attribute is already configured and you run remove_configured_attribute, all you do is remove attribute from the table where the default libraries will look when they have to configure the device.

The configuration of each attribute is saved in the device’s flash memory and will continue to function until the device is reset or a new configuration is sent that is overwritten.

To eliminate a configuration and not send periodic reports, you must send a specific configuration with a value of 0xFFFF in the maximum interval, according to the zigbee libraries.

2.5.7.1.5 Minimum Reporting Interval Field
The minimum reporting interval field is 16 bits in length and SHALL contain the minimum interval, in
seconds, between issuing reports of the specified attribute.
If this value is set to 0x0000, then there is no minimum limit, unless one is imposed by the specification of the
cluster using this reporting mechanism or by the application.

2.5.7.1.6 Maximum Reporting Interval Field
The maximum reporting interval field is 16 bits in length and SHALL contain the maximum interval, in
seconds, between issuing reports of the specified attribute.
If this value is set to 0xffff, then the device SHALL not issue reports for the specified attribute, and the
configuration information for that attribute need not be maintained. (Note: in an implementation using dy-
namic memory allocation, the memory space for that information may then be reclaimed).
If this value is set to 0x0000 and the minimum reporting interval field equals 0xffff, then the device SHALL
revert back to its default reporting configuration. The reportable change field, if present, SHALL be set to
zero.6

2.5.7.1.7 Reportable Change Field
The reportable change field SHALL contain the minimum change to the attribute that will result in a report
being issued. This field is of variable length. For attributes with ‘analog’ data type (see Table 2-10) the field
has the same data type as the attribute. The sign (if any) of the reportable change field is ignored.
For attributes of ‘discrete’ data type (see Table 2-10) this field is omitted.
If the Maximum Reporting Interval Field is set to 0x0000 and the minimum reporting interval field equals
0xffff, indicating a default reporting configuration, then this field SHALL be set to zero upon transmission
and ignored upon reception. 7

On the other hand, when you change a device configuration after it has been configured you have to change the minitorization of the attribute with add_monitired_attribute so that the healtCheck function adjusts the intervals to the new configured intervals.

If you set values that do not send periodic reports, then you have to run remove_monitired_attribute(cluster, attribute) so that healthCheck is not run when no messages are received for that attribute

1 Like

Yes exactly, I guess my assumption was that a call to remove_configured_attribute would check the existing “added attributes table” and update the entry accordingly so that the reporting configuration is removed from the device on the next call to device:configure().

I guess rather than remove_configured_attribute I could simply call add_configured_attribute instead like so:

add_configured_attribute(
        cluster = SimpleMetering.ID,
        attribute = SimpleMetering.attributes.CurrentSummationDelivered.ID,
        minimum_interval = 0,
        maximum_interval = 65535,
        data_type = SimpleMetering.attributes.CurrentSummationDelivered.base_type,
        reportable_change = 360000
)

That would remove the reporting configuration in the device on the next call to device:configure()

I think must be this:

device:add_configured_attribute(
        cluster = SimpleMetering.ID,
        attribute = SimpleMetering.attributes.CurrentSummationDelivered.ID,
        minimum_interval = 65535,
        maximum_interval = 65535,
        data_type = SimpleMetering.attributes.CurrentSummationDelivered.base_type,
        reportable_change = 360000
)

device:configure()
device:remove_monitored_attribute(SimpleMetering.ID, SimpleMetering.attributes.CurrentSummationDelivered.ID)

Also can use this more simple

device:send(SimpleMetering.attributes.CurrentSummationDelivered:configure_reporting(device, 0xFFFF, 0xFFFF, 360000))

device:remove_monitored_attribute(SimpleMetering.ID, SimpleMetering.attributes.CurrentSummationDelivered.ID)

reportable_change value 360000 i do no known if is correct

1 Like

To disable reporting, the spec only says the Maximum Reporting value is to be 0xFFFF. The Min Reporting Value and Reportable Change are to be ignored.


edit: ha, just saw @Mariano_Colmenarejo already posted a text version of this exact text. Sorry to duplicate.

That being said, I’ve seen devices not conform to this and as a preventive measure I’ve always sent Min = 0, Max = 0xFFFF, Reportable Change = 0 to disable reporting.

3 Likes

I have also seen devices that do not comply 100% with these zigbee rules.

There are also devices that do not accept configuration changes outside of the pairing process or if they are devices with battery power and are asleep, they must be woken up, although this does not seem to be the case for this specific device.

3 Likes