OpenEVSE
Only poll Tesla API when charging is active
After enabling the OpenEVSE Tesla integration I noticed a higher than average vampire drain (12 miles lost overnight) on a 2015 Model S. I setup TeslaMate which logs the state of the vehicle, as well as lots of useful info.
TeslaMate confirmed my suspicion that the car was not going to sleep. After the OpenEVSE Tesla integration was switched off at about 13:00 shortly after the car went to sleep.
@chris1howell @lincomatic can you replicate this experience? Have you noticed higher than usual vampire drain if using the OpenEVSE Tesla API? Do you have any other integrations running using the Tesla API? If so these could also be keeping the car awake. What is the usual vampire drain on your cars?
I'll continue to monitor and test this.
Polling the Tesla API will keep the car awake and prevent it from sleeping.
Right now we are always polling regardless of state. We could stop polling or poll way less often when the vehicle is not charging or driving.
On Fri, Jun 26, 2020, 4:31 PM Glyn Hudson [email protected] wrote:
After enabling the OpenEVSE Tesla integration I noticed a higher than average vampire drain (12 miles lost overnight) on a 2015 Model S. I setup TeslaMate https://github.com/adriankumpf/teslamate which logs the state of the vehicle, as well as lots of useful info.
TeslaMate confirmed my suspicion that the car was not going to sleep. After the OpenEVSE Tesla integration was switched off at about 13:00 shortly after the car went to sleep.
[image: Screenshot from 2020-06-26 21-22-04] https://user-images.githubusercontent.com/758844/85898185-bd5ac580-b7f3-11ea-88c1-c6d1042b81b4.png
@chris1howell https://github.com/chris1howell @lincomatic https://github.com/lincomatic can you replicate this experience? Have you noticed higher than usual vampire drain if using the OpenEVSE Tesla API? Do you have any other integrations running using the Tesla API? If so these could also be keeping the car awake. What is the usual vampire drain on your cars?
I'll continue to monitor and test this.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP32_WiFi_V3.x/issues/96, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN5QH6EPAPY33XGGRSDBYDRYUASRANCNFSM4OJUTB4A .
@glynhudson sorry, i don't have a Tesla, so I can't do much testing. I developed the API code using Chris' account
It polls the Tesla API by calling /api/1/vehicles/#{id}/vehicle_data regularly. Wouldn't it be better to use the streaming websocket API instead?
Tesla doesn’t care for their servers being polled repeatably so a streaming websocket API solution might be better?
Advantages would be:
- Instantaneous updates of car data (around once per second) - no polling delays
- No waking up in case the car is sleeping (not 100% sure about this though - but it seems to be the case in my tests)
- More future-proof, since the Tesla app also seems to be abandoning the polling method
Some code samples: https://github.com/timdorr/tesla-api/blob/master/lib/tesla_api/stream.rb https://github.com/mseminatore/TeslaJS/pull/158/files#diff-8cc7128b6d8cb9a5b8a5fbdc3dd86338
edit/ Also Teslamate uses this idea...
Polling the Tesla API will keep the car awake and prevent it from sleeping.
I've added a note to the docs to mention the increased vampire drain if using the integration.
This doesn't seem optimal, loosing approx 12 miles/day. That's a lot of energy over a year! Also increased wear on the MCU and DC-DC converter since it's running pretty much continuously. Only polling when charging/driving and less regularly sounds sensible.
@glynhudson sorry, i don't have a Tesla, so I can't do much testing. I developed the API code using Chris' account
Nor do I, I borrowed one from a family member for testing
Wouldn't it be better to use the streaming websocket API instead?
That sound like a good solution. Would you be able to put together a pull-request for this if you're familiar with the API?
The streaming API is not yet well documented, for now we should only poll while actively charging as the vehicle will already be awake. If the station status is error, connected or Ready we can stop polling to allow the vehicle to sleep. In the future we could add the streaming API or polling while driving to update the display with real time charge time estimates.
On Sun, Jun 28, 2020 at 6:06 PM Glyn Hudson [email protected] wrote:
Polling the Tesla API will keep the car awake and prevent it from sleeping.
I've added a note https://github.com/OpenEVSE/ESP32_WiFi_V3.x/commit/e7fd6aa405249e61ebe32c9185ae0bd7f5e4de43 to the docs to mention the increased vampire drain if using the integration.
This doesn't seem optimal, loosing approx 12 miles/day. That's a lot of energy over a year! Also increased wear on the MCU and DC-DC converter since it's running pretty much continuously. Only polling when charging/driving and less regularly sounds sensible.
@glynhudson https://github.com/glynhudson sorry, i don't have a Tesla, so I can't do much testing. I developed the API code using Chris' account
Nor do I, I borrowed one from a family member for testing
Wouldn't it be better to use the streaming websocket API instead?
That sound like a good solution. Would you be able to put together a pull-request for this if you're familiar with the API?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenEVSE/ESP32_WiFi_V3.x/issues/96#issuecomment-650828257, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN5QH7FG3ASUH2CQ5D7FFDRY65E3ANCNFSM4OJUTB4A .