Car Status stays on "Connected" but not updating #556
Comments
|
I think I have the same problem. Just noticed it since yesterday that my sensors aren't updating anymore. |
|
Sorry, I did not make myself clear enough: Sensors are still updating when e.g driving around et cetera or the car is "really" connected like when I keep Sentry Mode on. |
|
I think I might have the same issue that has probably started since the update to 3.11.0. In my case I think the sensors are updated, but it is just taking longer than it used to (probably 10 to 20 minutes delayed). In my case, I have automations that are activiated when the charger is plugged in, and also at certain times to turn the charger on. These automations depend on the things like the charging sensor showing up accurately. Unfortunately the update of these sensors appear to be delayed. As Dilorenzo says, the car seems to stay "Connected" in HA when it should probably disconnect, and when in this state, I suspect some things like the whether the charger is on or not seems to be slow to update. If I do a "force data update" it seems to quickly get and update the sensors. I hope this can be identified and fixed quickly. |
|
Further to the post above, I should have mentioned that I have "Seconds between Polling" option set to 66 seconds, so previously all these things should be updated every 66 minutes and thus the concern why it is now taking up to 20 minutes that I have observed. |
|
I few more observiations from me. When the charge is unplugged, that seems to update quite quickly. But when I plug it in, is updates much more slowly. Likewise when the charger start charging that sensor is slow to update. But it seems to be quick to update when the charger is turned off. |
|
For what it's worth, I also seem to have some issues with the 'online' sensor. Don't know if I have the exact same issues as the others about updating the sensors. I've reverted the integration to v3.10.4 via HACS and everything is running fine again. |
|
I am getting issues for a couple of months now. The values frequently become "unknown" and it is very hesitant to update even when I click on Update. Maybe coincidence: I gave stopped paying for premium connectivity this year, as I don't really see the value in premium spotify etc. I found this in log: |
Just an outside perspective... what you wrote here seems to align with what the documentation says about how polling is done https://github.com/alandtse/tesla/wiki/Polling-policy#polling-policy Are you certain you understand how the polling is done?
|
I would say I can safely suggest that I understand it. I use the default polling policy If the car would be not sleeping I would see a significant and steady loss of range. |
I'm not disagreeing that your car is asleep. I think you are misunderstanding the polling info. It does not poll the car nor update the data unless one of the conditions shown in the list is true. When your car is asleep, it will not poll the car-- therefore the sensors that you want to update are not updated. Right now the code does exactly what it says it does, and your experience exactly matches what the code says it will do. You can perhaps suggest that a different way of displaying the data would improve the user experience, but that would be a design choice to present data other than what is provided by the API. |
|
Dear Jorhett I am solely talking about the binary sensors "_asleep" and "_online". Both used to go "off" when my car was asleep (e.g Off / Disconnected). |
|
I am experiencing a similar issue too. v3.11.0 will always say my car is "Connected" and "Asleep Off" when it should not be. Reverting to v3.10.4 resolves this issue with the "Connected" and "Asleep" variables reporting correctly. |
Me too, reverted to 3.10.4. |
|
Thought it worth an update on my issue with this. When I originally reported, my main challenges was that the sensor for the charger being plugged in, seem to be very slow to update 10-20 minutes. But that issue seems to have gone away without me being aware of anything that I have changed (though HA was updated in there somewhere). So not sure if this might have been an issue with something outside of the integration or not. But as others have said, "Online" and "Asleep" almost certainly are not reporting correctly. In my case, I am now connected all the time pretty much, and at the same time "Asleep" is always "On" even when it is almost certainly not true, as none of the other sensors are updating. |
|
Yes, its really strange. E.g now my car is outside my office and sentry mode is on. All values are updating as expected (due to not being asleep) however it shows this:
|
|
Latest update is my slow recognition of some but not all changes is back. eg when I plug the the charging cable in, it seems to take about 10 minutes to change its state from "Unplugged" to "Plugged In". Likewise it takes the same about of time for the "Charger" state to change from "Off" to "On". Interestingly if I unplug the charging cables, it is much fast to update, and only takes about 1 minutes, which is pretty much what I expect with the "seconds between polling" time set to 66 seconds. If I press the "Force Update Data" when it is being slow to update, then it immediately updates. If I leave it to sort itself out, it seems to take about 10 minutes. In fact, it has been pretty much exactly 10 minutes from when I plug it in, to when it registers the change the 2 times I have tried this to test which might or might not give some clues. The other little things that has changed is the "asleep" sensor has changed to "off" which looks like it might be pretty permanent, whereas before this appeared to be on permanently. The "Online" sensor is still showing "Connected" at all times even when it is almost certainly not online. The only other observation is that this morning the Automation to turn the charger on in the morning when the sun came up seemed to have failed (it ran and from the trace seemed to do everything right to turn it on, but it did not take effect). This could be a 1 off, but for 6 months it has been very reliable, but I have had a couple of incidences of this since the latest Tesla integration update (might be coincidence). The only thing that has changed, is I have accepted the latest HA updates, but nothing relating to Tesla. I hope this can be sorted quickly as it is really breaking my automations to get the car charged from solar. |
alandtse
added
bug
|
Issue still there after 3.12 update!! Can't use it, reverting to 3.10 again... |
|
I am observing the same thing where the status is continuously saying "Connected" even when the car is asleep and this is also present on the latest update to 3.12. I can see that TeslaFi has the right status, but Home Assistant is still reporting as connected. I have my settings at 660 seconds between polling and the "normal" connection option.
|
|
If Home Assistant is restarted while the car is sleeping, it shows the correct state. This was on v3.12.0 |
Yes, it always shows the correct state at startup but after a wake up and going to sleep it is not :/ |
|
Same issue here was working OK on 3.10 |
|
Same problem here since V3.11 |
|
Recently bought a MY, so my first version was 3.11, but I immediately noticed the sensors "connected", "asleep", and "parking brake" (maybe more states which don't correlate with car sleeping) have strange update frequency resulting in dynamic polling as suggested in the docs doesn't work correctly. |
|
Same/similar issue here (3.12.2): came home today, plugged in, about 15 minutes later frontend showed still unplugged, used the wake up button, checked the app: the car was happily charging, HA did not agree. |
alandtse
changed the title
|
Not sure if my issue is exactly the same as the original post but it's been marked as dup above so I'd assume so. My context is: However, if I force reload the integration, then everything updates. Which I assume means the integration is working as it is getting an update. It's also worrying me alittle as sometimes it says the car is awake for hours, when actually I don't think it is. Leading me to check more reliable sources like teslascope to ensure they say it's asleep. My polling_interval is set to the default time of 660 and Polling Policy: Normal (default). |
I've reverted to version 3.10.4 and everything looks to be working again. |
|
I just installed this integration and I have the same issue with 3.12.2 version. I am using 'normal' mode and I checked the log and it seems the integration uses all the time the default 660s polling interval no matter what the status the car it is in. I tried to set polling interval to 60s in an automation triggered when the charging is started and I can see in the log it is taken in consideration but still it does the update at 660 s when it is charging and awake. I think this part of the log is relevant as even the update supposed to be getting the data at 10s, it skips fetching the data until 660s are passed: 2023-05-21 08:12:33.160 DEBUG (MainThread) [teslajsonpy.controller] 15457: online. Polling policy: normal. Update state: normal. Since last park: 1354. Since last wake up: 1394. Idle interval: 600. shift_state: None sentry: False climate: False, charging: Charging I can see the code in the controller.py Maybe this is giving some light for the developer. Bogdan |
|
I've been using this repository for 1 year and I've never had any problems, I was updating without asking myself any questions. I created an automation that sends me a report on the condition of the car every day at 8:00 a.m. when I am on vacation. (Battery status in %, sentinel status, door status, front and rear trunk status, charging port status, parking brake status). In February 2023, I'm going on a cruise for 1 week, I leave the car in the port car park, sentry cut (therefore in deep sleep!). Every day at 8:00 a.m., my automation wakes up the car, sends me the report, 11 minutes later the car goes back to deep sleep! (confirmed by message via another automation). In 1 week I lost 2% of battery (Normal!). April 29, 2023 11 a.m., I leave my car in a box loaned by my family, sentinel cut and 97% battery and go on vacation for 3 weeks in Asia. 1st report 24 hours later, the battery is at 90% (???), 2nd report 24 hours later, battery at 83%. I go through the Tesla application, confirmed battery at 83%! I think of a bug in the repository following the last update before my departure! So I go back from version 3.12.1 to 3.12.0 of April 21, 24 hours later 3rd battery report at 76%! I still go down to version 3.11.0 of March 26, 24 hours later 4th battery report at 69% I do a quick calculation, I'm at 12000Km, I'll be back in 18 days, if I can't find a solution, my car is at 0% battery when I get back and I have to call a tow truck! I call my family, I open the car remotely and ask them to check if the sentry mode is off! (And indeed, it is well cut!) Next report at 8:00 a.m., battery at 62%! So I call a friend who has a Tesla, and who 2 days later goes to the box, pulls an extension cord to the box to plug in my UMC and put my car on charge, which at that time is at 45 % of battery (i.e. a loss of 52% in 1 week!). The car being plugged in, the battery charges normally and the car remains plugged in until I return! Now reassured that I don't have my car at 0% when I get back, I come to this repository on github, to see if other people have had the same problem, and browsing through this thread, I see that everything works normally with the version 3.10.4. So I decide to go back down again to version 3.10.4 of March 24, 2023, and there!!! Oh miracle everything works!!! Although the car is charging, it goes into deep sleep 11 minutes after the last consultation by the application or after my report at 8:00 am. Today, it's been 5 days since I got back, I'm still on version 3.10.4 and everything works perfectly! The car goes into deep sleep when the sentry is cut off. I have several automations that notify me via Messenger on Facebook of the various changes to the car. So I looked when the car last went into deep sleep before April 29. It was March 28, 2023 at 12:33 p.m., at 1 p.m. I upgraded to version 3.11.0! Conclusion : |
In February my car wasn't spending any energy while idle either. By April my car was consuming a large percent every day keeping my car cool. This is likely the reason for what you are seeing. |
|
My observations are that the latest version 3.12.2 works fine, however with the following issues:
|
I live in France, and the temperature in April did not exceed 15°. And the cabin overheat protection is not activated. |
1 - my scan interval is set to 660s (default setting) |
|
Of course the HA integration takes the info from the server and not directly from the car. I've checked in logs and source code that after 600s of idle time, the integration allows the car to sleep and it has the sleep information but does not send it immediately to HA - that must be a bug. And when the car is asleep the HA integration does not poll the info so that the car will not be waken up. On mine I've seen the car going to sleep quickly after charging is finished and all the other conditions to sleep are true. How about the state of the car when charging? I don't think it is a deep sleep but maybe a kind of light sleep. In the github wiki there are are docs describing how update_interval(polling_interval) should be adjusted internally automatically by the integration when driving or charging or other states. Looking at the code it seems not all this is implemented yet and that is why the update happens at 660s default interval. |
|
I am the OP on this issue and the newest release (3.12.3) looks promising. |
|
This should be resolved by #621 which is incorporated into v3.12.3. I've been using it for the last few days and it's working properly. |
|
Also can confirm it's fixed in 3.12.3 |
|
Hey, I'm going to keep my eye on it, but it feels like this issue might have come back. I wanted to ask if anyone else has felt this issue come back since v3.15.2? Many thanks. |
|
I still have the v3.14.0 which is working fine for me. I need the integration working as of now so I have to do the upgrade when I'll have time to debug it (I am the one who found the fix in the first place). Bogdan |
|
I have a feeling it was not the hass integration but something to do with the Tesla itself which I didn't realise till later. When my wife took the car to work yesterday I was unable to connect to the car via the Tesla app itself. Since my wife returned home with the car and I opened the car with the app, I can now also connect via the app from a distance (unlike yesterday) and the hass integration is working again. So I think something else was going on. |
Using the current version 3.11.0 I noticed that the status stays on "Connected" but it isn't as no values are getting updated. Usually, I would see a decrease in Range or fluctuations in the temperature sensors over several hours.
I honestly don't know when this behavior started.
I am happy to assist with logs. Please let me know what I should provide.
The text was updated successfully, but these errors were encountered: