-
Notifications
You must be signed in to change notification settings - Fork 59
Vehicle Module Priority - Preference local BLE over API #598
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
… over API transparently
… over API transparently
|
Not necessarily in this PR, but I created something that might be helpful in installing the BLE binaries. Since Tesla doesn't publish the armv6 binaries that would be needed on a Pi 0W and building from code is a pain, I put together https://github.com/MikeBishop/tesla-vehicle-command-arm-binaries/ which does a daily check to see whether Tesla has released a new version and if so, builds and posts ARM binaries for it. The latest can always be fetched from https://github.com/MikeBishop/tesla-vehicle-command-arm-binaries/releases/latest/download/vehicle-command-binaries-linux-armv6.tar.gz. |
The idea of this branch is to introduce module priorities, which would allow us to overlap the TeslaBLE module over the top of the TeslaAPI module, so that commands like start/stop charging, wake, set charge limit etc would first be sent out via BT, and we'd look for indications in the response that confirm that the command was sent.
If this fails, it would fall back to the next priority module, the API. It's possible we could slot another module in-between these for the Tesla Fleet API - eventually the owner-api will go away and it will just be a no-op, this is my view of how we can untangle / stack technologies as Tesla deprecates the API we've depended on for a while now.
Regressions:
Tests: