Skip to content
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

Allow "MaxCurrent" to return "errAsleep", or add status "asleep" to vehicles #14431

Closed
Maddimax opened this issue Jun 17, 2024 · 13 comments · Fixed by #14451
Closed

Allow "MaxCurrent" to return "errAsleep", or add status "asleep" to vehicles #14431

Maddimax opened this issue Jun 17, 2024 · 13 comments · Fixed by #14451
Labels
enhancement New feature or request

Comments

@Maddimax
Copy link

Is your feature request related to a problem? Please describe.
I have configured my tesla vehicle with part teslalogger (all "read" values via mqtt) and part custom BLE control (via. Http).
When the tesla is asleep, evcc fails to wake it up, as there is no way to tell evcc that the vehicle is asleep (that I could find)

Describe the solution you'd like
Either: A way to specify an "asleep" state or a way to create a "failed because asleep" http response.

Describe alternatives you've considered
I could always call wakeup in my BLE proxy for any request from evcc, but that seems a bit inefficient.

@andig
Copy link
Member

andig commented Jun 18, 2024

Question is: how? I don‘t see a good option to add a side channel for errrors? We could support them via text. Receiving one of the supported values would convert them to errors: ErrAsleep, ErrMustRetry and ErrNotAvailable.

@andig andig added the enhancement New feature or request label Jun 18, 2024
@Maddimax
Copy link
Author

Maybe (pseudocode):

if (http.status == 500) {
   if (body == "ErrAsleep") return ErrAsleep;
  ....
}

@andig
Copy link
Member

andig commented Jun 18, 2024

Genau, ich würde es aber nicht an einen Status binden. Oder hilft das? Und es muss natürlich über Websockets und Mqtt identisch laufen.

Nvm. Für HTTP eine gute Idee, dann aber != 200.

@andig
Copy link
Member

andig commented Jun 18, 2024

Bitte mal ausprobieren. Für HTTP ist Status != 200 Voraussetzung dass die Fehler abgefragt würden.

@Maddimax
Copy link
Author

Maddimax commented Jun 18, 2024

Websockets würde wahrscheinlich gehen, Mqtt hat halt keine response zu nem publish, von daher ginge da wohl nur ein state, ala:

vehicle:
  asleep:
    source: mqtt
    topic: ....

Und dann ist die frage ob man nicht das gleiche auch für andere benutzen sollte anstatt da zu versuchen error handling zu betreiben.

@andig
Copy link
Member

andig commented Jun 19, 2024

Einfach mal ausprobieren. 3 Fehler x mind. 20 Apis x 4 Geräteklasse auszumultiplizieren wie du das vorschlägst ist keine Option.
Websockets und mqtt sind async, da muss die Abfrage also vorher passiert sein. Und auch die kann natürlich einen Fehler wie ErrAsleep liefern.

@andig
Copy link
Member

andig commented Jun 20, 2024

@Maddimax magst Du den PR mal ausprobieren?

@andig
Copy link
Member

andig commented Jun 22, 2024

ping @Maddimax wenns den Bedarf sonst nicht mehr gibt würde ich hier zu machen.

@Maddimax
Copy link
Author

Sry, bin unterwegs. Ich Probier es nexte Woche.

@Maddimax
Copy link
Author

Die fehlerbehandlung funktioniert super 👍

FYI: Mein kleiner tesla-ble-proxy: https://github.com/Maddimax/tesla-proxy

@andig
Copy link
Member

andig commented Jun 23, 2024

Private repo? Anyway seems we can merge?

@andig andig added needs documentation Triggers issue creation in evcc-io/docs and removed needs documentation Triggers issue creation in evcc-io/docs labels Jun 23, 2024
@Maddimax
Copy link
Author

Ups, public now. +1 from me for merging it.

@andig
Copy link
Member

andig commented Jun 24, 2024

Wenn du Lust hast meld dich gerne mal auf Slack- wir könnten Entwicklerunterstützung gut brauchen 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants