Sleepy End Device Reporting Configuration

[candeodevelopment]

@Koenkk I might be misremembering, but shouldn't Z2M queue reporting configuration changes for a sleepy end device until the device is next active in some way?

This doesn't appear to be the case now, what I am seeing is:

1. Make a reporting configuration change in the UI for a battery powered sensor (I've tried with many - e.g. Sonoff, Ikea, Heiman) and click "Apply" - for example change battery percentage reporting from 3600 / 65000 / 10 to 3600 / 7200 / 10.
2. Wireshark immediately shows binding / reporting configuration activity to the device (3 attempts).
3. Device is a sleepy end device so doesn't respond.
4. Z2M shows a config failure message in the UI and reverts the UI changes made back to the original (3600 / 65000 / 10).
5. A few minutes go by and the device is active again in some way (perhaps it reports in a state change, temperature, or it takes a minute for me to climb a ladder and press a button).
6. Wireshark shows activity from the device as expected, but no "queued" reporting configuration is ever sent.

Should changes be queued and work like this or have I imagined that's what used to happen?

[Koenkk]

Its not done for these messages indeed, when configuring manually you have to wakeup the device

[candeodevelopment]

I'm probably confused by other platforms (we work with many).

Is this something that could be considered for the future?

The new web UI with its "reporting" section makes it easy to mass-edit reporting configuration across many devices but it's not really usable for sleepy end devices - if you make a change to 10 devices simultaneously they will get attempted immediately, likely fail and then those changes are lost from the UI.

It would be good to:

1. Have the UI save your "intended" reporting configuration, even if it fails to be applied - it could show "current" and "requested" values for example.
2. If reporting configuration fails, re-attempt it when the device is next active (based on differences between "current" and "requested" values).
3. Perhaps have an optional flag that the user sets to governs the behaviour ("if sleepy end device configuration failed - do you wish to apply it when the device is next active?").

This might not be a new request, I do see that there's quite a few mentions of it elsewhere now that I've looked for it (example #28620) and also some discussions around message queues (example #17177).

[Koenkk]

It's indeed a good idea, let's leave this open and see how many people are interested in this.

[tomaszduda23]

It is not the same problem but seems close. If you want me to open another discussion please let me know.

I added sleepy device support to esphome esphome/esphome#13950. It reduces power consumption by 10-20x.
It works just fine with zha but I cannot make it work with z2m:

1. If devices is added as non-sleepy I cannot make it to connect to network after changing to sleepy
2. After changing address it connects as sleepy but interviewing never ends.

• Clusters show correct configuration
• Expose is empy
• Bind show end points but no bindings
• Reporting show end points but not any configuration

I would appreciate some help.

[alexh3o]

That would be great if it z2m could indeed keep the reporting configure queued until device wakes up. Manually waking them up can sometimes be tedious.
I used to have a home assistant script for this, looping every 10 seconds until device shows an update, then sending the reporting configure mqtt command, but the command stopped working in the last months and i haven't been able to fix it.
Update: just fixed the HA script it is working again, i can share on request

[sbraz]

Manually waking them up can sometimes be tedious.

Exactly, I have a waterproof outdoors temperature sensor that I'll need to open up just to change its reporting. And it's so tedious that I'm searching the Web for a workaround instead of leaving the sofa to actually do it :)