Feature request: IsChargerConnected and IsSOCbelowChargingLimit via BLE

[osimmert]

To implement solar charger logic using BLE, it would be helpful to know if a charging cable is plugged in and if the battery currently needs charge. (Reading the SOC via BLE also would be nice to implement a display)

[sftman18]

I believe this is covered in #52

[osimmert]

It would be important that the two infos could be obtained without waking up the car.
If a solar charger want's to charge, it needs to wake up the car and try start charging. The charging-start command may fail due to several issues:

• Charging already in progress (started manually or by App)
• Car not plugged in
• Battery already fully charged
• BLE TX/RX error
• Car not awake
  As the solar charger does not know the reason of the error, it needs to retry to start charging.
  Due to that, the car is kept awake all the time if the battery is fully charged or the car is not plugged in.
  This needs to be improved.

[sethterashima]

Partially addressed by: #263

I believe infotainment stays awake while charging, but I'll need to confirm that internally. This would mean that if the above method indicates the car is asleep or the charge port is closed, then the car is not plugged in. The reverse is heuristic; it's possible for the car to be awake with an open charge port but not plugged in.

[osimmert]

Most important thing is: If the solar system gets the info that the charge port is currently closed, it has to poll the car to find out if it became plugged in.
This polling (either for the charge port or for plugged in) must be possible without waking the car. Otherwise the car would be waked by every poll.

[sethterashima]

This change allows you to determine if the charge port is open without waking up the car.

Most important thing is: If the solar system gets the info that the charge port is currently closed, it has to poll the car to find out if it became plugged in.

I'm not sure what you're saying here. If the charge port is closed, the car is not plugged in.

[tzoratto]

Partially addressed by: #263

I believe infotainment stays awake while charging, but I'll need to confirm that internally. This would mean that if the above method indicates the car is asleep or the charge port is closed, then the car is not plugged in. The reverse is heuristic; it's possible for the car to be awake with an open charge port but not plugged in.

hi @sethterashima, thanks for your answers.

Have you confirmed that infotainment is awake when charging ?

If this is the case, then we can implement solar charging more easily, but there are still some corner cases that would need dirty workarounds without access to the current SOC and charging limit:

• we won't know when to stop sending charging amps settings to the car based on solar production. A workaround would be to wait for 10 minutes between each update and to check if infotainment is still awake or not to give the car a chance to sleep after charging is over. But waiting 10 minutes between each update doesn't sound acceptable to me. We could instead "randomly" wait for 10 minutes from time to time, but it clearly is a dirty workaround.
• we won't be able to start or stop charging at appropriate times based on solar production. We would need to schedule charging from the car (at 9AM every day let's say, when solar production is supposed to kicks in, but it would be a static setting), and then rely on that by checking if the car is awake and charge port open, meaning that charging has started and that we can update charging amps. Stopping charging automatically (when the solar production is too low, and then resuming charging later on) on top of that would be complex to implement, as we would have to make almost blind guesses to know if the car still actually needs charging or not

To sum it up, the risk here is either to:

• have an implementation that will send commands frequently that keep the car awake, even when no charging is required
• have an implementation that does not wake the car up all day long every day inappropriately, but which is really complex and fragile, and we all know what it means => it will only work in the short term

Using the Fleet API only to fetch data, and then use the BLE one to send commands (so that we don't hit the super low Fleet API rate limits) is technically possible, but fetching data from the Fleet API also comes with low rate limits, using the Fleet API also is a pain in the neck for individuals, and it will eventually be charged. Don't get me wrong, I understand why the Fleet API needs to be charged in the end, handling millions of calls is not cheap in terms of infrastructure, but that's why having a local BLE option in addition to the Fleet API is all for the best.

Are there any plans to make the SOC + charging limit available from BLE ?

Bonus question: instead of implementing this by communicating with the car, could we use an official local API for the Tesla Wall Connector Gen 3 ? It would probably make the all thing way simpler, without having to take care about not waking up the car when not needed. We could leave the car do whatever it wants, and only set the Wall Connector amps continuously. I was under the impression that the legacy local API for the Wall Connector was also being deprecated and replaced by the Fleet API. It this the case ? And is there any local official alternative just like we have with BLE for the car ?

Thanks

[osimmert]

Just to clarify: It is already possible to continuously change the charging amps while charging.

For the Wall Connector: There are countries where 3 phases are not common (e.g Spain). In that countries the Wall Connector has no advantage over the charging brick. For that reason a 'wall-box-only' solution is not sufficient for many customers. (But may be nice for the 3 phase guys. 8-)

[tzoratto]

Just to clarify: It is already possible to continuously change the charging amps while charging.

Interesting, could you expand on that please ? From my understanding, all we can do for now is either send "charging amps settings" blindly, that will wake the car up if it doesn't need charging, or we can use #263 to see if the car is (only) likely to be currently charging and send commands only if this is the case, but there are many corner cases, such as the one that I mentioned above (and many more).
Am I missing something ?

For the Wall Connector, yes it would only be a solution for customers that have one of them, but still, if we could talk to it locally (officially), it would still be nice.

[osimmert]

With #263, IsChargerConnected is well covered (charge port will not be open otherwise)
For IsSOCbelowChargingLimit or the current SOC there is still a solution required. But for this information it is OK to wake the car. If the charger has seen that the battery is full there is no need to ask again (at least that day).

[tzoratto]

For IsSOCbelowChargingLimit or the current SOC there is still a solution required

Ok, then we are aligned, we still need IsSOCbelowChargingLimit (or current SOC + charging limit) to implement solar charging properly using BLE. #263 helps, but is not enough to cover edge cases