Suspend logging is not needed anymore as car falls asleep even while polling #3639
Comments
|
What do you mean by "the car fell asleep while constantly being polled"? The car will not sleep if an application (Tesla app, TeslaMate, other third-party Tesla loggers) are polling the car. Thus the "falling asleep" feature was introduced to allow the car to enter a sleep pattern. And yes, if you start a drive or a charge during the "falling asleep" window, it will miss some (or all depending on the duration) of that event. This is intended behavior. |
cwanja
added
note:more information needed
This has been the case for years, but not anymore. I created the following Powershell Script: This results in the following TeslaMateLog: This results in TeslaMate never letting the cars go to sleep, but they still do. I know the issue regarding Teslas not sleeping due to constant polling of the car, but this is not the case anymore. At least not with a 2019 Model 3 and a 2023 Model Y. What I do not know is, how Model S/X (especially Legacy Model S/X) handle that. Still, Model 3 with Intel atom and Model Y with Ryzen MCU sleep without any issue, although TeslaMate does not pause polling. |
|
What I noticed is that TeslaMate is a bit freaking out, probably because it does not expect the car to go to sleep: |
|
Do you have the Streaming API enabled in the Settings page? |
|
Yes. As I said, this only occurs when there is something wrong with the streaming API on drive/charge start. But your question has nothing to do with my issue. The issue is, that suspend logging is not needed anymore. |
pkuehnel
changed the title
|
For me it seems more that there might be an issue with /api/car//logging/resume This:
Indicates that teslamate is polling on the non-keeping-car-awake-state, which is happening when teslamate suspends the polling from https://owner-api.teslamotors.com/api/1/vehicles/XXXXXXXXX/vehicle_data which is the polling that can keep the car awake (and should also be able to wake it up) Can you extend the log you have to also contain some earlier [info] Start / :xxxx like this one:
The must be some Start / :online somewhere. At that point vehicle_data is being polled. Since you are telling teslamate to resume every 10 seconds it might mess something up in the switch between what is polled. |
|
I updated my script to only call But I am pretty sure that pausing the log is not needed anymore. I am using the new Fleet API in parallel, and there I also call Is there a way to change the polling breaks? Sadly, the options to change the intervals disappear when enabling the streaming API. |
|
Both cars still falling asleep while polling. Logs |
|
What I never see is:
Unless I am missing that in the logs. But I fail to see it. |
|
@cwanja I'm not sure what you want me to do 🤔 |
Where in those logs does it show that the car is asleep? And still asleep after you resume polling. That's what I am missing. To answer you specifically, I am looking for evidence that:
|
Means the car is asleep, that's why I pasted the log until that point.
What I am trying to tell you is, that the car falls asleep even though polling |
|
|
It looks like there is a bug in TeslaMate that if the car falls asleep while being polled, the message is not logged. As you can see here, in the dashboard, the car is displayed as
What I also notice is that the car is alternating between healthy and not healthy all the time while being asleep: Here are a few more logs, but as you can see, nothing is logged, indicating that the car is asleep. But it is, the States Dashboard is correct. Logs |
|
Some random points. asleep stateI do believe that: Means TeslaMate is entering the Having said that, my understanding of how we transition to the The 429 errorsThe expected error when the car is asleep is 408. But in the above we are seeing 429. This is the rate limit error, it means that the Tesla API is refusing to process the request because it has deemed that we have exceeded predetermined limits. It does not mean that the car is asleep. We do not currently process 429 errors correctly. |
|
The car is definitely asleep at this point as the high voltage switches click at this point. Try it yourself, the car goes to sleep while polling |
|
The car is also displayed for multiple hours as asleep, when I enter the car the high voltage switches click again and there is no vampire drain even not after 30 hours. The new Fleet API |
|
My findings are that whenever Teslamate writes Start / :[something] it is because that is the state coming directly from the api using either /vehicle or /vehicle_data. They both contain a state that can be online, asleep or offline. So that should be the true state of the car. Suspended is an internal state in Teslamate where the actual state is online, but /vehicle_data is not polled. Only /vehicle. I agree in /vehicle_data not doing anything if the car is already asleep or offline, I can't wake my car (2017 model s with MCU2 retrofit) with Invoke-WebRequest -Uri "http://192.168.1.5:4000/api/car/1/logging/resume" -Method Put I would however say that going to suspended is still useful, see my PR #3262 Is this something you can test. E.g. after a drive or after you leave it and lock it: How long does it take your car to go to asleep when you trigger resume vs. when you don't |
I tested that already but it is not really possible to determine the time it takes as (at least my 2019 Model 3) dries the air conditioning after each drive. So after a drive in very cold conditions (below ~-5°C) the car goes to sleep pretty much immediately after leaving it, sometimes after less than one minutes. But there are times the car is still awake after the first |
|
I think we need to make the appropriate change, test it on as many different cars and MCU versions as possible, and see what happens. I think the relevant code is: https://github.com/teslamate-org/teslamate/blob/master/lib/teslamate/vehicles/vehicle.ex#L1345-L1352 {suspend_after_idle_min, suspend_min, i} =
case {car.settings, streaming?(data)} do
{%CarSettings{use_streaming_api: true}, true} -> {3, 30, 2}
{%CarSettings{suspend_after_idle_min: i, suspend_min: s}, _} -> {i, s, 1}
end
suspend? = diff_seconds(DateTime.utc_now(), data.last_used) / 60 >= suspend_after_idle_minSo if streaming is enabled in web interface, then we use hard coded values, otherwise we get values from the database (which come from the web interface but only shown if streaming is disabled). My theory is if we can set a long time for I think the other two values control how long we wait before trying to fetch the data. |
|
Also note that stuff here might change, e.g. if Tesla introduces the strict rate limits as documented here, then increasing the polling may be a bad idea. |
|
As a first step a good solution would be to use the database values on streaming API as well and allow editing the values when streaming API is enabled. Maybe auto set the currently hard coded values when switching to streaming API. |
|
The vehicle takes much longer to fall asleep during active polling. It does fall asleep, but it takes longer. If we prolong the polling, we increase the vampire drain. Personally, I hit "try to sleep" manually when I leave the car. This causes the least amount of irritation and the smoothest fall asleep observed. |
|
@JakobLichterfeld Not sure where your data is from, but my car sleeps sometimes after 3 minutes even though polling every 10 seconds, so your comment seems to be invalid: |
|
Most of the time it is about 10 minutes but not sure how 10 minutes can be "way" longer:
|
|
Obviously our MCUs are different. And you only consider wake time after charge or drive. |
|
As my 2019 Model 3 and my 2023 Model Y behave the same, it seems like all cars except Legacy S/X fall asleep despite being polled. So there won't be a solution on that front, and very likely,> 90% of the users have to deal with missing drives/charges? I really would appreciate it if at least the three and 30 minutes weren't hard-coded (and the invalid label would be removed on that issue). |
|
I don't own any legacy S or X. Model 3 has at least 3 different MCU versions. |
|
I have a 2017 Model S with MCU2 retrofit When doing nothing: Suspending logging happens after around 3 minuttes (like intended based on the code) I have tried after a drive to keep it logging by clicking resume logging on the webpage For now I only have this one test where I did it. I actually don't think I ever missed a drive due to the stream API being down. And with bad internet. Wont both polling and streaming be down anyways? So I would actually rather have it suspend faster :) I actually already have an experiment in PR #3262 where I suspend when getting fetch errors in online. |
@micves No: The streaming API only detects drive and charge starts. If you begin your drive in a garage with no internet and polling has just stopped, the next 30 minutes won't be logged. Calling But I see there are many different requirements. Best would probably be if the timers wouldn't be hard coded, so I could enter 999999 minutes until polling is stopped and @micves or @JakobLichterfeld could enter 0 resulting in polling is immediately stopped. |
|
As much as this suspend state is a huge hack; it means we can take a while to notice events that happen while the car is in the suspend state (other then what we pick up from streaming - e.g. event when car is plugged in) - I am not convinced we can remove it. Maybe if we can fill in a table like the following? Hopefully I got this correct, please check ;-) A wiki page might be better, anyone can edit; although I don't think we have that enabled at present.
|
|
2019 Model 3 and 2023 Model Y do not require suspend. |
|
If the car has been woken up by Tesla to let you know that a new update is available, the car won't go to sleep immediately if polling is active. Instead, it will charge the 12V battery and be awake for about 1 hour. I use TeslaMateTelegramBot, and as soon as I get the message that the update is available, I open TeslaMate, hit try to sleep, and if I'm fast enough, the car will fall asleep in the next few minutes. That being said, there are cases where polling prevents the car from going to sleep and causes vampire drain as mentioned before. |
|
Why is just letting the user decide with not using the hardcoded values not an option? Everyone who is not interested can let the defaults, everyone who prefers less vampire drain can use zero minutes instead of the hard coded values, everyone who is interested in safely not loosing any data can insert a high value and in rare occasions there is somewhat more vampire drain. When switching off the streaming API there is also no hard coded value and the user can decide. Why removing that option when using the Streaming API? |
If I read the code correct, it disagrees with this. Streaming should just as well trigger a drive when suspended as it does online. I also read it as it should also start the drive if the car is already driving: teslamate/lib/teslamate/vehicles/vehicle.ex Lines 411 to 431 in f71cc51 teslamate/lib/teslamate/vehicles/vehicle.ex Lines 462 to 482 in f71cc51 I don't know if something is buggy in this or behave weird with bad internet. Do you have the log from such an incident? I'm actually not against having the options when streaming is selected. teslamate/lib/teslamate/settings/car_settings.ex Lines 8 to 9 in f71cc51 That way you can switch streaming on and off without messing with the stored values. |
|
A log is on my initial comment but here another log starting a little earlier: Note: The actual drive started at 15:37 and was 16km long. |
|
Yeah, I can see that is a problem. Is all the 'GET /' because you watch your teslamate webpage to monitor what is going on? Do you have a test where you on teslamate webpage click resume? Does it catch the drive right away after resume? Streaming and polling are on different sites, so one could fail while the other doesn't streaming: teslamate/lib/tesla_api/stream.ex Line 36 in f71cc51 normal: teslamate/lib/tesla_api/vehicle.ex Line 51 in f71cc51 Available timings when streaming api is on could help some. |
No idea why these are there but very likely something from my side.
Yes it starts immediately when clicking on resume. Here is a log: |
|
Hi, just adding my 2 cents, I own a Tesla model 3 2024 with SW : 2023.44.30.9 The car is plugged on the wall but the Wallbox is offline. ( So not charging) I did this multiple time, and every time, after 12 min my car go in the arms of Morpheus. And then i get those error from the API : So indeed |
|
I believe these lines: Involve the internal web server inside TeslaMate, we don't need to worry about them here. |
Somebody needs to come up with a pull request, and then we need to test it to ensure it really does what it is suppose to on different cars. And there has been a suggestion how to do this already, #3639 (comment). I note this was given a thumbs down, but unfortunately I am not sure why this was given a thumbs down. In short though, we would need:
This would mean we have less hard coded values in the code, which is probably a good thing. Even if we find out we do need the suspended logging. On the other hand, it means there are more variables to consider if somebody were to complain "it is not working for me" without giving any details. |
|
I wrote about my concerns above. To sum up, I would highly appreciate @adriankumpf background view on streaming API polling sleep things, before moving on. |
Because of Tesla's update in the cars resulting in no matter what TeslaMate does, the car falls asleep anyway (in most cases). |
|
Well as @JakobLichterfeld shows his love to hard coded values by voting down every single comment against hard coded values, I just stick to my powershell script. Looks like there won't be a solution in the official release. |
Thanks for your misinterpretation. I already explained it above:
We do need a solution for all the users, who pulled the docker image nearly 22 Million times. From your single point of measurement, we can expect to drop the hard coded values for streaming. Reality has shown that we need to look much further, which is explained above in several ways. Would like to keep this open for further exchange and perspective from Adrian and others. |
JakobLichterfeld
added
note:discussion
|
I have mixed feeling here. Yes, support is an issue. And yes, people will want to try this out in weird and wonderful ways that we never even considered. If somebody sets the value to 99999 and finds it isn't working for them, they are going to ask for support. And they probably have won't mention that they did set the value to 99999. We will have remember to ask. What happens if you set the value to 0? What happens if you set the value to -1? Maybe it is OK, but have we really considered such cases? Will this will increase polling of the Tesla APIs? Or allow reduction of the polling time? As mentioned above this makes me nervous. We don't want to give Tesla any additional reason to block us. But it is kind of hard to argue the merits of a particular approach when we don't have a pull request to evaluate... I think we could use the existing values already in the database. We don't need to add more settings that don't already exist. Also maybe we could clarify the labels "Idle Time Before Trying to Sleep" and "Time to Try Sleeping". They look the same. I think I know what they mean, and I find these labels confusing. Maybe the second one should be "Maximum time to try sleeping", because if I am reading this correctly we poll the car after this time even in suspend mode. |
|
For context here is a thread with (I think) good information about how teslamate polls/streams and when. #1288 Opinion: Whenever possible I think that reasonable defaults should be set but overrides be available. In this case make it clear that these are experimental and/or un-supported. |
Is there an existing issue for this?
What happened?
If the car does not have good connectivity or on Tesla's side breaks something regarding the streaming API, data is not recorded due to Logging being suspended. This was needed as cars stayed online when constantly being polled. But this is not the case anymore. Even if continually polling, the vehicle falls asleep without issues. I own a Model 3 from 2019, currently on
2023.44.30.9, but I tried this almost a year ago, and there, the car fell asleep while constantly being polled, as well.Expected Behavior
"Falling asleep" should not occur anymore, or at least there should be an option to disable the "falling asleep" feature.
Steps To Reproduce
trying to sleep.Relevant log output
2024-01-27 15:21:34.045 car_id=1 [info] Suspending logging 2024-01-27 15:29:23.091 [warning] Too many disconnects from streaming API 2024-01-27 15:29:23.094 car_id=1 [info] Creating new connection … 2024-01-27 15:29:23.094 car_id=1 [info] Disconnecting ... 2024-01-27 15:29:23.110 car_id=1 [info] Connecting ... 2024-01-27 15:51:34.401 car_id=1 [info] Vehicle is still online. Falling asleep for: 33 min 2024-01-27 15:51:34.409 [info] Start of drive initiated by: %TeslaApi.Vehicle.State.Drive{gps_as_of: 1706370691, heading: 354, latitude: 48.984552, longitude: 12.980987, native_latitude: 48.984552, native_location_supported: 1, native_longitude: 12.980987, native_type: "wgs", power: 11, shift_state: "D", speed: 5, timestamp: 1706370694311} 2024-01-27 15:51:34.409 car_id=1 [info] Driving / StartScreenshots
No response
Additional data
No response
Type of installation
Docker
Version
1.28.2
The text was updated successfully, but these errors were encountered: