(DO NOT MERGE) WIP - Update devices in ZHA storage at intervals

[dmulcahey]

Proposed change

This PR fixes the exceptions that ZHA tests were throwing. There was a race condition caused by explicitly saving devices in ZHA storage on the HA stop event while the storage itself was in process of flushing its state. We now write the devices to storage at a 15 minute interval.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

• This PR fixes or closes issue: fixes Fix zha tests that have uncaught exceptions #33348

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

[probot-home-assistant]

Hey there @Adminiuga, mind taking a look at this pull request as its been labeled with a integration (zha) you are listed as a codeowner for? Thanks!

[Adminiuga]

Maybe should wait till #33358 goes through?
But alternatively, if going this route, why not to leverage async_delay_save() of the storage helper?
ZHADevice._check_available() is already called regularly, we could use it to update last_seen in zha_storage and just schedule a delayed write?

[dmulcahey]

Maybe should wait till #33358 goes through?

Definitely

But alternatively, if going this route, why not to leverage async_delay_save() of the storage helper?
ZHADevice._check_available() is already called regularly, we could use it to update last_seen in zha_storage and just schedule a delayed write?

It does leverage that internally. The store itself needs to be updated first which is what happens here at 15 minute intervals which will schedule the write to disk. The save delay you reference is to prevent multiple writes of storage to disk within a short period (10 seconds). Each update to the store will reset that timer and then when there are no updates for 10 seconds it will write to disk.

EDIT
Your suggestion would perpetually cancel the save call because there is no end to _check_available being called. It's called every 60-90 seconds for every device. That means every device would cause async_delay_save() to be called. What would you use for a delay there? The more devices you have the more likely we never write to disk because we just keep calling async_delay_save() Does that make sense?

[dmulcahey]

Hrm... this may not work around the race condition

[dmulcahey]

Def still a race condition... 1st time a single test failed in the entire suite with the original exception this was intended to fix... Closed the PR and reopened it so it would rebuild and it passed.