device: Expose "sleepy" configuration

[kennylevinsen]

When set, all endpoints sends will default to sendWhenActive: true,
avoiding the need for manually setting this for every request.

[kennylevinsen]

An earlier implementation of this embedded the heuristic for enabling sleepy mode (battery-powered end device), but I thought it made sense to merge the manual version first - we want to be able to overrule regardless.

[Koenkk]

I guess this changes after we choose to go for #445 (comment) ?

[kennylevinsen]

We can have the interview flip this setting for all the endpoints. Is it guaranteed that a device object will go through interview after being created/read from database? If so, we could remove the database record and just have interview be responsible for flipping the bit.

[Koenkk]

@kennylevinsen

• Is it guaranteed that if the device supports genPollCtrl, sendWhenActive is not needed (can be false)?
• Instead of introducing a new term; maybe defaultSendWhenActive instead of sleepy is better
• In case we do not set sleepy in the interview, where do you plan to set this from? (from the configure()?)

[kennylevinsen]

@kennylevinsen

• Is it guaranteed that if the device supports genPollCtrl, sendWhenActive is not needed (can be false)?

The opposite. genPollCtrl is the zigbee-official way of powering a sendWhenActive behavior, by having the end device actively call us specifically to empty any request or configuration queues.

As it specifically controls sleepy end device behavior, it should be pretty safe to use as indicator for a device being sleepy.

• Instead of introducing a new term; maybe defaultSendWhenActive instead of sleepy is better

Will do.

• In case we do not set sleepy in the interview, where do you plan to set this from? (from the configure()?)

Indeed, known sleepy devices without genPollCtrl may wish to manually set it in configure.

However, we could add the end device + battery powered heuristic as fallback when genPollCtrl isn't there. Not sure if we'll end up needing any overrides in that case.

[Koenkk]

@kennylevinsen

However, we could add the end device + battery powered heuristic as fallback when genPollCtrl isn't there. Not sure if we'll end up needing any overrides in that case.

Not sure about that, I know that e.g. many Xiaomi end devices like the smoke detector and vibration sensor can be send messages to without sendWhenActive (they do a dataRequest every 30 seconds)

[kennylevinsen]

they do a dataRequest every 30 seconds

I believe that is a good example of where sendWhenActive is necessary, but where chance probably make things work often enough to not notice.

The parent will keep 1 packet for the device for 7.68 seconds. If the device long polls at 30s intervals, then delivery failure is guaranteed if:

1. More than one packet is sent in a 30s timespan.
2. Any packet is sent less than 22.32 seconds after the device polled last. If we add 10 seconds of retry logic, this becomes 12.32 seconds, or slightly more than 1/3rd risk.

Occasional fast poll sessions drop the risk a bit depending on how often they happen, so maybe 1/4th average risk of failure due to request timing.

So I believe that those Xiaomi end devices should be using sendWhenActive. The updated version that tries a plain send first is very unintrusive though, and effectively only changes behavior it is needed.

[kennylevinsen]

Added tests for having interview respect a user setting - we'll probably need the user setting regardless of whether we add a fallback heuristic later.

Ready for review.

[Koenkk]

@kennylevinsen sounds good indeed