Active power channel (supported attribute) now detecting as total active power (unsupported attribute)

[baku104788]

Older versions of OH 2.3 allowed power usage monitoring on Samjin outlet. This was coming via 'active power' channel in 2.3 and is now showing as 'total active power' in 2.4 fails as an unsupported attribute.

OH 2.3 example:

2018-12-20 18:43:53.147 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [Electrical Measurement: 57472/1 -> 0/1, cluster=0B04, TID=D1, records=[ReadAttributeStatusRecord [attributeDataType=SIGNED_16_BIT_INTEGER, attributeIdentifier=1291, status=SUCCESS, attributeValue=19]]]

OH 2.4 example:

2018-12-18 08:00:34.326 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [Electrical Measurement: 3969/1 -> 0/1, cluster=0B04, TID=F5, records=[ReadAttributeStatusRecord [attributeDataType=null, attributeIdentifier=772, status=UNSUPPORTED_ATTRIBUTE, attributeValue=null]]]

'Active power' channel is now detecting as 'total active power' and no longer working as 'total active power' is an unsupported attribute.

Configuration

Coordinator:
Confirmed on both telegesis and Ember EM35x coordinators to have the same result.

OH Version:
2.3 worked, 2.4 failed. (exact version between is unknown where this stopped working.

OS:
Ubuntu Linux 18.04.1 LTS

HARDWARE:
Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz, 4 cores

MEMORY:
39.95 GB used / 6.30 GB cached / 47.07 GB total

JAVA:
zulu-8 (8.33.0.1)

[cdjackson]

There is no change in the source since 2.3 and 2.4 - ie it hasn't been changed since it was first added.. Probably what is happening is that the reporting configuration is not being set, so the binding is polling. Polling and reporting are using different attributes - and this has always been the case (it's a bug, but it's always been there).

Please provide a log that shows what is happening - not just the single line that shows the data.

[baku104788]

Attached is a copy of the working log and not working log.

working.log
notworking.log

[cdjackson]

Thanks. This demonstrates my point - both logs show the same thing -:

working -:

2018-12-19 20:04:51.249 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [Electrical Measurement: 37410/1 -> 0/0, cluster=0B04, TID=47, records=[ReadAttributeStatusRecord [attributeDataType=null, attributeIdentifier=772, status=UNSUPPORTED_ATTRIBUTE, attributeValue=null]]]

not working -:

2018-12-18 08:00:34.326 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReadAttributesResponse [Electrical Measurement: 3969/1 -> 0/1, cluster=0B04, TID=F5, records=[ReadAttributeStatusRecord [attributeDataType=null, attributeIdentifier=772, status=UNSUPPORTED_ATTRIBUTE, attributeValue=null]]]

So there is no change to the binding - but there is a change in the way the device is working. The difference is that now, for some reason, the device is not sending the reports. I would suggest to get a log showing the initialisation of the binding which is when the reporting is configured.

[baku104788]

Sorry - I must have accidentally uploaded an incorrect log. I’ll find the correct one and get it uploaded once I get back home. Had to dig around some snapshots to find the file again and clearly messed that up 😳. Sorry.

[cdjackson]

Why do you think that it was the wrong log? Sorry - I'm lost?

[cdjackson]

Just to clarify, the logs both show the error, but one log also shows the correct reports - this is as per the code - if the reports are sent by the device, then it works, and if they are sent due to polling, they won't work. The binding will periodically poll, so both logs will show the error. If the device is sending the reports, then it will also work ok.

This is why I want to see the initialisation logs from the latest binding. I'm not sure I understand your comment about loading incorrect logs though?

[baku104788]

Sorry I thought I must have grabbed a wrong log from your first comment - but now I see you are just pointing out that it acts similarly in both yet one isn’t working.