feat: handle sleep behavior of MCU2 upgraded cars

[JakobLichterfeld]

changes from @micves from #3262, fixes #3084

to use this just follow https://docs.teslamate.org/docs/development#testing-with-our-ci-which-builds-the-docker-images-automatically-per-pr with pr-4453

[netlify]

✅ Deploy Preview for teslamate ready!

Name	Link
🔨 Latest commit	1bfb9c7
🔍 Latest deploy log	https://app.netlify.com/projects/teslamate/deploys/690c57577456ba000865868e
😎 Deploy Preview	https://deploy-preview-4453--teslamate.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[brianmay]

I am having trouble making sense of this PR.

It started off simple (with the original first two commits from the first PR) and has become rather complicated, and IMHO hard to understand. And I am wondering if this complexity is really required.

Then there are some changes when in this PR that don't belong here; for example the changes to delete the "models2" entries. I think this might have been included in error.

There are some changes though that would be easy to apply separately, for example improvements to the log messages.

[JakobLichterfeld]

Agree, I do have trouble reviewing. The comments helped a bit.
As so much test cases fail I would love to see a split up by @micves on this branch.

[micves]

Not sure where the model2 changes are coming from. They are not in the original https://github.com/teslamate-org/teslamate/pull/3262/files Maybe it wasn't synced when this PR was made?

The commit history of the old #3262 is long and a bit messed up. Might be easier to only look at the end result. Which again as you mention is a bit complex :(
The issue is also complex as the length of #3084 also indicates.

The shortest way to sum it up, might actually just be the description I made on fake_online_state variable:

fake_online_state is introduced because older cars upgraded to MCU2 have a little wakeup every hour to check subsystems.
They report online but if vehicle_data is requested they wake up completely (cars clicks) and is awake for
15 minutes instead of a 2-3 minutes. The only difference (known at this moment) is that stream reports power=nil
in subsystem online and reports power as a number when it is a real online.

The complexity comes in because online all of a sudden might not be online.
It's Schrödinger's online until data from Stream is received :)

This means that the entire online state handling and stream is re-done, and the tests (or as I see it, the API mock used for tests) does not support the fact that a Stream is required.

The ultimate solution would be that the car or Tesla servers would hide the fake online.
I haven't checked in a while, but my guess is that nothing has changed there.

[brianmay]

I guess next step is to double check this is still required. Which might be the case, but I think we do need to check to be sure.

[micves]

I just checked my logs and it seems to still be an issue:

2025-01-02 17:31:57.037 car_id=1 [info] Vehicle online, connect stream to check for real online
2025-01-02 17:31:57.037 car_id=1 [info] Stream connecting ...
2025-01-02 17:31:58.356 car_id=1 [info] Fake online: power is nil
2025-01-02 17:34:30.612 car_id=1 [info] Stream :inactive in state :offline, seems to have been a fake online
2025-01-02 17:34:30.907 [info] Streaming API: Vehicle offline
2025-01-02 17:34:30.907 car_id=1 [warning] Stream reports vehicle as offline, fetching vehicle state ...
2025-01-02 17:34:30.977 car_id=1 [info] Stream disconnecting ...
2025-01-02 18:33:31.219 car_id=1 [info] Vehicle online, connect stream to check for real online
2025-01-02 18:33:31.219 car_id=1 [info] Stream connecting ...
2025-01-02 18:33:32.431 car_id=1 [info] Fake online: power is nil
2025-01-02 18:35:35.748 car_id=1 [info] Stream :inactive in state :offline, seems to have been a fake online
2025-01-02 18:36:01.681 car_id=1 [info] Stream disconnecting ...
2025-01-02 19:24:10.953 [info] Refreshing access token ...
2025-01-02 19:24:11.301 [info] POST https://auth.tesla.com/oauth2/v3/token -> 200 (347.532 ms)
2025-01-02 19:24:11.343 [info] Scheduling token refresh in 6h
2025-01-02 19:34:43.498 car_id=1 [info] Vehicle online, connect stream to check for real online
2025-01-02 19:34:43.498 car_id=1 [info] Stream connecting ...
2025-01-02 19:34:44.882 car_id=1 [info] Fake online: power is nil
2025-01-02 19:37:00.137 car_id=1 [info] Stream :inactive in state :offline, seems to have been a fake online
2025-01-02 19:37:30.696 [info] Streaming API: Vehicle offline
2025-01-02 19:37:30.696 car_id=1 [warning] Stream reports vehicle as offline, fetching vehicle state ...
2025-01-02 19:37:30.760 car_id=1 [info] Stream disconnecting ...
2025-01-02 20:35:58.701 car_id=1 [info] Vehicle online, connect stream to check for real online
2025-01-02 20:35:58.701 car_id=1 [info] Stream connecting ...
2025-01-02 20:35:59.867 car_id=1 [info] Fake online: power is nil
2025-01-02 20:38:27.131 car_id=1 [info] Stream :inactive in state :offline, seems to have been a fake online
2025-01-02 20:38:57.674 [info] Streaming API: Vehicle offline
2025-01-02 20:38:57.674 car_id=1 [warning] Stream reports vehicle as offline, fetching vehicle state ...
2025-01-02 20:38:57.737 car_id=1 [info] Stream disconnecting ...
2025-01-02 21:37:43.140 car_id=1 [info] Vehicle online, connect stream to check for real online
2025-01-02 21:37:43.140 car_id=1 [info] Stream connecting ...
2025-01-02 21:37:44.633 car_id=1 [info] Fake online: power is nil
2025-01-02 21:39:53.967 car_id=1 [info] Stream :inactive in state :offline, seems to have been a fake online
2025-01-02 21:40:13.489 car_id=1 [info] Stream disconnecting ...

It has the hourly sequence with 'Fake online: power is nil' lasting 2-3 minutes
The car is on 2024.45.32

@brianmay, I think I read somewhere that you also have an MCU2 upgraded car?
If you are on a difference PR or release, my guess is that you also have these hourly wakeups, but yours will last longer because it wakes up for real because vehicle_data is polled. If you are near the car it will also click on the high voltage relay.

[Dhtjf]

Sample of my logs of 2017 MCU2 upgraded Model S. On 2024.26.7 and TeslaMate on 1.31.2-dev from pr-3262. 200s are from uptime Kuma, so unrelated.

2025-01-03` 22:49:19.230 [info] GET /
2025-01-03 22:49:19.231 [info] Sent 200 in 1ms
2025-01-03 22:50:46.620 car_id=1 [info] Vehicle online, connect stream to check for real online
2025-01-03 22:50:46.620 car_id=1 [info] Stream connecting ...
2025-01-03 22:50:48.561 car_id=1 [info] Fake online: power is nil
2025-01-03 22:51:19.235 [info] GET /
2025-01-03 22:51:19.237 [info] Sent 200 in 1ms
2025-01-03 22:51:46.950 car_id=1 [info] Stream disconnecting ...
2025-01-03 22:53:19.241 [info] GET /
2025-01-03 22:53:19.243 [info] Sent 200 in 1ms

[brianmay]

I can confirm that I have MCU2 upgraded car, am using this branch, and am seeing similar log messages. So yes, does seem like this PR is still required.

[brianmay]

Looking at the simplest piece of the PR here:

diff --git a/lib/teslamate/vehicles/vehicle.ex b/lib/teslamate/vehicles/vehicle.ex
index d32098b9a8..e30020392b 100644
--- a/lib/teslamate/vehicles/vehicle.ex
+++ b/lib/teslamate/vehicles/vehicle.ex
@@ -1433,6 +1645,12 @@
         {:keep_state, %Data{data | last_used: DateTime.utc_now()},
          [broadcast_summary(), schedule_fetch(default_interval() * i, data)]}

+      {:error, :power_usage} ->
+        if suspend?, do: Logger.warning("Power usage ...", car_id: car.id)
+
+        {:keep_state, %Data{data | last_used: DateTime.utc_now()},
+         [broadcast_summary(), schedule_fetch(default_interval() * i, data)]}
+
       {:error, :unlocked} ->
         if suspend?, do: Logger.warning("Unlocked ...", car_id: car.id)

@@ -1501,6 +1719,10 @@
        %CarSettings{req_not_unlocked: true}} ->
         {:error, :unlocked}

+      {%Vehicle{drive_state: %Drive{power: power}}, _}
+      when is_number(power) and power > 0 ->
+        {:error, :power_usage}
+
       {%Vehicle{}, %CarSettings{}} ->
         :ok
     end

I believe this means Teslamate will never enter "trying to sleep" if power > 0. What is the rationale here?

Does power > 0 suggest that the tesla itself is not trying to sleep, and as a result there is no point entering "trying to sleep" ourselves?

Would it make sense to split this patch out and apply it first?

[brianmay]

There appear to be 4 different values for fake_online_state: 0, 1, 2, and 3. What do these different values mean?

[brianmay]

The model2 changes don't appear in the original PR:

[brianmay]

The model2 changes are not in the original PR; am going to delete them.

diff --git a/lib/teslamate/vehicles/vehicle.ex b/lib/teslamate/vehicles/vehicle.ex
index d32098b9a8..e30020392b 100644
--- a/lib/teslamate/vehicles/vehicle.ex
+++ b/lib/teslamate/vehicles/vehicle.ex
@@ -65,7 +70,6 @@
           with str when is_binary(str) <- type do
             case String.downcase(str) do
               "models" <> _ -> "S"
-              "models2" <> _ -> "S"
               "model3" <> _ -> "3"
               "modelx" <> _ -> "X"
               "modely" <> _ -> "Y"
@@ -79,7 +83,6 @@
           case {model, trim_badging, type} do
             {"S", "100D", "lychee"} -> "LR"
             {"S", "P100D", "lychee"} -> "Plaid"
-            {"S", "100D", "models2"} -> "LR+"
             {"3", "P74D", _} -> "LR AWD Performance"
             {"3", "74D", _} -> "LR AWD"
             {"3", "74", _} -> "LR"

[brianmay]

Testing my understanding of the code here. Please correct any errors!

:get_vehicle -> TeslaApi.Vehicle.get: will return information Tesla has on the car but will not try to talk to the car, as such it will not keep the car awake and will succeed even if car is asleep. As such this will be limited in scope.

:get_vehicle_with_state -> TeslaApi.Vehicle.get_with_state will try to talk to the car and get all available information, but this will mean keeping the car awake if it is awake or out right failing if the car is asleep.

[brianmay]

Am wondering about the changes to the fetch function. What we have is:

  defp fetch(%Data{car: car, deps: deps}, expected_state: expected_state) do
    reachable? =
      case expected_state do
        :online -> true
        {:driving, _, _} -> true
        {:updating, _} -> true
        {:charging, _} -> true
        :start -> false
        {:offline, _} -> false
        {:asleep, _} -> false
        {:suspended, _} -> false
      end

    if reachable? do
      fetch_with_reachable_assumption(car.eid, deps)
    else
      fetch_with_unreachable_assumption(car.eid, deps)
    end
  end

  defp fetch_with_reachable_assumption(id, deps) do
    with {:error, :vehicle_unavailable} <- call(deps.api, :get_vehicle_with_state, [id]) do
      call(deps.api, :get_vehicle, [id])
    end
  end

  defp fetch_with_unreachable_assumption(id, deps) do
    with {:ok, %Vehicle{state: "online"}} <- call(deps.api, :get_vehicle, [id]) do
      call(deps.api, :get_vehicle_with_state, [id])
    end
  end

i.e. we try to guess if car is reachable or not, then we check if this assumption is correct or not, and then we try to get the data.

But after this PR we do things differently but only if the streaming api is enabled in the config.

        allow_vehicle_data? =
          case expected_state do
            # will not go to real state :online unless a stream is received
            # with power not nil in state :offline/:asleep or if use_streaming api is turned off
            :online ->
              true

            {:driving, _, _} ->
              true

            {:updating, _} ->
              true

            {:charging, _} ->
              true

            :start ->
              false

            {state, _} when state in [:asleep, :offline] ->
              case data do
                %Data{fake_online_state: 3} -> true
                %Data{} -> false
              end

            {:suspended, _} ->
              false
          end

        if allow_vehicle_data? do
          call(deps.api, :get_vehicle_with_state, [car.eid])
        else
          call(deps.api, :get_vehicle, [car.eid])
        end

So now if fake_online_state is 3 we consider the car to be awake, where as before we considered it to be asleep. That probably makes sense.

But now instead of carefully making calls to fetch_with_unreachable_assumption and fetch_with_reachable_assumption to check our assumptions are correct, we make the calls directly. What is the rationale here?

[brianmay]

To half answer my own question, we can't trust this logic anymore:

defp fetch_with_unreachable_assumption(id, deps) do
    with {:ok, %Vehicle{state: "online"}} <- call(deps.api, :get_vehicle, [id]) do
      call(deps.api, :get_vehicle_with_state, [id])
    end
  end

This would result in calling get_vehicle_with_state when the car is "fake awake", which will result in the car being woken up properly.

And the logic to upgrade a car that is asleep to awake does seem to be dependent on creating streaming. Hence we have to fall back to fetch_with_unreachable_assumption if streaming is disabled.

But I still do wonder why we can't use fetch_with_unreachable_assumption?

And contrary to the comment at the top, the logic seems to be more along the lines of "Is car awake? Can we receive streaming data?" as opposed to looking a the power level (except for the logic that inhibits sleeping when the power level is non-zero).

[brianmay]

Taking a different approach.

Take a random failing test, for example:

mix test test/teslamate/vehicles/vehicle/suspend_logging_test.exs:238

It looks like there is confusion in the date/time happening. As in the test wants to use 1970-01-01 but we are getting present day date and times.

This in turn means any incoming data is discarded because it is 2025-1970 = 55 years too late:

16:09:40.759 car_id=15611 [warning] Discarded stale fetch result: [
  now: %TeslaApi.Vehicle.State.Drive{
    active_route_destination: nil,
    active_route_energy_at_arrival: nil,
    active_route_latitude: nil,
    active_route_longitude: nil,
    active_route_miles_to_arrival: nil,
    active_route_minutes_to_arrival: nil,
    active_route_traffic_minutes_delay: nil,
    gps_as_of: nil,
    heading: nil,
    latitude: 0.0,
    longitude: 0.0,
    native_latitude: nil,
    native_location_supported: nil,
    native_longitude: nil,
    native_type: nil,
    power: nil,
    shift_state: "N",
    speed: nil,
    timestamp: 0
  },
  last: %TeslaApi.Vehicle.State.Drive{
    active_route_destination: nil,
    active_route_energy_at_arrival: nil,
    active_route_latitude: nil,
    active_route_longitude: nil,
    active_route_miles_to_arrival: nil,
    active_route_minutes_to_arrival: nil,
    active_route_traffic_minutes_delay: nil,
    gps_as_of: nil,
    heading: nil,
    latitude: 0.0,
    longitude: 0.0,
    native_latitude: nil,
    native_location_supported: nil,
    native_longitude: nil,
    native_type: nil,
    power: nil,
    shift_state: nil,
    speed: nil,
    timestamp: 1735967380670
  }
]

Note the timestamp of the incoming data is 0, the other timestamp is 1735967380670 which I assume was the current date time when I ran the test.

Similarly the test is expecting 1970-01-01 to be in the data, but it gets 2025-01-04 instead:

  1) test cannot be suspended if shift_state is N (TeslaMate.Vehicles.Vehicle.SuspendLoggingTest)
     test/teslamate/vehicles/vehicle/suspend_logging_test.exs:227
     Assertion failed, no matching message after 300ms
     The following variables were pinned:
       date = ~U[1970-01-01 00:00:00.000Z]
     Showing 4 of 4 messages in the mailbox
     code: assert_receive {:start_state, _, :online, date: ^date}
     mailbox:
       pattern: {:start_state, _, :online, [date: ^date]}
       value:   {
                  :start_state,
                  %TeslaMate.Log.Car{__meta__: #Ecto.Schema.Metadata<:built, "cars">, id: 15611, name: nil, efficiency: nil, model: "3", trim_badging: nil, marketing_name: nil, exterior_color: nil, wheel_type: nil, spoiler_type: nil, eid: 0, vid: 1000, vin: "1000", settings_id: nil, settings: %TeslaMate.Settings.CarSettings{__meta__: #Ecto.Schema.Metadata<:built, "car_settings">, id: nil, suspend_min: 21, suspend_after_idle_min: 15, req_not_unlocked: true, free_supercharging: false, use_streaming_api: true, enabled: true, lfp_battery: false, car: #Ecto.Association.NotLoaded<association :car is not loaded>}, charging_processes: #Ecto.Association.NotLoaded<association :charging_processes is not loaded>, positions: #Ecto.Association.NotLoaded<association :positions is not loaded>, drives: #Ecto.Association.NotLoaded<association :drives is not loaded>, inserted_at: nil, updated_at: nil},
                  :online,
                  [date: ~U[2025-01-04 05:09:40.670Z]]
                }

       pattern: {:start_state, _, :online, [date: ^date]}
       value:   {
                  :insert_position,
                  %TeslaMate.Log.Car{__meta__: #Ecto.Schema.Metadata<:built, "cars">, id: 15611, name: nil, efficiency: nil, model: "3", trim_badging: nil, marketing_name: nil, exterior_color: nil, wheel_type: nil, spoiler_type: nil, eid: 0, vid: 1000, vin: "1000", settings_id: nil, settings: %TeslaMate.Settings.CarSettings{__meta__: #Ecto.Schema.Metadata<:built, "car_settings">, id: nil, suspend_min: 21, suspend_after_idle_min: 15, req_not_unlocked: true, free_supercharging: false, use_streaming_api: true, enabled: true, lfp_battery: false, car: #Ecto.Association.NotLoaded<association :car is not loaded>}, charging_processes: #Ecto.Association.NotLoaded<association :charging_processes is not loaded>, positions: #Ecto.Association.NotLoaded<association :positions is not loaded>, drives: #Ecto.Association.NotLoaded<association :drives is not loaded>, inserted_at: nil, updated_at: nil},
                  %{date: ~U[2025-01-04 05:09:40.670Z], speed: nil, latitude: 0.0, longitude: 0.0, elevation: nil, power: nil, battery_level: nil, ideal_battery_range_km: nil, est_battery_range_km: nil, rated_battery_range_km: nil, usable_battery_level: nil, outside_temp: nil, inside_temp: nil, odometer: nil, fan_status: nil, is_climate_on: nil, driver_temp_setting: nil, passenger_temp_setting: nil, is_rear_defroster_on: nil, is_front_defroster_on: nil, battery_heater_on: nil, battery_heater: nil, battery_heater_no_power: nil, tpms_pressure_fl: nil, tpms_pressure_fr: nil, tpms_pressure_rl: nil, tpms_pressure_rr: nil}
                }

       pattern: {:start_state, _, :online, [date: ^date]}
       value:   {ApiMock, {:stream, 1000, #Function<0.51361193/1 in TeslaMate.Vehicles.Vehicle.connect_stream/1>}}

       pattern: {:start_state, _, :online, [date: ^date]}
       value:   {
                  :pubsub,
                  {:broadcast, TeslaMate.PubSub, "Elixir.TeslaMate.Vehicles.Vehicle/summary/15611", %TeslaMate.Vehicles.Vehicle.Summary{car: %TeslaMate.Log.Car{__meta__: #Ecto.Schema.Metadata<:built, "cars">, id: 15611, name: nil, efficiency: nil, model: "3", trim_badging: nil, marketing_name: nil, exterior_color: nil, wheel_type: nil, spoiler_type: nil, eid: 0, vid: 1000, vin: "1000", settings_id: nil, settings: %TeslaMate.Settings.CarSettings{__meta__: #Ecto.Schema.Metadata<:built, "car_settings">, id: nil, suspend_min: 21, suspend_after_idle_min: 15, req_not_unlocked: true, free_supercharging: false, use_streaming_api: true, enabled: true, lfp_battery: false, car: #Ecto.Association.NotLoaded<association :car is not loaded>}, charging_processes: #Ecto.Association.NotLoaded<association :charging_processes is not loaded>, positions: #Ecto.Association.NotLoaded<association :positions is not loaded>, drives: #Ecto.Association.NotLoaded<association :drives is not loaded>, inserted_at: nil, updated_at: nil}, display_name: nil, state: :online, since: ~U[2025-01-04 05:09:40.682977Z], healthy: true, latitude: 0.0, longitude: 0.0, heading: nil, battery_level: nil, charging_state: nil, usable_battery_level: nil, ideal_battery_range_km: nil, est_battery_range_km: nil, rated_battery_range_km: nil, charge_energy_added: nil, speed: nil, outside_temp: nil, inside_temp: nil, is_climate_on: nil, is_preconditioning: nil, locked: nil, sentry_mode: nil, plugged_in: true, scheduled_charging_start_time: nil, charge_limit_soc: nil, charger_power: nil, windows_open: nil, doors_open: nil, driver_front_door_open: nil, driver_rear_door_open: nil, passenger_front_door_open: nil, passenger_rear_door_open: nil, odometer: nil, shift_state: nil, charge_port_door_open: nil, time_to_full_charge: nil, charger_phases: nil, charger_actual_current: nil, charger_voltage: nil, version: "", update_available: nil, update_version: nil, is_user_present: nil, geofence: nil, model: "3", trim_badging: nil, ...}}
                }
     stacktrace:
       test/teslamate/vehicles/vehicle/suspend_logging_test.exs:238: (test)

But oddly enough I don't think anything in this PR deals with date/time?

[zexpe]

Last 24. hours here, mostly curious why there are these 13m online wake ups pretty consistently(the thin blue lines repeated) :

Those regular hourly wake-ups are exactly what this branch should fix (it does for me), by detecting that the car isn't really awake and then not polling for data that will properly wake up the car. Whenever the car wakes up, e.g. you check on it in the app (not just opening the app these days, but actually going to the location map, or checking climate for example) or you physically access the car (e.g. open the trunk / door and then close it again), then it always takes 13 minutes to fall back to sleep - that's normal, but TeslaMate here is causing these extra wake-ups unnecessarily by data polling during a "fake wake". Those longer online periods of two hours might be something else - if it's in your garage and plugged in then it might be some charge scheduling thing?

[jeremyjpj0916]

Those regular hourly wake-ups are exactly what this branch should fix (it does for me)

Gotcha, so this fix or a varient of it is not out in their flagship release yet(the 2.0.0 I am on rn). Hope it gets out there. I can test this branch myself too to see if it changes the pattern then.

[zexpe]

Actually, those 2 hours wakes seem to happen at regular 8 hour intervals. Curious.

[zexpe]

Those regular hourly wake-ups are exactly what this branch should fix (it does for me)

Gotcha, so this fix is not out in their flagship release yet(the 2.0.0 I am on rn). Hope it gets out there. I can test this branch myself too to see if it changes the pattern then.

No, they've chosen to keep it as a separate branch - as per discussion above.

[jeremyjpj0916]

Those regular hourly wake-ups are exactly what this branch should fix (it does for me)

Gotcha, so this fix is not out in their flagship release yet(the 2.0.0 I am on rn). Hope it gets out there. I can test this branch myself too to see if it changes the pattern then.

No, they've chosen to keep it as a separate branch - as per discussion above.

Sucks when things get so complicated we end up with all kinda one off builds to support things in a tool hah, I do see the workaround is basically:

services:
  teslamate:
    image: ghcr.io/teslamate-org/teslamate:pr-4453

In a docker compose to grab the github CI build image they pump out. Testing it out now.

[JakobLichterfeld]

Am I on the wrong version?

the 2.0.0 I am on rn

Obviously yes, not sure what the benefit of posting in a PR is, when not using the dedicated pr version.

If you have issues, please use issues. If you have additions to a PR use PR comments. If you are happy, as TeslaMate supports MCU2 upgraded cars, great, please share. And yes, we are confident this PR solves issues only MCU2 upgraded cars have, much of confirmation in the issue, the previous PR and this PR.

[zexpe]

Actually, those 2 hours wakes seem to happen at regular 8 hour intervals. Curious.

Probably not related to TeslaMate, but on the subject of sleep behaviour, I've since noticed that whenever my car is sleeping whilst connected to wifi it also wakes up on exactly 8 hour intervals, though in my case it falls asleep again in the usual 13 minutes rather than 2 hours (you can actually see that in my data above, but I've since found many more examples). If the car is sleeping without a wifi connection it can sleep for much longer than 8 hours without waking. Random wakes still occur occasionally. I would love to know why exactly.

[MadManDK]

I changed to this PR and did not see a big change, so I tested the 12v battery and it was no god, so I replaced it. However I been running for a while and even changed back and forth ( version 2.0.0 and this PR version 2.0.1-dev) and get exactly the same state pattern (about 1h asleep and about 15m online):

I know this is not how it should be, so what am I doing wrong?

Other info:

• Tesla Model S 85D from dec. 2015 with MCU upgrade
• Normal tesla app in use, as well as HA tesla integration - not other apps in use
• It is on Wifi, but a very solid connection as the AP is outside, 1-2 meters from the car
• Red bar is an update that completed

Appreciate any hints I can get.

[USAFPride]

@MadManDK

• Tesla Model S 85D from dec. 2015 with MCU upgrade
• Normal tesla app in use, as well as HA tesla integration - not other apps in use
• It is on Wifi, but a very solid connection as the AP is outside, 1-2 meters from the car
• Red bar is an update that completed

Appreciate any hints I can get.

Turn off the polling in the HA App (or set the time to more than 60 minutes aka 3600 seconds). Note Polling will turn back on whenever HA restarts

[MadManDK]

Turn off the polling in the HA App (or set the time to more than 60 minutes aka 3600 seconds). Note Polling will turn back on whenever HA restarts

Thanks, looks different now, longer sleeps, but also longer awake.

[USAFPride]

Thanks, looks different now, longer sleeps, but also longer awake.

@MadManDK, That looks normal

[JakobLichterfeld]

This branch will get v2.1.0 changes later today or tomorrow

[JakobLichterfeld]

This branch will get v2.1.0 changes later today or tomorrow

Done, this is latest 2.1.0 for MCU2 upgraded cars

[JakobLichterfeld]

Updated to v2.1.1, this is latest v2.1.1 for MCU2 upgraded cars

[glynhudson]

Nice work guys, it's great to get this long-standing MCU2 upgrade sleep issue fixed. Is there any prospect that this will be merged? Or should I switch to this PR fork for good?

[brianmay]

This code is "proof of concept" only. It is somewhat ugly. Problem is that the Vehicle state machine (GenServer) is already overly complicated and unmaintainable (IMHO), and this just makes it so much worse.

Ideally the code needs a refactor to implement this properly. I have some vague ideas on how to do this.

Problem is though with Tesla threatening to shut off the unofficial API, nobody wants to dedicate their time on a refactor that may eventually become useless.

[glynhudson]

Fair enough, I've just switched to this PR and my Model S has finally slept for more than 50 min since getting the MCU2 upgrade a year ago! Nice work

It wasn't too difficult to switch to this PR, upgrading to V2 was more involved!

[MadManDK]

Been running this version on my 2015 Models S MCU2 and sleep pattern is good, however I have now twice seen that I "loose data". I just did a round trip of about 30 min each way with a approximately 10 min stop and I am still at the midpoint. It has not realized that I drove home (no data from the return trip and the car is still away from home) and is now sleeping.

Am I missing a setting somwhere?

[brianmay]

I think this is somewhat typical. The legacy API is somewhat terrible, and sometimes we might miss events.

In theory we should be able to detect the car is waking up, IIRC through streaming and polling the tesla endpoint (as in the endpoint that doesn't wake the car). In practice, I have occasionally seen times it misses trips also.

This PR is somewhat complicated, it is possible there is some edge cases we don't deal with correctly. Alternatively it is possible we are getting bad/cached data from Tesla API. Need to investigate. But can't investigate without a reproducible test case.

[JakobLichterfeld]

Am I missing a setting somwhere?

I think this is somewhat typical. The legacy API is somewhat terrible, and sometimes we might miss events.

For more details see: https://docs.teslamate.org/docs/faq#why-am-i-missing-data-when-not-using-the-streaming-api

I personally make sure, TeslaMate is not in falling asleep state before every start (using secure connection to my instance and, open webpage and if in trying to fall asleep I hit the button. This way I never lost a single meter).

[MadManDK]

For more details see: https://docs.teslamate.org/docs/faq#why-am-i-missing-data-when-not-using-the-streaming-api

I recall reading that some time ago, I'm just surprised it never picked up on my 30 min drive home, like after 8 min. (10 min stop and 8 min of the drive would cover the the 3 + 15 min "timeout").

I personally make sure, TeslaMate is not in falling asleep state before every start (using secure connection to my instance and, open webpage and if in trying to fall asleep I hit the button. This way I never lost a single meter).

Thanks, I'll look at setting something like this up - probably via home assistant.

[JakobLichterfeld]

Thanks, I'll look at setting something like this up - probably via home assistant.

There is an put api endpoint for this as well (not really documented: #91). As I do not want to miss anything, I do not trust the automation like mobile has Bluetooth connection to car -> call wake-up), as sometime Bluetooth in Tesla hangs.

[JakobLichterfeld]

Updated to v2.2.0, this is latest v2.2.0 for MCU2 upgraded cars