(Dev) Commands not going through if vehicle is asleep

[FraBoCH]

Hi, I’m trying to use your ble implementation (using the dev branch to have the « wake » command) with evcc and it is not working as expected when the car is asleep, which is most of the time in my case.

Here is a scenario I observed this afternoon looking at the logs:

1. Evcc is sending the command « set amps ».
2. The ble command fails and enters in the 5 attempts retry
3. In the meantime, evcc notice nothing is happening, suppose correctly that the vehicle is asleep, and sends a « wake » command

At that point, your implementation continues to retry (even starting the « second call » even if the first failed) and seems to ignore the new wake request that could help.

I thus suggest either improving the error handling and transparently wake the vehicle (this is what https://github.com/wimaha/TeslaBleHttpProxy is doing), or change the loop logic to process immediately the « wake » command.

Let me know if you need more information and I would be happy to help testing a fix!

[iainbullock]

Thanks for your observations and comment on this. What is the 'evcc'?

There is a plan to update the code to not keep trying if commands can't work, as this 'chokes' the loop unnecessarily. (See https://github.com/iainbullock/tesla_ble_mqtt_docker/issues/17 ). Maybe also to send a wake command if the first attempt fails with a message code that indicates the car is asleep.

I am working with this project in parallel so we will look at this

https://github.com/raphmur/tesla-local-control-addon

[raphmur]

EVCC is a standalone service to manage solar I think. https://evcc.io/en/ Looks nice, but different from HA

I think the thing would be to add a control loop to send a wake command if the normal command fails. Indeed we would need to: 1/ Process the stdout to differentiate between "cannot connect" and "cannot execute" 2/ Force send a wake command if "cannot connect" occurs more than 5 times... 3/ Bonus: warn the user or HA error message (via MQTT entity) if car is not present and command is sent via BLE

[FraBoCH]

Yes, it is this evcc. I switched from custom made automation in ha to this system and I’m reaching much better auto-consumption of my solar production. And it is available as a HA add on as well 😉

Le lun. 24 juin 2024 à 10:58, Raphael Murray @.***(mailto:Le lun. 24 juin 2024 à 10:58, Raphael Murray < a écrit :

EVCC is a standalone service to manage solar I think. https://evcc.io/en/ Looks nice, but different from HA

I think the thing would be to add a control loop to send a wake command if the normal command fails. Indeed we would need to: 1/ Process the stdout to differentiate between "cannot connect" and "cannot execute" 2/ Force send a wake command if "cannot connect" occurs more than 5 times... 3/ Bonus: warn the user or HA error message (via MQTT entity) if car is not present and command is sent via BLE

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[raphmur]

See https://github.com/tesla-local-control/tesla-local-control-addon/pull/40 for stdout/stderr simple processing. It does not solve the issue of continuously sending message if the car is asleep. But it's a start

[raphmur]

@FraBoCH https://github.com/tesla-local-control/tesla-local-control-addon/pull/40 has been merged in the addon (not yet included in the standalone, planned this week). It solves the countless retries. Any chance that EVCC itself can send a wake command it nothing is happening?

@iainbullock We can maybe try and create a new entity "wake needed" which is set to True when the retries have been done for 5 times. As for now (in the addon code) the retries are stopped if the car has answered

[MrBLJ]

@FraBoCH Would you mind sharing your EVCC yaml config ? I'm very interested in this but I'm not sure how to make it work with the mobile connector, or a dumb wallbox.

[FraBoCH]

@raphmur evcc will indeed send a wake command by itself if nothing happens (point 3 of my initial description).

@MrBLJ for now, the only solution appears to setup a custom vehicle using TeslaMate to fetch the "read" information needed like the soc. Here is the corresponding yaml for the vehicle. The rest of evcc config depends on the rest of your setup: solar system, wallbox, etc. Please refer to evcc documentation for that.

- name: tesla
  type: custom
  capacity: 74
  chargeenable:
    source: mqtt
    topic: tesla_ble/command
    payload: '{{if .chargeenable}}charging-start{{else}}charging-stop{{end}}'
  maxcurrent: # set charger max current (A)
    source: mqtt
    topic: tesla_ble/charging-amps
    payload: '{{.maxcurrent}}'
  wakeup: # vehicle wake up command
    source: mqtt
    topic: tesla_ble/command
    payload: 'wake'
  soc:
    source: mqtt
    topic: teslamate/cars/2/battery_level
    timeout: 8h
  range:
    source: mqtt
    topic: teslamate/cars/2/est_battery_range_km
    timeout: 8h
  status:
    source: combined
    plugged:
      source: mqtt
      topic: teslamate/cars/2/plugged_in
      timeout: 8h
    charging:
      source: mqtt
      topic: teslamate/cars/2/charging_state
      timeout: 8h

[MrBLJ]

@raphmur evcc will indeed send a wake command by itself if nothing happens (point 3 of my initial description).

@MrBLJ for now, the only solution appears to setup a custom vehicle using TeslaMate to fetch the "read" information needed like the soc. Here is the corresponding yaml for the vehicle. The rest of evcc config depends on the rest of your setup: solar system, wallbox, etc. Please refer to evcc documentation for that.

- name: tesla
  type: custom
  capacity: 74
  chargeenable:
    source: mqtt
    topic: tesla_ble/command
    payload: '{{if .chargeenable}}charging-start{{else}}charging-stop{{end}}'
  maxcurrent: # set charger max current (A)
    source: mqtt
    topic: tesla_ble/charging-amps
    payload: '{{.maxcurrent}}'
  wakeup: # vehicle wake up command
    source: mqtt
    topic: tesla_ble/command
    payload: 'wake'
  soc:
    source: mqtt
    topic: teslamate/cars/2/battery_level
    timeout: 8h
  range:
    source: mqtt
    topic: teslamate/cars/2/est_battery_range_km
    timeout: 8h
  status:
    source: combined
    plugged:
      source: mqtt
      topic: teslamate/cars/2/plugged_in
      timeout: 8h
    charging:
      source: mqtt
      topic: teslamate/cars/2/charging_state
      timeout: 8h

Thanks a lot ! So it appears I need teslamate. Do you also have the Tesla Custom integration ? I’m concerned that if I use Teslamate in addition to the proxy and the custom integration, it’d cause some issues and/or query the car too much.

[FraBoCH]

The source of data can also be http (see https://docs.evcc.io/en/docs/reference/plugins#http-readwrite), so there is probably a way to use the data from ha Tesla integration instead of TeslaMate.

Le sam. 29 juin 2024 à 06:09, MrBLJ @.***(mailto:Le sam. 29 juin 2024 à 06:09, MrBLJ < a écrit :

@.***(https://github.com/raphmur) evcc will indeed send a wake command by itself if nothing happens (point 3 of my initial description).

@.***(https://github.com/MrBLJ) for now, the only solution appears to setup a custom vehicle using TeslaMate to fetch the "read" information needed like the soc. Here is the corresponding yaml for the vehicle. The rest of evcc config depends on the rest of your setup: solar system, wallbox, etc. Please refer to evcc documentation for that.

• name: tesla type: custom capacity: 74 chargeenable: source: mqtt topic: tesla_ble/command payload: '{{if .chargeenable}}charging-start{{else}}charging-stop{{end}}' maxcurrent: # set charger max current (A) source: mqtt topic: tesla_ble/charging-amps payload: '{{.maxcurrent}}' wakeup: # vehicle wake up command source: mqtt topic: tesla_ble/command payload: 'wake' soc: source: mqtt topic: teslamate/cars/2/battery_level timeout: 8h range: source: mqtt topic: teslamate/cars/2/est_battery_range_km timeout: 8h status: source: combined plugged: source: mqtt topic: teslamate/cars/2/plugged_in timeout: 8h charging: source: mqtt topic: teslamate/cars/2/charging_state timeout: 8h

Thanks a lot ! So it appears I need teslamate. Do you also have the Tesla Custom integration ? I’m concerned that if I use Teslamate in addition to the proxy and the custom integration, it’d cause some issues and/or query the car too much.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[MrBLJ]

The source of data can also be http (see https://docs.evcc.io/en/docs/reference/plugins#http-readwrite), so there is probably a way to use the data from ha Tesla integration instead of TeslaMate.

Thanks for the tip, I think I get it. Looking deeper into this, I guess I need Teslamate afterall : my goal is to use my mobile connector as a charger and it seems there's a workaround that also uses TeslaMate : https://github.com/Haveacry/twc3teslamate

May I trouble you again for the rest of you config ? Incl. site, charger and the rest ? Thanks for any help you can provide :)

[FraBoCH]

Back to the initial issue, I can confirm that a similar project implementing a HTTP proxy using directly the tesla go library (https://github.com/wimaha/TeslaBleHttpProxy) is avoid this problem by automatically sending a « wake » command when receiving the error « context deadline exceeded ». And I can confirm it is working flawlessly for me in evcc for several days. 

[iainbullock]

Thanks a lot for the feedback, we will investigate doing something similar

[MrBLJ]

@raphmur evcc will indeed send a wake command by itself if nothing happens (point 3 of my initial description).

@MrBLJ for now, the only solution appears to setup a custom vehicle using TeslaMate to fetch the "read" information needed like the soc. Here is the corresponding yaml for the vehicle. The rest of evcc config depends on the rest of your setup: solar system, wallbox, etc. Please refer to evcc documentation for that.

- name: tesla
  type: custom
  capacity: 74
  chargeenable:
    source: mqtt
    topic: tesla_ble/command
    payload: '{{if .chargeenable}}charging-start{{else}}charging-stop{{end}}'
  maxcurrent: # set charger max current (A)
    source: mqtt
    topic: tesla_ble/charging-amps
    payload: '{{.maxcurrent}}'
  wakeup: # vehicle wake up command
    source: mqtt
    topic: tesla_ble/command
    payload: 'wake'
  soc:
    source: mqtt
    topic: teslamate/cars/2/battery_level
    timeout: 8h
  range:
    source: mqtt
    topic: teslamate/cars/2/est_battery_range_km
    timeout: 8h
  status:
    source: combined
    plugged:
      source: mqtt
      topic: teslamate/cars/2/plugged_in
      timeout: 8h
    charging:
      source: mqtt
      topic: teslamate/cars/2/charging_state
      timeout: 8h

Thanks again for this detailed reply. I have my system (almost) working. Commands can't be set because mqtt qos must be set to 1 for the service to register. Have you been faced with this issue ? To your knowledge, is there a way to set qos for mqtt messages sent by evcc ? I've checked the doc and there appears to be none.

[raphmur]

We have set qos to 0 to prevent locks in case the mqtt command cannot be processed. But it could be set as an option @iainbullock , what do you think?

[MrBLJ]

Just to make sure I'm clearly describing the situation :

1. The MQTT button provided by the addon (standalone in my case) works fine.
2. In HA, using a service call, this fails (not registered) :

   service: mqtt.publish
   data:
   payload: flash-lights
   topic: tesla_ble_mqtt/MYVIN/command

3. In HA, using a service call, this succeeds (not registered) :

   service: mqtt.publish
   data:
   payload: flash-lights
   topic: tesla_ble_mqtt/MYVIN/command
   qos: 1 # This is what makes it work

In mqtt explorer, this is what I can see :

[iainbullock]

We have set qos to 0 to prevent locks in case the mqtt command cannot be processed. But it could be set as an option @iainbullock , what do you think?

QOS has to 1 be whilst we are still using the -E -c -i options for mosquito_sub in the main listening loop. Now we are confident that BLE presence detection can run in parallel we can drop these which will allow QOS=0. I was going to submit a PR and work on this (once I'm on top of the use of sub modules)

[MrBLJ]

We have set qos to 0 to prevent locks in case the mqtt command cannot be processed. But it could be set as an option @iainbullock , what do you think?

QOS has to 1 be whilst we are still using the -E -c -i options for mosquito_sub in the main listening loop. Now we are confident that BLE presence detection can run in parallel we can drop these which will allow QOS=0. I was going to submit a PR and work on this (once I'm on top of the use of sub modules)

Great news ! I think it's the last bump on the road before I get EVCC running, which looks very promising so far : If you think it can be useful, I'll write a full setup procedure from start to finish for this addon. There are a few tricks to overcome.

[raphmur]

FYI, there is a new feature introduced in the teslamotors/vehicle-command repo allowing for capture minimal info state.

Eg. When vehicle is asleep:

{
        "vehicleLockState":  "VEHICLELOCKSTATE_LOCKED",
        "vehicleSleepStatus":  "VEHICLE_SLEEP_STATUS_ASLEEP",
        "userPresence":  "VEHICLE_USER_PRESENCE_NOT_PRESENT"
}

When vehicle is awake:

{
        "closureStatuses":  {
                "frontDriverDoor":  "CLOSURESTATE_CLOSED",
                "frontPassengerDoor":  "CLOSURESTATE_CLOSED",
                "rearDriverDoor":  "CLOSURESTATE_CLOSED",
                "rearPassengerDoor":  "CLOSURESTATE_CLOSED",
                "rearTrunk":  "CLOSURESTATE_CLOSED",
                "frontTrunk":  "CLOSURESTATE_CLOSED",
                "chargePort":  "CLOSURESTATE_OPEN",
                "tonneau":  "CLOSURESTATE_CLOSED"
        },
        "vehicleLockState":  "VEHICLELOCKSTATE_LOCKED",
        "vehicleSleepStatus":  "VEHICLE_SLEEP_STATUS_AWAKE",
        "userPresence":  "VEHICLE_USER_PRESENCE_NOT_PRESENT"
}

--> Closing this issue as solution was found for this issue (read above). @FraBoCH can you draft a short "howto" in a separate issue? Merci!

@iainbullock @baylanger I am opening an issue in _core dedicated on this new command.

[dglaude]

Dear @raphmur, I have some doubt that the initial real problem from @FraBoCH has been solved. @FraBoCH found that the strategy to wake after failure to send a message (and retry) as implemented by https://github.com/wimaha/TeslaBleHttpProxy and works for him when that is used by evcc.

I am using evcc, and I was using TeslaBleHttpProxy, except that after a few days it would become non-responsive... this is the reason I am now trying to use Tesla_Ble_Mqtt.

However, this project (used by evcc) only work for me if:

• The Tesla is awake (like when I plug the car and it is sunny)
• I wake the car with the Home Assistant button
• I wake up the car or I start the charge using the Tesla app (when I know it is the right time

But if it is sunny and working, then I start using a lot of electricity in the house (or cloud) so that the charge is stopped by evcc, and then the Tesla fall asleep... it will not restart automatically.

In that case, evcc will fail to wake up the car, then keep trying to change the AMP but without success.

Could you revisit the original issue? (I think I had discuss this already, but could not found the thread with more details and logs)

[iainbullock]

@dglaude the latest release v0.2.2 has an autowake feature. I published it to Dockerhub last night, so it is available if you wish to test it for your application.

[dglaude]

So far so good, I upgraded over lunch... but I need a raising sun after a night with the Tesla sleeping (I don't even know after how much time the car goes to sleep).

[dglaude]

It is working and not working, let me explain.

WHAT I SEE

Here is what I see in the log bellow (and on EVCC).

On occasion, the "tesla_ble_mqtt" does wake up the car by issuing a "command:-domain vcsec wake".

But the repeated 5 time command that should have triggered a wake up did not: "command:charging-set-amps 5" <= Why it was not issuing a wake in this case?

And the next repeated 5 time command did trigger a wake up: "command:charging-start" <= Why this time it is issuing a wake?

But after the successfull wake up, the command was not resend, and the car is awake, but not charging. EVCC is waiting for the car to start charging, but does not repeat the "command:charging-start". What EVCC does is to keep updating the charging amps with successfull "command:charging-set-amps 8" and "command:charging-set-amps 10".

But the car is not charging (at least not without manual intervention).

POSSIBLE FIX

Maybe the solution it to remember the command that was issued and tryed 5 times without success. At that time issue a wake, and if the wake is successfull, repeat the command that failed 5 times. The only problem is that this command is now more that 5 times 5 seconds later, so because of the timeouts, it take up to 30 seconds. So maybe it is not super great to send a command to the car so long after it was requested. But as long as we keep the sequence of request we should be fine and match EVCC internal state. I don't think EVCC knows if the command was send successfully or not. And obviously EVCC does not try multiple time to start the charge, the command seems never repeated. <= Obviously, EVCC could detect that the car is not charging request again...

THE LOG

Received MQTT message; topic:tesla_ble/XP7YXXXX0XX000000/charging-set-amps msg:5 vin:XP7YXXXX0XX000000 cmd:charging-set-amps
Attempt 1/5 sending Set charging Amps to 5 to vin:XP7YXXXX0XX000000 command:charging-set-amps 5
VIN:XP7YXXXX0XX000000
PRESENCE_EXPIRE_TIME:1726497972
listen_to_ble; calling check_presence() BLE_LN:Sa1234567890123456 BLE_MAC:BLE_MAC
vin:XP7YXXXX0XX000000 ble_ln:Sa1234567890123456 match:(Sa1234567890123456|74:B8:DE:AD:BE:EF) presence detected
vin:XP7YXXXX0XX000000 ble_ln:Sa1234567890123456 update presence expire time to 1726498103
listen_to_ble; macAddr:74:B8:DE:AD:BE:EF BLE_MAC:74:B8:DE:AD:BE:EF
listen_to_ble; BLE_MAC_LIST:74:B8:DE:AD:BE:EF
tesla-control send command:charging-set-amps 5 to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
teslaCtrlSendCommand; Retrying in 5 seconds
Attempt 2/5 sending Set charging Amps to 5 to vin:XP7YXXXX0XX000000 command:charging-set-amps 5
tesla-control send command:charging-set-amps 5 to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
teslaCtrlSendCommand; Retrying in 5 seconds
Attempt 3/5 sending Set charging Amps to 5 to vin:XP7YXXXX0XX000000 command:charging-set-amps 5
tesla-control send command:charging-set-amps 5 to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
teslaCtrlSendCommand; Retrying in 5 seconds
Attempt 4/5 sending Set charging Amps to 5 to vin:XP7YXXXX0XX000000 command:charging-set-amps 5
tesla-control send command:charging-set-amps 5 to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
teslaCtrlSendCommand; Retrying in 5 seconds
Attempt 5/5 sending Set charging Amps to 5 to vin:XP7YXXXX0XX000000 command:charging-set-amps 5
tesla-control send command:charging-set-amps 5 to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
Received MQTT message; topic:tesla_ble/XP7YXXXX0XX000000/charging msg:start vin:XP7YXXXX0XX000000 cmd:charging
Attempt 1/5 sending Set charging mode to start to vin:XP7YXXXX0XX000000 command:charging-start
bluetoothctl_read; check presence, launch bluetoothctl power on,devices,scan on
VIN:XP7YXXXX0XX000000
PRESENCE_EXPIRE_TIME:1726498103
listen_to_ble; calling check_presence() BLE_LN:Sa1234567890123456 BLE_MAC:BLE_MAC
vin:XP7YXXXX0XX000000 ble_ln:Sa1234567890123456 match:(Sa1234567890123456|74:B8:DE:AD:BE:EF) presence not detected
vin:XP7YXXXX0XX000000 ble_ln:Sa1234567890123456 presence not expired
listen_to_ble; macAddr:74:B8:DE:AD:BE:EF BLE_MAC:74:B8:DE:AD:BE:EF
listen_to_ble; BLE_MAC_LIST:74:B8:DE:AD:BE:EF
tesla-control send command:charging-start to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
teslaCtrlSendCommand; Retrying in 5 seconds
Attempt 2/5 sending Set charging mode to start to vin:XP7YXXXX0XX000000 command:charging-start
tesla-control send command:charging-start to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
teslaCtrlSendCommand; Retrying in 5 seconds
Attempt 3/5 sending Set charging mode to start to vin:XP7YXXXX0XX000000 command:charging-start
tesla-control send command:charging-start to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
teslaCtrlSendCommand; Retrying in 5 seconds
Attempt 4/5 sending Set charging mode to start to vin:XP7YXXXX0XX000000 command:charging-start
tesla-control send command:charging-start to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
teslaCtrlSendCommand; Retrying in 5 seconds
Attempt 5/5 sending Set charging mode to start to vin:XP7YXXXX0XX000000 command:charging-start
tesla-control send command:charging-start to vin:XP7YXXXX0XX000000 failed exit status 1.
teslaCtrlSendCommand; Error: context deadline exceeded
Received MQTT message; topic:tesla_ble/XP7YXXXX0XX000000/command msg:wake vin:XP7YXXXX0XX000000 cmd:command
Attempt 1/5 sending Wake up vehicule to vin:XP7YXXXX0XX000000 command:-domain vcsec wake
teslaCtrlSendCommand;
Command -domain vcsec wake was successfully delivered to vin:XP7YXXXX0XX000000
Received MQTT message; topic:tesla_ble/XP7YXXXX0XX000000/command msg:wake vin:XP7YXXXX0XX000000 cmd:command
Attempt 1/5 sending Wake up vehicule to vin:XP7YXXXX0XX000000 command:-domain vcsec wake
teslaCtrlSendCommand;
Command -domain vcsec wake was successfully delivered to vin:XP7YXXXX0XX000000
Received MQTT message; topic:tesla_ble/XP7YXXXX0XX000000/charging-set-amps msg:8 vin:XP7YXXXX0XX000000 cmd:charging-set-amps
Attempt 1/5 sending Set charging Amps to 8 to vin:XP7YXXXX0XX000000 command:charging-set-amps 8
teslaCtrlSendCommand;
Command charging-set-amps 8 was successfully delivered to vin:XP7YXXXX0XX000000
Received MQTT message; topic:tesla_ble/XP7YXXXX0XX000000/command msg:wake vin:XP7YXXXX0XX000000 cmd:command
Attempt 1/5 sending Wake up vehicule to vin:XP7YXXXX0XX000000 command:-domain vcsec wake
teslaCtrlSendCommand;
Command -domain vcsec wake was successfully delivered to vin:XP7YXXXX0XX000000
Received MQTT message; topic:tesla_ble/XP7YXXXX0XX000000/charging-set-amps msg:10 vin:XP7YXXXX0XX000000 cmd:charging-set-amps
Attempt 1/5 sending Set charging Amps to 10 to vin:XP7YXXXX0XX000000 command:charging-set-amps 10
teslaCtrlSendCommand;
Command charging-set-amps 10 was successfully delivered to vin:XP7YXXXX0XX000000

[iainbullock]

@dglaude I am not sure you are running v0.2.2. Below is the log I get when I set charging current with the car asleep:

2024-09-17T05:23:00.883629578Z Received MQTT message; topic:tesla_ble/LRW3XXXXXXXX03/charging-set-amps msg:9 vin:LRWXXXXXXXX403 cmd:charging-set-amps
2024-09-17T05:23:00.890239613Z Attempt 1/5 sending Set charging Amps to 9 to vin:LRWXXXXXXXX403 command:charging-set-amps 9
2024-09-17T05:23:02.482565034Z vin:LRW3XXXXXXXX403 ble_ln:SaXXXXXXXX18C match:(SaXXXXXXXXe18C|40:79:12:20:20:F9) presence detected
2024-09-17T05:23:27.172461305Z teslaCtrlSendCommand; Error: context deadline exceeded
2024-09-17T05:23:27.172836874Z Vehicle might be asleep
2024-09-17T05:23:27.172892342Z Trying to wake up car then launch the command again
2024-09-17T05:23:27.250049244Z Attempt 1/5 sending Wake up vehicule to vin:LRWXXXXXXXX403 command:-domain vcsec wake
2024-09-17T05:23:29.732936936Z Command -domain vcsec wake was successfully delivered to vin:LRWXXXXXXXX403
2024-09-17T05:23:31.737357918Z Attempt 2/5 sending Set charging Amps to 9 to vin:LRWXXXXXXXX03 command:charging-set-amps 9
2024-09-17T05:23:35.010168472Z Command charging-set-amps 9 was successfully delivered to vin:LRXXXXXXXX03

You are not getting 'Vehicle might be asleep' and 'Trying to wake up car then launch the command again' in your logs which makes me think you are not using the latest version with the autowake feature

[dglaude]

You are not getting 'Vehicle might be asleep' and 'Trying to wake up car then launch the command again' in your logs which makes me think you are not using the latest version with the autowake feature

Sorry, I don't know what I did to fail upgrading and not noticing. This time I stopped and removed any trace of previous docker image, and I used this docker compose up --force-recreate --build -d to make sure I had the latest.

Now I am getting the expected Vehicle might be asleep in the log:

Received MQTT message; topic:tesla_ble/XP7YXXXX0XX000000/charging-set-amps msg:5 vin:XP7YXXXX0XX000000 cmd:charging-set-amps
teslaCtrlSendCommand; Standard call: in.
Attempt 1/5 sending Set charging Amps to 5 to vin:XP7YXXXX0XX000000 command:charging-set-amps 5
teslaCtrlSendCommand; txt deadline exc. - IN
teslaCtrlSendCommand; Error: context deadline exceeded
Vehicle might be asleep
Trying to wake up car then launch the command again
teslaCtrlSendCommand; Nested call: in. Set callMode and copy internal variables
Attempt 1/5 sending Wake up vehicule to vin:XP7YXXXX0XX000000 command:-domain vcsec wake
bluetoothctl_read; check presence, launch bluetoothctl power on,devices,scan on
teslaCtrlSendCommand;
Command -domain vcsec wake was successfully delivered to vin:XP7YXXXX0XX000000
teslaCtrlSendCommand; Nested call: out. Set callMode back to standard and revert internal variables
teslaCtrlSendCommand; txt deadline exc. - OUT
Attempt 2/5 sending Set charging Amps to 5 to vin:XP7YXXXX0XX000000 command:charging-set-amps 5
teslaCtrlSendCommand;
Command charging-set-amps 5 was successfully delivered to vin:XP7YXXXX0XX000000
teslaCtrlSendCommand; Standard call: out.

I checked that the car was asleep, then I switched evcc from solar to min+sol and the charge started (the log above is the begining of the sequence where evcc set it to min = 5 Amps.

I'll keep watching today, but I think version 0.2.2 nailed it and is solving my problem.

Thank you very much.

[iainbullock]

Good to hear. I'll keep this thread open for a while longer so you can report back

[dglaude]

@iainbullock This is fully functional for me.

The car charge fine without human intervention, we can just forget about it and let the system operate.

From my point of view, you can safely close this issue.

[iainbullock]

Excellent glad it's now working for you