KWReid
Member
It seems like the "let car go to sleep" logic worked well overnight. Previously the car was awake the entire night when polling every 1min for details.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Model S REST API
- Thread starter timdorr
- Start date
-
- Tags
- Model S User Interface
It seems like the "let car go to sleep" logic worked well overnight. Previously the car was awake the entire night when polling every 1min for details.
darth_vad3r
Well-Known Sith
This is definitely the gap in this partial workaround. If I'm in the "let the car go to sleep" mode because the car is ONLINE and SHIFT_STATE is null... and I get in to start driving I'm going to miss some part of the drive because my app will not get details for 10-15min while it lets it try to sleep. Then it'll make a call and find it's SHIFT_STATE is no longer null and start reading details again.
I'd like to avoid having to manually do something to prep the car before driving. Also, if the car is in this "waiting to sleep" state already, and I turn on preconditioning, my app won't know that because it's not making details calls to get that info, nor will it know that user_present.
Yea. if I'm that concerned about losing a part of the drive details, I could just build in a one button web call to temporarily switch to details polling mode for the next few minutes.
thx!
I find myself loving the preconditioning so much that I use it all the time to make the car cool before getting in.
If your car is in “waiting to sleep” state, and you turn on preconditioning, you need to make your app check the climate_state.is_preconditioning and the vehicle_state.is_user_present to see if someone has indicated the car is likely about to be driven (only if the /vehicles API indicated that the car is online obviously). If you wait the required time between checks it shouldn’t interfere with sleep. If it’s awake to drive you will catch it, if it’s awake about to go to sleep you’ll delay the sleep by 10 minutes. As long as you wait long enough before the next check you should see the car go to sleep is my understanding. You can actually check the /vehicles API more frequently when you are waiting for it to go to sleep to see how long your car takes to go to sleep.
If you keep track of sleep state, you could actually check /vehicles more frequently to see if the car wakes up, then immediately check the vehicle_data to see what it’s doing.
I guess this depends if you can run your app in the background or not.
If a drive has ended and the car is locked, I would go into the “wait for sleep” state, but as soon as I detected the car is asleep, I’d move to a “wait for drive” state.
In that state I’d only check /vehicles until it’s online, then I’d check vehicle data right away, and every 12 or so minutes (assuming sleep delay is 10?).
I haven’t played with this myself yet but I’ve thought about doing so.
Last edited:
KWReid
Member
My app is server side. It polls continuously every min. It starts with a /vehicles call which tells me if it's sleeping or online. If it's online, it'll follow that up with a details check unless it was seen as online prior, but looks like it's trying to sleep.
So far I've not seen any problem with the car going to sleep after a drive. Today, after finishing a drive and plugging in, the car remained awake while charging, and for another 30min after charging, and then went to sleep.
Note that for preconditioning, I'm pretty sure that would require the car to be in the online state. If it were attempting to sleep, preconditioning should interrupt that and keep the car awake.
My apps "wait for sleep state" is one that stops polling details when the car is showing as "online". If you wait until the car is asleep, then you're going to miss any drives done while the car is online but not polling details. Since we're not polling for details we're not going to be able to see any state change on the car (unlocked, driving, user_present, etc...). So that's not going to be better.
darth_vad3r
Well-Known Sith
I’m just saying you should check the state if it comes online and decide the next state based on that using the criteria I mentioned.
Was asleep + comes online => check state, if interesting, keep polling more frequently to catch start of drive, otherwise don’t poll for 12 minutes to see if it just goes back to sleep.
If you see it come online, after it was asleep, what do you do now?
KWReid
Member
Resume detailed pings. So it'll pick up the drive as soon as the car is no longer asleep.
darth_vad3r
Well-Known Sith
Ya, there’s where you need to back off unless a drive actually looks imminent, otherwise how will you let it go back to sleep if it wakes up to charge the 12V overnight?
I would only pick up the pace if it was preconditioning or unlocked or user was present within a minute or two of waking up, otherwise I’d wait 12 minutes and see if it’s gone back to sleep.
KWReid
Member
Remember I look for a hint that he car is prepping for sleep, so when the details call is done, if that shows, it backs off. When the car wakes up overnight it starts giving that indication within minutes of waking, so it goes to sleep within the 10-15min back-off time.
So again, doesn't seem to be a problem.
Had to do the same thing for the DRIVE - Electric app on the Samsung Watch. The new endpoint works fine. The old one succeeed one out of five attempts...
darth_vad3r
Well-Known Sith
I think this "unless" bit is where I'm saying you can check the state of preconditioning, doors locked, user present, etc. To distinguish between random wake up, or user initiated wakeup to drive ... I checked the drive_state.shift_state and can see it as null both after a drive after exiting, and BEFORE a drive before entering, so I don't see how null shift_state helps you decide if the car wants to sleep or not ... I see it when it wakes up.
Ya, I don't think the logic about letting it go to sleep has any issues ... I'm more trying to figure out how you can catch a drive better when it wakes up, other than your apparent logic above of "unless it was seen as online prior" which catches the single transition from asleep to online, but then I'm unclear what goes on after that. Do you wait to see if it goes to sleep? Do you assume online = ready to drive and start polling until your 'hint' of null shift state?
Yes, most definitely it must be online. You would check this when you detect the car has become online.
I'm fully aware of only being able to check the state conditions I mentioned when the car is online, but I'm suggesting to check these for a short period of time after a car becomes newly-online, after waking up, so that you can determine if it's an pre-drive wakeup, or a random insomnia event during the night.
EDIT: Here's an example from my car ...
At the end of the night after a drive:
shift_state: "P", locked: false, is_user_present: true
shortly after that, before the car sleeps:
shift_state: null, locked: true, is_user_present: false
...
the next day after it was 'asleep' all night, after I wake it up in preparation to pre-condition it to cool off: shift_state: null, locked: true, is_user_present: false
(Note that this state is identical to the prior night's "going to sleep" state. If I paused polling here I'd miss the start of a drive.)
less than a minute later, after I turn pre-conditioning on:
shift_state: null, locked: true, is_user_present: false, same as above ... but now:
is_climate_on: true, is_preconditioning_true => this tells me I've turned the car on in prep to drive, and it's not trying to sleep.
Based on this last bit of info, I can continue polling to catch the start of a drive.
I don't see how shift_state helps me in catching the wake up -> pre-drive transition. I can see how it might help letting the car go to sleep at night, or after a pause in driving, but the reverse doesn't seem to be the case (for me anyways, as in my example above).
So I look for other hints (preconditioning, doors unlocked, user present) that a drive might be starting soon and then I can increase polling instead of trying to let it sleep.
Last edited:
KWReid
Member
This is the misunderstanding. You're suggesting I do some additional checks after a wake-up to determine if it's user-triggered or not, and if so, continue live polling. If not, start letting it go back to sleep.
I don't bother to do any other checks after waking up because my detail polling usually only lasts for a few minutes before the car starts indicating it's "ready to sleep" again by returning null shift_state.So attempting to accelerate the go to sleep state by immediately backing off the detail polling would only save me a few minutes of online time after a periodic wake-up. Doesn't seem to be worth the added complexity.
However I did miss pretty much all of my 13min drive home today because of bad timing on the sleep state. My car had just gone into that waiting-to-sleep state where shift_state was null, and my poller backed off just 1min before I got in the car to drive home. The next detail call was me at home with the car plugged in.
This goes back to that wake-up problem described before. I have no way yet to abort the 10-15min back-off I set up when getting this shift_state null. To do that I'd need to build some kind of signal that I trigger when getting into the car to reset the sleep waiting state of the polling app.
I could very quickly set up an web call endpoint that will reset the waiting to sleep state, and add that as a browser favorite in the car. Just refresh that page in the browser when I get in? That's still too manual for me.
I could set up a IFTTT (if this, then that) rule on my phone that when it connects to car bluetooth, it makes that web endpoint call. That'd be completely hands-off and automatic, but requires me to install IFTTT and configure a rule. More complex than I'd like.
darth_vad3r
Well-Known Sith
I see.
Obviously the solution is to just add 1 minute to your state transition
So, it sounds like this was (a) a drive, then (b) a short stop where it decided to back off, and then (c) a short drive that got missed?
Or if it’s not this, then is there a flaw in your checks for ready to sleep?
Perhaps my suggestion in jest above might be the solution. Wait longer to go to sleep during the times of day/days when it is more likely this pattern might occur. Lunch time at work, after work, weekends during the day?
There’s always going to be some cutoff you magically hit where you might miss 1-12 minutes of a drive, but if your stops are typically <X minutes you could set the delay to X and catch all the ones shorter than that. The cost would only be X-10 minutes of added wake time max per stop, less if your stop is shorter. You could also incorporate my previous suggestions to extend your waiting time if any user hints are detected suggesting a pending drive, despite the shift_state hint suggesting sleep is desired. How short is the period to get to shift_state null? I wonder if that just indicates if the user is authed to shift into gear still or not. I’m pretty sure I’ve seen it null while I’m in the car. e.g. It would be silly to have a drive, short stop where you are in the car waiting for someone else to run into a store and back, and your logger has backed off to let the car sleep when you could avoid that by checking for a butt in the seat.
It’s too bad the vehicle API has no hint about the driving state.
Has anyone figured out when the tokens in the vehicles response cycle? Could those refreshing possibly be related at all to car usage and a change in the tokens be used as a hint that the car is doing something? I just took a closer look at these in my historical data ... they seem to change several times overnight so I guess they are just short-lived expiry tokens. No luck there.
KWReid
Member
No this was me parked at work all day. Hadn't been driven since I'd arrived in the morning.
The car will wake up from sleep every 70min or so for a few minutes, and then go back to sleep. Here, it had just woken up a few min prior and was just starting to emit the shift_state = null indication it's getting ready to sleep, so my poller backed off for 10min. By the time it checked details again, I was already home.
For the case you suggested (drive, park for a bit, drive again) that might happen during running short errands, but I find that when I'm doing that the car doesn't as quickly try to go to sleep. It's like it waits for 30-60min before trying to sleep. I wonder if Telsa is doing some of their own logic to prevent the car from having to be woken up.
... I just realized I haven't seen any "car is getting ready" type messages from my car for a while. Could just be luck. Or the car could be learning schedules... or my poller is keeping it awake more often. <shrug>
darth_vad3r
Well-Known Sith
Interesting. What firmware version are you on? I thought maybe they’d backed off on the more frequent wake ups with people saying that drain seems to have gone down lately (with .20 or .24?)
Dan203
Active Member
So can anyone tell me how to determine the rear seat config using this API? I'm looking for a way to tell the difference between a Model S with a 2 seat "executive" setup and a standard 3 seat config, and a way to tell the difference between the 3, 4 & 5 seat configs on the Model X.
darth_vad3r
Well-Known Sith
Look at the option codes and refer to here:
Option Codes
Unfortunately the Model 3's all seem to report back the same black LR model options no matter what the config is, so I can't confirm the option codes are accurate, they should be for Model S still and probably for Model X they should be ... since that website has a bunch of codes for it?
In the /vehicles response look for "option_codes" which is a list of those codes:
{
"response": {
"id": xxxx,
"user_id": xxxx,
"vehicle_id": xxxx,
"vin": "xxxx",
"display_name": "xxxx",
"option_codes": "AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0",
"color": null,
[...]
Dan203
Active Member
Is there any way to check if the car is awake without actually waking up the car? Or do all of the functions just fail if the car is asleep and you don't send the wake call first?
Similar threads
