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.
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.
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.
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?
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.
Yes, most definitely it must be online. You would check this when you detect the car has become online.
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.
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.