Tesla BLE Module keeps Car awake after reaching cars SOC Limit in PV Mode #14952
Comments
|
Did you try setting the limit in evcc instead of the vehicle? As long as the eallbox is enabled, evcc will update the power envelope. /cc @Maddimax seems this needs be handled by the proxy? Not sure how we did this with the http api. |
|
The https://github.com/wimaha/TeslaBleHttpProxy proxy automatically tries to wake up the car any time a command fails. It does not use the mechanism you build to return errors about the wake state. The two options are to update the proxy, which (I think is not possible/means a rewrite) as it executes the requested commands async after it already ended the http request, or to change EVCC to not send power changes unless the vehicle is actually charging. |
|
We could change the TWC. But whats the logic? When not charging we still need to enable the charger at some point |
evcc over HTTP doesn‘t do this and handles wakeup in the loadpoint when it sees an api.ErrAsleep as appropriate. Seems this might be needed here, too? |
I just tested it. What strikes me: This information is missing if the vehicle specifies the charging limit and therefore ends charging automatically. Although the WebGUI shows that the vehicle has reached the vehicle's charging limit and the charging process is complete, the above-mentioned note is missing in the log file. The question for me is, why does EVCC continue to send control commands when it detects that the vehicle has reached the vehicle's charging limit? LP1 Log - Charging Limit sets in EVCC LP1 Log - Charging Limit sets in Car |
|
I set the vehicle max soc to 90% (in the tesla app) to stop charging, interestingly I now see evcc trying to restart the charge. From the log of my personal ble proxy: (This probably means that even with my proxy, evcc would then try to wake the car once it gets the errAsleep) |
|
Even after adding "limitsoc:" to my custom vehicle definition, evcc is still trying to start charging. |
|
Was spräche dagegen, bei schlafendem Auto ErrAsleep zurück zu geben und das Wakeup evcc zu überlassen? So ist es bei Http auch. Der Wakeup auf Proxy-seite ist hier unerwartet. |
|
Wenn ich das Log richtig verstehe, dann hat EVCC in meinem Fall selber das Fahrzeug über den Fleet API Dienst von Tesla geweckt. Dann würde das an der BLE HTTP Proxy Mechanik nichts ändern. Liegt das Problem nicht vielmehr darin, dass EVCC den Ladevorgang, obwohl er laut Web GUI beendet ist, wieder starten möchte und zusätzlich den Ladestrom kontinuierlich anpasst? Das dürfte ja nicht passieren, wenn EVCC den Ziel SOC des Fahrzeugs bereits kennt und auch den aktuellen SOC. |
|
Wenn der limit soc bekannt und erreicht ist sollte das nicht mehr passieren. Hilfreich wäre ein Log mit Tesla und custom charger auf trace. |
|
Seeing this same issue on single vehicle (Tesla M3) with TWC and Tesla BLE module. Even after reaching 100% and showing as such in the evcc UI, evcc continues to send set_charging_amp messages to Tesla BLE. This keeps the car awake for no reason. If EVCC can tell the charging is finished, as shown in the UI, why is it continuing to send these commands? EVCC log extract, many minutes after charge 100% completion: BLE Log extract, many minutes after charge 100% completion: |
|
There is no signalisation for "finished". SOC 100% does not tell you anything about the energy consumption of the whole vehicle. |
|
I don’t think that’s what’s happening here. The car isn’t drawing a charge. Instead EVCC is repeatedly telling TesleBLE the new charge rate every time the available solar changes which in turn prevents the vehicle ever sleeping (unless unplugged) This doesn’t seem right? |
|
evcc is doing what it does with every other charger- adjust the rate as long as the vehicle is connected. It does specifically not intentionally wake the vehicle up. Given that BLE connection requires awake vehicle we'd probably need to change this in evcc- not sure we should do this. |
|
Thanks for considering it at least. I'm not familiar with Go but from reading the codebase it would seem like something as simple as changing like below would prevent it changing the amps/keeping vehicle awake when not charging. core/loadpoint.go line 1861 to: I was going to run this to test impacts locally but it seems like due to not having a TESLA_CLIENT_ID or secret the template for Tesla won't initialise so can't really validate it, and command_proxy doesn't seem supported for Tessie or TeslaMate integrations. Anyway, hope you could consider implementing this or some parameterised version of it if there's impacts on other vehicle/charges. |
|
Can't do that (at least in this place) since it's also handling on/off there. |
Seems this is only happening when there is enough power. So this seems acceptable, if not perfect? |
Describe the bug
Hello,
I have two Tesla Model Ys and two Tesla TWC3s. The control runs via the new function of the BLE Proxy.
If one Vehicles has reached its Car Charging Limit in PV Mode, then EVCC continues to send Charging Currents to the BLE proxy and keeps the Car awake:
[tesla ] TRACE 2024/07/21 12:32:43 POST http://192.168.178.121:8080/api/1/vehicles/VIN1/command/set_charging_ampsand wakes up the Vehicle via Web API Proxy:
[tesla] TRACE 2024/07/21 12:15:42 POST https://fleet-api.prd.eu.vn.cloud.tesla.com/api/1/vehicles/VIN1/wake_upOn the EVCC homepage, the Charging Process is shown as complete and also that the vehicle SOC limit has been reached.
I have the same behavior when the vehicle has no Charging Limit set and it has reached 100%.
When I charge in fast Mode, EVCC sends wake up and Charge Start Commands
NOTE: I have made some places unrecognizable in the Log File and the Config.
Steps to reproduce
Workaround: Set charging control from PV to Stop. Only then does EVCC stop.
Configuration details
Log details
What type of operating system are you running?
HomeAssistant Add-on
Version
0.128.3
The text was updated successfully, but these errors were encountered: