configureReporting - not supported by Xiaomi devices?

[veeceeoh]

I have been doing a bunch of reading and research on what is the appropriate code to use for configuring attribute reporting time intervals. What I found should be used is:

zigbee.configureReporting(cluster, attribute, dataType, minReportTime, maxReportTime, minReqValueChange)

Most of the "official" supported ZigBee device handlers in the SmartThingsPublic repository use configureReporting to set up battery reporting, but it's been well established that Xiaomi devices use a very non-standard method for reporting battery voltage, so I tried making code to set up configureReporting for each devices

However, based on my own tests and testing of code by joelw135 and GSzabados that I came up with for the Original Xiaomi Temp / Humidity sensor, it appears that configureReporting commands are ignored.

I did some Googling, and found a discussion thread here on GitHub by some users of deCONZ (a graphic user interface-based ZigBee monitoring & control software solution) trying to use Xiaomi devices.

In the thread, one user posted this about reporting of attributes by Xiaomi devices:

It looks like the sensor is smart enough to send multiple reports once it's awake (unlike the Hue motion sensor, which uses separate scheduling for presence, lightlevel and temperature. I see no pattern in the timing, indeed, it would seem it only sends reports once a threshold for change has been crossed. Note that at 9:07, only the temperature is sent - I assume bacause there was no change in humidity.

Normally, this would be configured through the ZigBee attribute reporting configuration

This seem to be hard-coded in the sensor (and, in fact in all Xiaomi devices I've seen) - they don't support reading not writing the attribute reporting configuration.

So, this appears to confirm what we've been seeing - the Xiaomi devices will ignore configureReporting() commands (and also ignore readAttribute() commands as well), and they will send attribute reports at intervals according to Xiaomi's design.

If that's true, then there's no way we can help reduce the level of reporting for any users that are seeing their battery level drop rapidly.

If everyone agrees that configureReporting commands are ignored, then the code for the refresh() and configure() functions of all devices should be the same as what Brian has recently updated to for many of the DTHs:

def refresh(){
    log.debug "${device.displayName}: refreshing"
    checkIntervalEvent("refresh");
}

def configure() {
    log.debug "${device.displayName}: configuring"
    state.battery = 0
    checkIntervalEvent("configure");
}

def installed() {
    state.battery = 0
    checkIntervalEvent("installed");
}

def updated() {
    checkIntervalEvent("updated");
}

private checkIntervalEvent(text) {
    // Device wakes up every 1 hours, this interval allows us to miss one wakeup notification before marking offline
    log.debug "${device.displayName}: Configured health checkInterval when ${text}()"
    sendEvent(name: "checkInterval", value: 2 * 60 * 60 + 2 * 60, displayed: false, data: [protocol: "zigbee", hubHardwareId: device.hub.hardwareID])
}

[gn0st1c]

mi sensors report when there is a change to be reported. humidity changes over 5% or 0.5 degrees on temperature etc.

even mi gateway itself does not have refresh/read sensors.

[veeceeoh]

Besides setting the minimum and maximum time intervals for attribute reporting, the configureReporting() command also allows the minimum change of value required to generate a report. So for example, it would allow you to required a 2% change in humidity before a attribute report would be sent to the hub.

It's a shame, because although Lumi / Xiaomi claims the Aqara sensors are ZigBee HA 1.2 compliant, the truth is they are not.

[veeceeoh]

I haven't seen any evidence of the configureReporting() command having any effect at all in the DTHs that are still using it.

I vote to remove the configureReporting() command from all DTHs.

I also vote to remove the refresh button from all DTHs as well.

The DeviceHealth configuration automatically gets sent any time you open the settings for a device in the SmartThings mobile app and press "Save." So the refresh button isn't needed, and it just confuses users who think that it will refresh the reported values from their sensors. It doesn't do that, so let's remove it.

What does everyone else think?

[bspranger]

I think your probably right on the configure reporting, and I also agree that the refresh is worthless.

[tmleafs]

I agree with @veeceeoh

[bspranger]

Let's take out configure reporting and refresh.

[bspranger]

I created a pull request for this

[bspranger]

Refresh and configure reporting have been removed.