Restore state of ZHA binary_sensor if available

[Adminiuga]

Description:

This is an enhancement to #14553
While setting ZHA binary_switch-es to 'Off" on initialization is more consistent with other platforms, why not to try restoring the old state from the recorder database?
In my setup async_update() consistently fails to read on_off attribute of OnOff output cluster, so losing switches state becomes a nuisance when you have to restart HA often, like in case of development.
This pull request implements the following logic for the "default state" upon HA initialization/restart:

• default state is None
• tries to update state using async_update(), since async_add_device(update_before_add=True)
• uses async_added_to_hass() to restore the old state if avaiable

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

[dshokouhi]

Hmm should this also be done for contact sensors as well? I noticed that when I restart, the state also defers to off instead of the last position which could be on.

[Adminiuga]

@dshokouhi are those IAS devices? Doesn't async_update() get the proper state?

[dshokouhi]

@Adminiuga they are IAS devices (at least I think they are centralite contact sensors?) They do not restore the state for binary sensor but the temperature sensor does retain the state now.

[pvizeli]

We don't restore states from exists device. Only level 2 components (logic)
or device with asumme states can do this. @balloob ?

[balloob]

Pascal is right. If we can query the device, we should not restore it from the database. If it's a sensor that only occasionally sends an update and that cannot be triggered, restoring is ok.

[Adminiuga]

Only level 2 components (logic)

@pvizeli can you please provide an example of Level 1/2/3 components, so I could better understand what are you referring to?

@balloob we can query the device by sending the attribute read request, but as was mentioned in #14553 the device may not respond to it (Xiaomi devices) or the device could be asleep. If the device does respond to query, we'll use the reply as the initial state and skip state restoration from db. we revert to state restoration only if the query fails or does not produce any update. Specifically to zigbee switches, the OnOff cluster is an "output" cluster eg it sends updates to the controller and is not intended to be queried, unlike an "input" cluster. In my setup, a bunch of 45857GE & 45856GE wall switches and OSRAM Ligthify wireless dimmers none respond to attribute read request so cannot properly update the state upon HA restart. Not until user toggles each switch back and forth to get it back in sync with HA, which becomes more annoying as the number of the switches goes up.

@rcloran which switch devices do you use which respond to attribute read request on OnOff output cluster?

[dmulcahey]

zha already caches attribute values. The reason there are many reports of mismatching values is because of this. The problem is that a majority of these devices are "sleepy" end devices. Meaning their radios are off until they have a change that they want to report. When the safe_read operation is used in conjunction with the recently update_before_added functionality zha is pulling the previously cached value from its db unless allow_cache is explicitly set to false on the call. @rcloran please keep me honest here incase I have something wrong...

That being said, I believe that devices with the onOff cluster in the output_cluster collection are remotes... not switches. switches have the onOff cluster in the input_cluster collection. This is a very important distinction. These are "sleepy" devices that are meant to be configured in zigbee groups with other devices (ex: light bulbs) but zha doesn't support zigbee group commissioning yet.

Not until user toggles each switch back and forth to get it back in sync with HA, which becomes more annoying as the number of the switches goes up.

#14795 should fix the out of sync issue w/ automations and bulbs or ha groups because it forces the events to fire on every button press. I would use the events in automations for now and completely ignore the state of the binary sensor that is created. Let the state of the device(s) you're trying to control filter the events that matter by setting conditions in the automations referencing them. Meaning only handle the osram on event if the light you're trying to control is off etc.

[Adminiuga]

That being said, I believe that devices with the onOff cluster in the output_cluster collection are remotes... not switches. switches have the onOff cluster in the input_cluster collection. This is a very important distinction

Correct. But the problem I'm experiencing with remotes is that I cannot read OnOff attribute from OnOff output cluster, regardless if I do cached or uncached read. @dmulcahey do you get successfule reads of OnOff attribute on these remotes?
forced_update=True does make things better and I think is actually a good fix for these remotes. Although in my opinion, users would get a better experience with the addition of state restore for these remotes.

[dmulcahey]

zha already handles state restore so long as allow_cache is set to true on the safe_read call. Should be a simple change on the HA entity...

[Adminiuga]

Attribute caching works only if read_attributes actually fetches new data. If reading of the OnOff attribute on OnOff _output_ cluster consistently fails, there won't be any data cached, thus state restoration relying on async_update pulling the cached data won't work. Not in this specific case of the remotes. It works for other sensors, but not for the remotes.

…

On Mon, Jun 4, 2018, 18:15 David F. Mulcahey ***@***.***> wrote: zha already handles state restore so long as allow_cache is set to true on the safe_call. Should be a simple change on the HA entity... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14755 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFjmcBPuIOzgwgzdthWEeh83pkrVQYNYks5t5bFlgaJpZM4UXgZj> .

[dmulcahey]

I’ll look into this when my son goes to bed. I thought cluster attribute updates were cached in general in Zigpy.

[Adminiuga]

Yes, they are cached when an attribute_report is received, but for whatever reason this does not happen for the _output_ clusters.

…

On Mon, Jun 4, 2018, 18:40 David F. Mulcahey ***@***.***> wrote: I’ll look into this when my son goes to bed. I thought cluster attribute updates were cached in general in Zigpy. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14755 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFjmcBmMH7wdS8MtbDVF7YoEKtOPzL0Xks5t5bdFgaJpZM4UXgZj> .

[dmulcahey]

Probably an oversight. I think a PR to Zigpy to change that makes sense. Thoughts?

[Adminiuga]

Need to dig a little bit deeper into this. If it can be fixed on zigpy side, then it would be a better solution.

…

On Mon, Jun 4, 2018, 18:48 David F. Mulcahey ***@***.***> wrote: Probably an oversight. I think a PR to Zigpy to change that makes sense. Thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14755 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFjmcPOtSDgx3ZkpCIaFOYJ0QzY4MwL6ks5t5bk9gaJpZM4UXgZj> .

[dmulcahey]

Are you on discord?

[Adminiuga]

Nope, can you please send an invite? Or do you mean home assistant discord channel?

…

On Mon, Jun 4, 2018, 19:21 David F. Mulcahey ***@***.***> wrote: Are you on discord? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14755 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFjmcEYqLYgdakWhb7B_Pk9eBhzaIJoSks5t5cEOgaJpZM4UXgZj> .

[dmulcahey]

HA discord channel

[balloob]

@Adminiuga: can you please provide an example of Level 1/2/3 components, so I could better understand what are you referring to?

Talking to devices is level 1. We get raw data. Level 2 is for example the filter sensor. Takes in data and then processes it (aggregate/filter/etc).

[Adminiuga]

closing in favor of #14902