Handle sleep behavior of MCU2 upgraded cars #3262
Conversation
…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 stream reports power=nil in subsystem online and reports a power as a number when it is a real online. Stay in state :start when online is detected on non-vehicle_data stream receives data and new variable fake_online is set dependent on power is nil or a number There are still some TODO's around the code. Also handle stream getting vehicle offline and change to state offline in vehicle
…te is offline or asleep. Before it caused a vehicle_data request in suspended even though not intended (since it actually went to state start where vehicle_data is allowed when false_online=false, which it is in online and suspended) Added a clause in suspended if power > 0 to go back to online (e.g. if climate is turned on remotely with app. That works, not sure if opening door without climate on is enough to trigger this (power seems to be integers, but hopefuly rounded up)
This will lay of vehicle_data and use non-vehicle_data instead and hopefully not keep the car awake when errors suddenly stop again Changed some comment and logger texts
… in online when getting an error.
Could otherwise give a irrelevant warning from try_to_suspend function. (E.g. User present)
JakobLichterfeld
added
area:tesla api
|
This is Beautiful - I've been wondering about this for a couple of years now but never thought to dig more into why the MCU2 upgraded car behaved differently to the other MCU2 car in the account |
|
Would it make sense to make different PR's to the things that are not directly related to the MCU2 issue?
Just to make it easier to review this, but also for me to actually get CI tests working for both this MCU2 issue and the other things |
|
Is this PR still active? |
Yes, it just fails some of the workflow tests, so I think I need to figure that out. Besides that I once in a while merge teslamate:master in to keep the PR up-to-date |
|
Currently installing 2023.38.9. Will report back Works fine with 2023.38.9 |
|
I can’t see any runs on this PR - @JakobLichterfeld do we have any elixir gurus who could take a look at this one? |
Run needs manual approval. I didn't push the button till now since this branch seems outdated in regards to workflow files |
|
I just synced the fork, but I know from last run that there are a lot of test failures. Previously I used WSL on windows for test, but it seems to fail even on master. |
✅ Deploy Preview for teslamate ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Can we get this merged into the master? |
Once our 321 test cases run successfully and we are sure that we are not breaking anything with non-MCU2 upgraded cars, the answer will be yes. |
JakobLichterfeld
added
the
note:needs investigation
…ly vehicles in products api endpoint
…e state :start. Added fallback if no data is comming from stream and allow vehicle_data fetch When in online dont detect as charging when power < 0 and preconditioning or dog mode Don't allow suspend when power > 0 More aggresive suspend timer, only wait 1 minute after last use to suspend, stream should detect anything relevant
|
I deployed: Getting errors like this: Also trying to load the web interface responds with 500 |
|
@czras are you using docker-compose.yml with something like this: I'm not using docker at the moment but a more manual install. But there is at least one that has pulled the latest from docker with no issues. I can't really figure out what is going on based on the log output :( Does it happen as soon as you start up or is it triggered by the GET ? That you try to access the web. Can you post some more of the log? From startup maybe. |
I am using the image with the SHA
As far as I can judge it is happening right after start. Without accessing the web UI, the same error continues to pop up.
Certainly. Hopefully I can retest it this evening to gather all the logs. |
…rev, commit date) and build date and print it at startup. Hopefully gives some good info on PR image builds
|
My suspicion is that the build information commit may not work correctly when doing the Docker build. As in does the build have access to the git information? If it does work, then disregard :-) |
|
I'm also anxious to see if it works :) The Build GHCR images do alot of git commands, but that might be in a different scope somehow. |
…in/erlexec: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found (required by /opt/app/erts-14.2.2/bin/erlexec)
|
I guess it didn't #3084 (comment) |
Sorry, got the flu which knocked me out for a bit of time. I deployed now from a local docker build and this works fine. Altough I had to switch from netcat-traditional to netcat-openbsd for IPv6 support but that is a different story. |
There is a lot more info in this issue: #3084
The short story is:
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 stream reports power=nil in subsystem online and reports power as a number when it is a real online.
Fix implemented by staying in state :start when online is detected on non-vehicle_data.
Stream receives data and new variable fake_online is set dependent on power is nil or a number.
The variable fake_online is used to decide whether to get only non-vehicle_data or the full blown wakeup vehicle_data
In suspended only non-vehicle_data is allowed to be better at going to sleep. Usage is detected if power>0 to go back to online state.
Other things:
This will lay of vehicle_data and use non-vehicle_data instead and
hopefully not keep the car awake when errors suddenly stop again