Device timesout after a getting data for a short time
DurgNomis-drol opened this issue · 90 comments
Describe the bug
Hey guys.
I have for the last week or so been having a weird problem with my Google Nest Mini. Our integration works great, but after a couple of minutes i get this debug message (See logs below) which i expect.
I can still talk to the device, but in the Google Home app i cannot access my device settings for my device. My first thought was that something had gone wrong with the device. I tried reseting it multiple times. When i disable or stop our integration it seems to work again, but as soon as i activated our integration again, it stops working and is timing out again. 😞 A power cycle also makes it work for a couple of minutes, and then it stops again.
What do you guys think is happening?
I thought maybe we are hammering it to hard, but then again the would be weird if i am the only one having this problem.
Version of the integration
If you are unsure about the version check the github release here.
1.4.2
Logs
2021-04-13 19:54:40 DEBUG (MainThread) [custom_components.google_home] Fetching data from Google Home device Køkken - https://192.168.0.205:8443/setup/assistant/alarms
2021-04-13 19:54:42 DEBUG (MainThread) [custom_components.google_home] Køkken device timed out while trying to get alarms and timers.
2021-04-13 19:54:42 DEBUG (MainThread) [custom_components.google_home] Getting Do Not Disturb setting from Google Home device Køkken
2021-04-13 19:54:42 DEBUG (MainThread) [custom_components.google_home] Requesting endpoint setup/assistant/notifications for Google Home device Køkken - https://192.168.0.205:8443/setup/assistant/notifications
2021-04-13 19:54:44 DEBUG (MainThread) [custom_components.google_home] Køkken device timed out while trying to post data to it - Raw data: None
2021-04-13 19:54:44 DEBUG (MainThread) [custom_components.google_home] Finished fetching sensor data in 4.009 seconds
I had something similar with Nest Hub Mini yesterday but then it remediated itself. Seems to work since then.
I did have the same behavior as well a few times. Thou currently my RPi has just stopped working with constant "Unable to connect to Home Assistant" since morning. Nothing seems to be helping, so i ll just focus on fixing it first 😅
Mine have just gotten to a point now where i cannot get it to work at all and i cannot figure out why or how it is caused, since i am the only one having it, it should be something unique to my setup, but I don't have a fancy network setup, just a tp-link wireless router and nothing else.
How is your devices connected to the network (2.4G, 5G or ethernet)?
I also have a problem with my RPI locking up after 1 day or 2. 😭
I think i have found out what is happening.
When I spam an endpoint call like this just after a restart with Google Home integration disable curl -X GET https://192.168.0.205:8443/setup/eureka_info -k. It crash's after about 20-50 calls in a row. If I then stop and wait sometime, it still won't respond with new API calls.
So my conclusion is that the webserver that Google uses on there devices either have memory leak or is very badly build. Or that it is limiting/refusing request after a set number received.
What do you guys think?
I just did 500 requests to alarms endpoint in 53s (9.4 req/s) to Google Home Mini, it responded to all of them.
Another 100 requests to eureka_info finished in 10.4s also just fine.
Strange, i may have a faulty one then 😞 Can you paste your script here so i can try to see if it replicates it?
Well, script 😅
for i in {1..100}; do echo "Request $i"; curl -H "cast-local-authorization-token: <token>" --insecure https://192.168.1.2:8443/setup/assistant/alarms; doneBtw, I think I broke it. I cancelled it with Ctrl-C and it no longer responds. Maybe unfinished requests block it? But power cycle fixed it.
I was able to reproduce it. Sometimes after Ctrl-C it becomes very slow. It actually responds but only after ~30 seconds.
I just tried doing a 1000 request, it worked fine until i opened the Google Home App and the it stopped. I then did Ctrl +C and tried to run it again and it timed out. But it seems to solve it self after sometime(as you suggest), but for me it is much more then 30 seconds. 🤔 I don't use the Google Home normally, only to delete alarms or timers, until i have implemented it.
Do you think it does not like parralle requests or?
I don't remember how much RAM these guys have, but could it be that some of them does not have enough ram to handle being polled often?
I mean in my case it responds for 30 seconds on a single request. Now it took almost 2 minutes.
I don't think it's a RAM size. It's probably shitty webserver implementation. It hangs on TLS handshake (client hello request).
I think we can detect this and reboot the device using api call with disabled timeout. In my case it worked. It rebooted with no sound, shouldn't be annoying.
How can you see that it hangs on TLS handshake? 🤔
That does not surprise me. 🙄
Run curl with --verbose.
It seem to switch from TLS 1.3 to 1.2 after server hello for some reason? I don't know much about this, but could that be anything?
I think it doesn't support 1.3. In my case it uses 1.2 and forcing 1.3 causes an error.
Right. I just did a little bit of research and it seems to be that there is a known bug in some versions of openssl that will cause the handshake to just hang forever. And if we are (un)lucky that is exactly that version they are using. 😭
Do you have a link to that issue?
Stackoverflow talking about it, see also comment under the one I have linked. This is not directly about openssl but why it is happening.
This is long manifest about it, i haven read it all. But I think it hits spot on with our problem.
This one seems to also be about it. Directly on openssl github
I realised that the first one is not that important. 🤔
I tried using different ciphers and downgrading to TLS 1.1 but it still becomes extremely slow after few cancelled requests. It seems rebooting is the only way to remediate this.
List of ciphers Google Home Mini supports:
PORT STATE SERVICE
8443/tcp open https-alt
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
As far as i understand it is because of this line TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A we are having problems, it expect a SHA1 128 but gets SHA2 256 or am i misunderstanding something?
And yes that is probably the workaround for now that we should implement or maybe I should test run for sometime and see if it fixes it for me.
No, it announces which ciphers it supports during the handshake and then curl uses what it expects. It hangs before this actually.
@DurgNomis-drol I was experimenting with this, you can try it: https://github.com/KapJI/ha-google-home/tree/reboot-timedout
oh flip, you guys have some interesting talks here... :)
The problem is real, but we can't just start restarting google home devices :/ it can bring to a bad user experience very quickly :/ How about decreasing the API call frequency and looking at making those calls sync instead of async as @DurgNomis-drol proposed earlier? 🤔
We don't make parallel calls to the same device. Decreasing frequency won't solve this problem and will make UX worse for everyone.
Right, just double checked, those are separate devices we call in parallel, with all sync calls to the same device - that's good.
A weird observation but i did notice sometime the devices dont even appear in HA after HA is reset for the same reason of timeout. Maybe device force restart at HA initialisation can help to "sync them all up"? 😅 haha, not sure how that would work though.
I'm just afraid of us calling restart service on timeouts so that won't end up being restarting the devices every hours or so..
I'm also wondering, have we not started receiving timeouts just recently? 🤔 Don't remember us having timeouts in a old releases.
Just an idea but maybe if restart happens during the request, it will cause this issue similar to ctrl-c in curl.
We started to see this after 2021.4.0 release but some people reported this issue on previous release as well, so that's probably not related.
Yeh, that could be a thing about "broken requests" if HA was restarting. That could be "solved" by "syncing" HA with google devices.
It seems only happening on the few latest HA releases, but also in ha-google-home. I don't recall having timeouts when we were just bluntly fetching alarms and timers, but i might be wrong on that one
Yeah, probably we can gracefully shutdown the component when HA restarts.
uuuu, have you seen any implementation around for handling that? That would be great to do
Nope, but I'd expect HA has something for that.
I also had the problem on 2021.3 😊So i don't think it necessarily something HA changed but rather something we have changed in the integration. I can test against older version of our integration later and see if it solves the problem 😊
I have a small update guys, i have just installed the latest version (1.4.3) and after I rebooted my google device., it now seems to work.
These steps may be important:
- Disable/Remove integration
- Restart Google device
- Wait for the Google device to fully reboot.
- Activate/Add the integration again.
It has now been running for half an hour and it is still working. Before it stopped working after 5 min.
I will return with an update tomorrow to see if it is still working after 24 hours. 😃
Restarting it often is not viable solution if the problem occurs very frequent.
Maybe I fixed something while enabling strict mypy checks 😅
I just checked again and now the problem is back 😞 I will test if an earlier version works.
Hey Guys, great integration! however I am having identical issue.
Google Home, works for about 20 min and then if you set an alarm or timer doesnt update the sensor, as soon as you reboot the device, sensors are updated.
Here is the interesting part, I also have Google Mini, that has been working rock solid for 2 days now! Issue seems to be with Google Home.
If I can help with any testing, let me know.
Thank you for your amazing work.
@Raul-7-7 does this happen every time with this device? Are you using Google Home app during this?
@KapJI Yup, everytime , between 5-10 hours after reboot it happens.
For example last night around 8 PM I reboot the device, it was working fine until around 1 am (5 hours) went to bed, woke up this morning and it is no longer working.
I opened Home App on my Android, and I can no longer access the settings for this device. I set Alarm, nothing, I reboot, alarm shows up in HA!
Please let me know if you like any further tests.
PS) 2 Google Mini devices I got, both working with no issue - 4 days now.
@KapJI in case this helps, I tried to call the service form HA: google_home.reboot_device with the entity id of the device in question, no luck, it doesn't even reboot it. Looks like all communication with the device is gone!
However, device still works , like if I say "Hey google, what time is it" it responds fine!
Yeah, it's the same issue but it's still not clear what causes this in HA.
reboot_device doesn't work because timeout it too low there. Device will only respond after ~30 seconds or more if in this state.
@KapJI did more testing yesterday.
The issues comes around 5 hours after the reboot. reboot fix it!
However, this is very interesting: In another test I did this
- Reboot device and HA
- Wait about 5 hours
- Set Alarm on device, did NOT show on HA
- Opened Google Home app on my phone, could NOT access the settings
- I did NOTHING, just waited, after about 2 hours (so now 7 hours since reboot)
- I opened Google Home app on my phone, I COULD access the settings
- I then set alarm on the device, and it DID show on Home Assistant!
it is now about 18 hours since original reboot, and everything is working!
Going to wait and see when it goes down again!
Almost 31 hours since the reboot and its working no problem.
If I get the chance tomorrow, I will reboot HA and device again, and see if I can reproduce the same behaviour.
@KapJI Update in case anyone reading:
This morning after about 40 hours, (It was still working), I reboot the Google Home and my Home Assistant and was able to replicate the issue
- Worked for 5 hours.
- Stopped working both on HA and Google Home APP
- Waited 2 hours
- Started working again and been solid !
Something happens about 5 hours after reboot that lasts for about 2 hours that break things, and then it works.
I am done testing and "AMAZING" integration works great for me, however if you want me to check something else or I can help community in anyway, let me know.
Thank you to all those involved.
Cheers,
@KapJI Issue has escalated recently, the last week or so, I have to reboot my devices (Google Home and Mini) every 5-6 hours or I will lose the connection to them. Easy way to check this, open Google Home app on your phone, open a Nest and you no longer have settings options etc.
@DurgNomis-drol Hey! curious have you found a way around it? I have tried so many things, none seem to work, max I got it to work was 7 hours and then nothing! When I open Google Home app on my phone, I can not access settings on Mini or Home! reboot of course fix the issue but for short period.
Man I loved this integration :( I am very curious how no one else seem to be facing this, what is it that we are doing making this appear for us?
@Raul-7-7 No, unfortunately not. I have also given up as it is even more severe for me.
As @KapJI and me (Mostly him) deduced is, that it is a bad implementation of the webserver running on the Google device and that we can't really do much about it. Specifically about how it handles requests and TLS handshake.
We can only hope that Google updates it's devices with a firmware that fixes this.
@DurgNomis-drol Interesting, that sucks! considering its pretty much you and I with this issue, I am very curious what is the cause of that?
Do you have any of the newer Gen devices?
@Raul-7-7 i have a Google Nest mini (Google Home mini 2). What about you?
@Raul-7-7 @DurgNomis-drol You are not alone with this issue. I have the same on multiple devices (couple of Harman Kardon CItation One, Harman Kardon Citation 100). I keep getting timeouts from this integration and I can't access any setting from the google home app either.
I also have the issue that these speakers regularly hit me with the "Please login through the google home app" when I issue commands. At this point I'm kinda done with all these google issues, and support has been terrible from their end.
The only real solution for us is to reduce the update interval to something like at 1 or 5 minutes, but that defeats the whole purpose for me as i am using short timers. Thus the devices will have time to handle when it times out a request.
Right now it cannot handle multiple requests. If they timeout due to something internal in the software, they effectively crash and have to be restarted. This is probably because of a very bad and possibly wrong implementation of a async webserver. I know that these devices runs a highly customized version of Android. It should also be said that the way Google Home is implemented, it have never been the intention to constantly try to get all this information, but rather only occasionally. That is probably why they didn't care to implement it better. Also these devices have very limited RAM, this may also be somewhat of a reason why they have a hard time handling multiple timedout requests.
If someone knows more or better please correct me. 😁
@DurgNomis-drol I have Google Home Mini (Gen 1) and Google Home (Gen 1) as well! so my devices are abit older than yours.
Regarding what you mentioned, do you know what is the frequency now? to check for alarm?
PS) you got it btw , Google has no intention to fix this, they dont really need to! for them, the device works with no issue!
I kinda fixed the issue but it's not pretty. I noticed that whenever the speakers stop being accessible from the google home app they also timeout if I do a request on the eureka endpoint, and that allows me to setup some automation to restart the speakers.
Here's how I set up all this:
- Connect my speakers to smart plugs that are controlled by HA.
- Define binary sensors for each speaker with the REST platform that ping the eureka endpoint. Whenever the requests timeout, the binary sensors' states change to "unavailable".
- Setup some automation (I used node-red, but it's doable in HA too) that turns off the smart plug whenever the sensor becomes unavailable and turns it on again after 10 seconds.
I added some more logic to the automation (for example not having the speakers restart at night and wake me up unless there is an alarm setup, not restart when something is playing, etc.) but that's the gist of my solution. It's not very elegant but it seems to be working for now.
@arevaclier Interesting, how often does it reboot? because mine becomes unavailable after about 2-3 hours, is it going to keep rebooting every 2-3 hours?
@Raul-7-7 it pulls endpoints every 10 seconds in series. So no parallel requests or any thing.
Off topic:
I am gonna be honest, i am probably gonna build my own smart home speaker as Google Assistant speakers here in Denmark does not have all the features enabled anyway. They are shit speakers and too cheap for Google to really care about making them work well. Even when not used with this integration it is sometimes completely hopeless when i speak to it in danish. 🤦♂️
@arevaclier that is a very "creative" way of solving the problem 😎 Kudos for making it work!
@Raul-7-7 It's a bit unpredictable for me, but around once or twice per day so not that bad. The only annoying part is that the speakers make a sound when they reboot but other than that I don't really notice them doing it.
@DurgNomis-drol Thanks! Been trying to find a solution for a bit and looking at this thread inspired me to try to poke at the eureka endpoint :)
@DurgNomis-drol and @arevaclier
I ran a little experiment, changed the update frequency from 10 seconds to 180 (3 min) and it has been rock solid since I did it! almost 24 hours now.
I know this might still break (I will update) and might not work for all usecases, however, since I mainly need this for alarms and I never set alarm that is less than 5 min away, if this hold up, would solve my issue!
Anyway will update how it goes in a few days.
@DurgNomis-drol @arevaclier @KapJI
Just wanted to update, still going strong, close to 50 hours now. I believe this is the issue, the Frequency (10 second) is causing the issue.
I have been running rock solid when changing it to 180 (3 min), for me this works as I never set alarm that is sooner than 5 min, however, maybe someone can test with 120 or 60?
Anyway, if it breaks I will update, but this is the longest it has ever gone without failing.
If I can help with anything, let me know.
Cheers,
My suspicion that this may happen when HA restarts and we don't close all connections gracefully. We should implement handler for shutdown event.
Does this happen for you without HA restarts? If so, does the new update starts after the previous one has finished in your case? May the overlap?
@KapJI when the Update Frequency was 10, it happened at any scenario I tried (and believe me I tried a lot of combo)
I rebooted both device, restart HA ---> 4-5 hours later had the issue
Restarting HA would NOT solve the issue, I even turned off the server HA was running, for 5 min, and no, issue would not resolve, only way to resolve the issue was to reboot the Google Home devices.
Since updating the frequency to 180, I have restarted HA, set alarm, set timer, cancel, you name it, all working no issue.
Maybe because you check every 10 seconds, the connection does not close in time before next one start?
I can test with Update Frequency set to 20 seconds and see if it fails if you think that is going to help.
I mean HA restart may cause it and put device in this bad state, it doesn't solve it.
Thanks for some extensive testing, @Raul-7-7, @arevaclier.
Clearly the first "low hanging fruit" we can implement to remedy the issue would be to increase the updating frequency. What's more, I propose we make a configuration entry in the Integration options where the user can easily change the updating frequency. We should find the smallest updating frequency possible that won't cause problems with Google Home timeouting and set a comment that decreasing that default updating frequency goes under the risk of the user, since those can cause timeouts.
This should help making the integration usable for people with timeouts like @Raul-7-7, @DurgNomis-drol and @arevaclier. And then we could look deeper into implementing of handler for shutdown events to take it an extra step further
@leikoilja It has nothing to do with shutdown event's 😊 The problem starts by itself after about 10 minutes for me. The only way to fix it for me is too restart the Google device and then reload the integration.
But changing the update interval may fix it for me, if I can find a low enough one that works consistently.
I think making update interval configuration via config flow is reasonable, so people experiencing this issue can adjust it to their needs.
I personally have this issue very rarely, e.g. once in few weeks which I think correlated to HA updates in my case.
@leikoilja Not a problem! I have a few units, anytime you guys needs testing, would be more than happy to help out.
@KapJI Great idea! I am currently on update 180 (3min) and it has 100% resolved my issue, not once I had to reboot my devices, I did restart HA 4-5 times, no issue, it is working.
@DurgNomis-drol maybe you can try changing it to 30 seconds? see how that works, just curious, what is your usecase that you need the update frequency be so low?
Cheers,
@DurgNomis-drol maybe you can try changing it to 30 seconds? see how that works, just curious, what is your usecase that you need the update frequency be so low
Well if you are running automations based on setting alarms/timers you generally want quick response times. If your automation triggers on a ringing alarm a round time of half a minute, could miss the event (if the user stops the alarm to quickly). And three minutes might even be very late, e.g. if you set a timer for a pizza in the oven and use home-assistant for additional notifications.
I use it as a kitchen timer, eg. short duration timers. I think 30 seconds may be the upper limit for me. I will test it now and report back in a couple of days 😃
Nope, unfortunately for me it does not work at all. 😭 I also tested 60 and 120 secs and it gives me the same result.
@DurgNomis-drol that sucks! mine is over a week now, going no issue with 3 min, I know 3 min wont work for you, but can you try it for a day? curious if thats the magic number!
@Raul-7-7 Yeah, 3 mins seems to be the magic number. It is now stable for me too, though too slow for me to use.
I noticed that in my case the same device was queried simultaneously as the device itself and as the main device in a group when querying groups. Can it be the same for you? You can also try to replace asyncio.gather in api.py with sequential queries and see if it helps.
@KapJI Tried that a long time ago. Didn't change anything.
@KapJI @DurgNomis-drol I been doing more testing past couple of weeks, seem to notice some consistency with this Scenario even at 3 min update Internal.
Setup: Google Home Mini is located in Bedroom & Google Home located in Living room.
I have no other device in Bedroom, however, I have ChromeCast with Google TV as well in Living room.
Testing Scenarios:
- Update = 20 seconds
-
- both devices eventually get to unavailable state in about 4-5 hours
- Update = 180 seconds (3min)
-
- Google home Mini in the bedroom rocksolid, not once it has gone offline.
-
- Google home in the living room goes offline after 24-30 hours, and even if I unplug it, wait 10 seconds plug back, its available for 2-3 hours and then again offline.
-
- This is where it gets interesting, I noticed in my Google Home app on my phone, I lose the "CONFIG" gear for the ChromeCast with Google TV, I reboot that device, then reboot Google Home and boom, they both stay online and Google Home is available and only I notice it become Unavailable when ChromeCast with Google TV also loses the Config Gear!
Is it possible that we ignore the update interval when another device in the same room becomes unavailable? and keep hammering it?
Anyway, I did this more as a test, for me it doesn't matter, I only use this integration for setting alarms, and I always set my alarms on the bedroom one which is RockSolid. However, I be happy to do more scenarios if you think it helps solve the issue for community.
Cheers,
@Raul-7-7 Thanks for testing. But i still believe the problem is coursed by a bad implementation of the webserver on Google's end. It does not handle timeout or parallel requests very well.
The things is with these products, they are constructed as cheap as possible, like when you buy a cheap old car. It is only meant the work for a short time until you can't complain or it breaks down. The API we are hammering have never been construct with the intentions of being pulled for data this offend. They are meant to be pulled only once in awhile, like when you open the settings in the app. And nearly all devices, even if they are not build by Google. They run a proprietary version of Android, specifically designed for this job. I know this because i was at some point researching how to root them, but learned that it is (almost) impossible.
@DurgNomis-drol I agree with you that these devices are not meant to be used the way we are using them, HOWEVER, the part that is driving nuts is, why only few of us are experiencing this? There has to be something different with our setup.
It may have something to do with the internal hardware. I believe that Google gets these devices manufactured at many different companies and they may use different hardware and hence different firmware, and they may even be using different software versions for them (I think this is the problem). But for us the consumer, it will look like it is all the same. This can maybe explain why only some of us are experiencing this problem. There are many other small things that also can play a role, but i believe this one is the main one.
This is by the way, a very come way to manufacture a large amounts of cheap hardware.
ohh flip, these google devices are a bit crappy.... so sad 😞
Do you guys think any of you can help draft a little section about timeout issue into readme's "troubleshooting" section? We might even need to add some "limitations" paragraph in the beginning of the README file to warn ppl beforehand that the integration might not work for 'high frequency' applications due to the google imposed limitation (what we believe is the case). We can also open a new issue to implement configurable update frequency from HA and once it's implemented we could refer the user to try lowering down the update frequency from let's say default 3minutes to something they need under their own risk? 🤔 Also, big thanks for debugging and testing, @Raul-7-7 and @DurgNomis-drol
@leikoilja That is a great idea!
3 minutes does not even work for me, but my network seems to be peculiar thing.
Lets open an issue for implementing update interval in config flow and separate one for the readme section.
I can make a draft of the readme section, as i am probably the one who fought with problem the most. 😞
@leikoilja @DurgNomis-drol I can also help with testing and readme section. Let me know.
Cheers,
@Raul-7-7 I have already written something about it. You can see it in the readme just under about. But if you think that you have something to add, you are more then welcome to open a PR with it. 😊
@Raul-7-7 thanks for offering your help. We have released a new version yesterday, can you please upgrade and test if it works for you to tune the update frequency and if the devices stop timing out (with a default 3mins update freq)? 🤩
I've been seeing this issue for a while too — but recently been struggling to get the devices to initialise all together.
For the record, we have 4 Google Home minis, and 2 Google Home Hubs — all pre-"Nest".
I did notice today that for the Google Home devices that did initialise through this component, they wouldn't show for the native "Google Cast" component. Although, deleting that has made little difference. I've managed to connect to 3 out of the 6 today, after several restarts. Initially, only one was working.
Tailing the logs, it seems like the API isn't providing the IP for connecting to the device — I've attempted several restarts, and a clean install when upgrading google_home to 1.7.0. The IP is still returned as "none".
Interestingly, in the past, I had issues connecting via the configuration options through the Google Home app too, as if all traffic was blacklisted temporarily. That no longer seems to be the case, and GH can connect even when HA can't.
UPDATE
Literally after posting this, and re-enabling Google Cast in Home Assistant, all the devices have come back online, but haven't persisted through a restart. The original three have fallen back offline for google_home — Cast is fine. Weird…
Hello
I saw that reloading the integration makes the sensors available again.
Maybe we can make an automation after x minutes of an HA restart, we reload the integration ?
I will try it
I set the refresh to 10 and made an automation to reload the integration after 5 minutes with homeassistant.reload_config_entry and the ID of the integration… seems to be OK all my sensors are available. I keep you posted
Sounds a bit hacky, but considering that this integration is based on the reversed unofficial google API - we do what we have to do. Thanks for posting your idea @oxamafia.
Can you please also post here your automation config for the reference? :)
Yes sure!
YAML of the automation
trigger:
- platform: homeassistant
event: start
condition: []
action:
- delay:
hours: 0
minutes: 5
seconds: 0
milliseconds: 0
- service: homeassistant.reload_config_entry
data:
entry_id: ID of Google home integration
To get the ID of GH integration : File Editor (or equivalent) > repertory config/.storage > file core.config_entries
Search for google_home and copy/paste the entry_id field
After almost 24hrs (without reboot) all my sensors are still ok.
it’s not very « clean » and a bit hacky but it can solve the problem.