Default attribute values for generated devices

[ffenix113]

Hello Koen,

For zigbee_home I am currently adding Electrical Measurement cluster (ZCL 4.9, cluster ID 0x0b04) with DC measurements by

• Adding MeasurementType and setting its bit 6 (DC measurement)
• Adding DCVoltage, DCCurrent, DCPower (ids 0x100, 0x103, 0x106)
• Adding DCVoltageDivisor, DCCurrentDivisor, DCPowerDivisor (ids 0x201, 0x203, 0x205)

As other attributes are optional, and most have defaults - I assumed that it would be good to go by just providing the attributes that I needed.

Unfortunately, while trying to pair such custom device with Z2M it results in some issues:

• Z2M tries to read & setup reporting for attributes that are not available (RMS Current/Voltage, AC Voltage/Current Multiplier/Divisor, etc..)
• While converting Electrical measurement value from such device the factor is not being calculated "correctly", as it tries to use attribute that is not present and just returns no factor (== 1).
• If I provide attributes for DC(Voltage|Current|Power)Divisor - they will not be used until they are explicitly read from Developer console. After the read - they will be used to properly modify the values of the reported attributes (if previous issue is ad-hoc fixed by const multiplier = ... || 1 and same for divisor).

Both issues are resolved by adding attributes with "dummy" values, but I think that better approach would be to use default values if attribute is not present. And for reporting missing attributes - Z2M could know which attributes are present and set up only those.

Based on ZCL 2.3.4.2 I understand that if the optional/deprecated attribute(s) is missing - default value should be used instead:

If the specification text of a cluster depends on the value of an optional or deprecated variable (e.g. attribute, command field, etc) of the same cluster, then the variable SHALL have a well-defined default value that
SHALL be used in place of the missing variable.

As I understand, the solutions could be:

• Have some table of attribute -> default value, which will be used somewhere around here, which will be used if no attribute is present. The getAttribute signature could be expanded to include additional argument returnDefault: boolean = false or similar to preserve original behavior, but allow getting default value, if specifically asked for.
• Finally go with fetching available attributes for cluster, as discussed here. If it is already done (I have not checked this) - use this information to properly do reporting.

For reference here is PDF of ZCL specification that I use to do cluster implementations.

---

This probably is an issue only for generated device definitions. So having default values usable in Z2M would (or could) simplify development of custom devices (especially in situations where Zigbee SDKs do not provide complete/correct implementations of clusters and attributes. Not pointing any fingers...).

I wanted to have some opinion on solution for this, and if this is an issue for Z2M at all, as I was able to mitigate the issues, but it requires manual work to check errors and iterate on the solution.

Edit: also it does not seem to be setting reporting for DC measurements as well, in addition to issues described above.

[ffenix113]

Issue with DC attributes not being read and reporting not being set are probably genuine issues, but I expect only because energy meters are mostly for AC, so DC meters were not added.

[Koenkk]

I think the problem here is that the definition generator doesn't provide any specific arguments which match with the device MeasurementType. I think reading the value there and based on that pass the correct args to m.electricityMeter should solve the issue (not configuring e.g. rmsCurrent and configure e.g. DCVoltage)

[ffenix113]

Created MR for it: #11422

I also noticed that exposed values were not correctly tested, as they will not include endpoint, so I made MR for it as well: #11423