Thoughts on developing 'smart' refresh function, best practices/suggestions?
cr08 opened this issue · 2 comments
Currently I am working on a fork of this code, basically making it standalone outside HA for my own (and potentially public use in the future) use. The more I play with things, the more useful and amazing stuff I'm seeing so massive kudos for the work so far!
I'm currently trying to brainstorm how best to make a 'smart' refresh function that minimizes 12v battery drain AND try to avoid Ford's banhammer as best I can. Currently I already have the basic status update check at the normal 15m interval.
I see how the current refresh function basically just polls the existing status request repeatedly until the refresh status updates with a success/fail/expire status. I've rewritten this in my fork just to return the full status json on success instead of 'True' to save an extra unneeded status poll. Not sure if there's a specific reason it is set this way in the HA integration unless the True/False response is to satisfy HA automations and such.
As far as when to refresh (This is largely focusing on my 2013 C-Max Energi which is an early Ford PHEV and is missing a number of data points newer vehicles have. But some of this could still apply for newer PHEV/EV models) is as follows:
Ignition status OFF, charger status DISCONNECTED
Refresh every couple hours or so or just avoid altogether? Useful updates are unexpected in this state. An ignition ON change or charger plug-in should trigger an automatic update from the vehicle?
ignition status ON
Refresh status every 15m. We're assuming the vehicle is running and continual 12v power is being provided. Not sure how happy Ford will be with this since the refresh command polls the status endpoint a few times on its own to verify completion.
Maybe add some conditions where if the refresh fails/expires on a few repeated attempts after the ignition ON status appears, fail back to normal status polling until the vehicle state changes or extend time between attempts until a success? One situation I can see this helping with is being in an area with no ATT service.
ignition status OFF, charger status CONNECTED Refresh every hour(?). EVSE is plugged in. Need to verify but I seem to recall a refresh command waking the vehicle will have the EVSE start supplying 12v power again via the onboard charger. Could make that optional/configurable if the extra usage is unwanted.
Alternatively I could adjust the refresh rate based on charging status. Unfortunately scheduled charging, at least on these early models, doesn't seem to say WHEN it is scheduled at least inside the main vehicle status data. Could do the 15m refresh or extend it a bit to like 30m or 1h. If the charge status changes to IN_PROGRESS, we can get the xevBatteryTimeToFullCharge, determine the estimated finish time from the update time of the IN_PROGRESS status. I'd have it start refreshing every 15m or so starting a 30m-1h prior (With my vehicle at least, it'll finish charging some not-insignificant amount of time before the car estimates it'll finish. Likely due to battery degradation.) until it shows complete and then go back to 'sleep' and do basic status checks at the base 15m intervals.
Right now with my modified code I have it set to run under a basic cron job at the aforementioned 15m intervals. I'm thinking just to have these conditions in the same job and if a refresh is needed, it'll take place of the normal status retrieval instead of doubling up especially since the refresh will return the status anyways on success.
Anything I'm potentially missing here or any suggestions for improvement? Or does this all seem sound? I think the biggest thing I'm worried about is just trying to avoid running into Ford's banhammer and keep queries reasonable.
Hi @cr08
To answer a few of your points:
-
Status function does a separate poll to refresh all HA entities as the service call needs to return True/False for HA to do it's thing. It could probably be rewritten to be a little smarter on the API call handling but it's finding the time :)
-
In terms of smart polling etc. What you can currently do and it's what I do is have an automation that checks if the ignitionStatus is set to On if so it polls the API every minute or two until the IgnitionStatus goes back to Off. This is separate from the 15min set interval as you can just call the poll_api service request inside your automation.
I know @SquidBytes was looking into more charging orientated status's and automations however he's been busy with personal things. As said you can easily create automations in HA or outside if your running it standalone that monitor certain values as you mentioned and then just manually poll the API yourself to retrieve the data as often as you want. You could even set the auto poll interval to like every 24hrs so it's entirely dependent on your automations for updates.
Obviously just be careful with how often you poll the API as Ford have not released any details on what the API call limits are.
Awesome! So it looks like I'm on the right track and not the only one that's went down this thought process. 😅
In terms of smart polling etc. What you can currently do and it's what I do is have an automation that checks if the ignitionStatus is set to On if so it polls the API every minute or two until the IgnitionStatus goes back to Off. This is separate from the 15min set interval as you can just call the poll_api service request inside your automation.
Just to confirm since the terminology is a bit weird and easy to mix together, but the polling you do every minute is that just the basic get_status polling or is this the full refresh that calls for the vehicle to update? I'll probably stick to the 15m interval initially if only to play it safe. As you said, Ford hasn't published anything because technically this isn't an approved use of their API. But if I can increase that later, that would certainly be handy if it is the full refresh.
Yeah, I read some of Squid's comments elsewhere and family/personal stuff definitely comes first. But I think there may very well be some crossover in some of our work as things progress. Right now my ultimate intent intent is to have a dedicated web dashboard to return a lot of features that Ford has given up on for these 1st gen PHEVs like having full trip data, potentially charge 'logs', and whatever other useful data I can add in a user friendly manner. Unfortunately it seems like there's a lot of inferring to do with the data provided and figuring how to build all the logic for that.
I guess the next thing on my agenda to sort out and not sure if I should just keep it here or open a new issue is if anyone has tried to figure out how to correlate individual trips from the trip specific data points? I know on my vehicle there's no longer any direct trip/journey status info available, just the individual datapoints from the API. Not sure if this is the same for other vehicles. My original thought was using the correlation ID but I've found in some cases that updates on a refresh (including the update time) even if the vehicle hasn't moved. But if no one has any ideas on this, I can continue to pour over all the logs I have so far (I've had my script running for over a week and it saves an individual json file of the status endpoint every 15m. Just to have plenty of data to test with) and see if there's any logic I can use on that. May just be going back to the ignition on/off status.