Andrew Berry

Thanks, I was missing a few components from that list. Based on https://github.com/zigpy/zigpy-znp/blob/dev/zigpy_znp/config.py#L69, I'm looking at the 30 seconds of logs from before the exception is thrown. There's several notices...

The prior log line was `10:39:48`, so beyond the window: `2021-06-14 10:39:48 DEBUG (MainThread) [zigpy_znp.api] Received command: AF.DataConfirm.Callback(Status =, Endpoint=1, TSN=61)`

The above was issue was fixed (🎉 !), as have other fixes to the library since I reported this issue. I'm still seeing the above task exception logged, and based...

Done! The only difference compared to the pre-rebase branch is removing a duplicate key for marking the battery as a diagnostic entity that's been fixed in master.

This is fixed at https://github.com/merbanan/rtl_433/pull/2116, but the tests PR at https://github.com/merbanan/rtl_433_tests/pull/428 is still open. Anything more for me to do there?

@ronnieSVK It's been working fine for me, though I only have one ATV. I thought there was a way you could re-trigger the pairing workflow but I can't find that....

This appears to still be an issue. We changed DST today, and a `run_daily` automation didn't run. There was no indication of errors or restarting apps in the logs.

Could there be a config option to opt out of the restart behaviour system wide, or per app? Another thought is that Home Assistant seems to handle this fine, so...

We just ran into this ourselves. There was an older similar issue fixed in lima-vm in 2021. Perhaps there's been a regression at some point? Or, Google's DNS records are...

GitHub now supports up to 10GB cached per repo. I got this working using https://github.com/ScribeMD/docker-cache as a proof of concept. Unfortunately, this is actually significantly slower than without a cache....