Test Tesla-Motors v1.0.0

[dbweb]

@tombox funktioniert soweit, gute Arbeit!
Die frage ist jetzt, wie wir das "zusammenbauen". Ich denke die ganze Logik mit aufwecken & schlafen lassen ist schon wichtig, vampire-drain ist bei Tesla massiv, wenn man ihn nicht schlafen lässt.
Variante A:
Teslajs stehen lassen, und deinen Flow nur verwenden, um ein Token zu erhalten.
Vorteil:

• Der rest des Adapters bleibt bestehen (Aufwecklogik etc.)
• die ganzen States bleiben bestehen
• abwärtskompatibel
  Nachteil:
• Abhängigkeit von teslajs bleibt
• Powerwalls & PV fehlt teilweise, es gibt evtl. auch noch ein paar andere States die fehlen.
  Variante B:
  Komplett auf das bisherige verzichten und auf deinem Aufbauen
  Vorteil:
• "clean" restart, keine Altlasten
• Keine Abhängigkeit von teslajs
  Nachteil:
• Aufwecklogik fehlt
• Nicht abwärtskompatibel, da Struktur der States anders ist und einige States anders heissen
  Variante C :
  teslajs rausoperieren und durch deinen Flow ersetzen, direkt mit Tesla kommunizieren
  Vorteil:
• Am saubersten
• Teils abwärtskompatibel
  Nachteil:
• Aufwändig

Was meinst du? Ich weis auch nicht genau, wie viel Zeit ich die nächsten Wochen dafür investieren kann.

[tombox]

@dbweb
Ich denke die Abhängigkeit zu teslajs macht kein Sinn da durch die Captcha eine tiefe Integration zum ioBroker notwendig ist, auch die Filterung nach Produkttyp und States finde ich nicht so gut.

Die Strukturänderung ist zwar ärgerlich aber hat den Vorteil dass die Powerwalls jetzt mit dabei sind und alle Datenpunkte und auch zukünftige Datenpunkte ohne Anpassung verfügbar sind. Das reduziert den Wartungsaufwand enorm.

Die Aufwecklogik habe ich nocht nicht ganz verstanden.
In meinem Adapter, kann man minutengenau den Updateinterval festlegen. Außerdem kann man einstellen ob das Fahrzeug vor jedem Update geweckt werden soll.

Wer vampire drain vorbeugen möchte deaktiviert die Option wakeup und es kommen nur neue Daten falls das Fahrzeug wach ist bzw werden die Daten vom letzten Stand gesendet.

Ich war nich ob man wakeup default mässig an oder aus stellt.

Welche Verbesserung könnte man da noch machen?

[dbweb]

@tombox Teslas habrn die eigenheit, dass sie nicht schlafen gehen, solange man Daten abfragt. D.h. wenn man immer nur dann Daten abfragt wenn er Wach ist, so geht er niemals mehr schlafen.
Deswegen die Aufwecklogik, das Ziel ist, möglichst nichts zu verpassen, aber trotzdem nicht Stundenlange abfragen wenn nichts passiert.
Wenn man sich bewegt, ist aber 1 Minute zu lange fürs Update, das reicht nicht für ein "Verfolgen".

[dbweb]

Als Beispiel:
Morgens setzt du die Klimaanlage auf "on". D.h. du wirst vermutlich bald losfahren. Daher macht es Sinn, die Daten regelmässig abzufragen.
Du kannst aber nicht fragen 'fährt das Auto' ohne es aktiv wach zu halten, wenn du aber nichts weiter abfragst, so wirst du die Abfahrt verpassen, du wirst nur irgendwann mitbekommen, dass das Auto wieder schläft.
Wenn du alle 10 Minuten Abfragst, bleibt das auto für immer Wach.

[tombox]

@dbweb Also müsste man schreiben überprüfen ob sich was änder oder ts mit tc vergleichen
Es wäre noch gut wann sich die timestamps wie zb tesla-motors.0.12345678901234567.vehicle_state.timestamp ändert.
Bei jedem Request oder nur bei Änderung

[dbweb]

@tombox nein das reicht eben nicht aus. Du hast zwei Endpoints, einer bei dem du siehst ob der wagen schläft, den kann man immer abfragen, und den zweiten, um alle Daten zu erhalten. Eine Abfrage darauf weckt den Wagen automatisch auf. Es gibt keine Möglichkeit abzufragen ob sich etwas ändert, ohne damit den Tesla-Internen Schlaftimer zurück zu setzen, womit er dann für 10-15 Minuten nicht mehr schläft.
Ist etwas komplexer das ganze als man es zuerst vermuten würde, ansonsten siehst du es evtl. in meinem Code was ich meine.

[tombox]

@dbweb Ok teslafi hat dazu ne gute erläuterung

https://owner-api.teslamotors.com/api/1/vehicles/:id
Kann man scheuen in welchem state sich das Fahrzeug befindet.

Wenn sich shift state , speed, charge oder climate sich innerhalb von 30min nicht ändert, dann 15min keine Abfragen machen und schauen ob er in sleep ist.

Kann ich noch einbauen

[dbweb]

Du kannst z.B. hier nachlesen, wie das ein anderer implementiert hat:
http://visibletesla.com/Documentation/pages/SleepMode.html

Ist auch der Grund, weswegen mich der Adapter einiges an Arbeit gekostet hat

[dbweb]

@tombox jepp ungefähr so habe ich das eingebaut. Aber auch wenn der User interagiert (z.B. öffnet) setze ich meinen Timer entsprechend zurück.

[dbweb]

Sieht man hier:
https://github.com/dbweb-ch/ioBroker.tesla-motors/blob/8fd1d74f8d818822e1100a998f38e05627550d71/main.js#L114

Zusätzlich:
Um ein Command abzusetzen, muss der Wagen Wach sein(z.B. heizung ein). D.h. man muss ihn zuerst Wecken, warten bis er wach ist, und dann den Befehl setzen. Der User will das vermutlich nicht jedesmal selbst machen und warten. Ich will morgens einen knopf Drücken und der Wagen heizt auf.

Etwas anderes:
Hast du das Refresh des Tokens nach <45 Tagen mittels refresh-Token auch eingebaut?

Einige Commands habe noch zusätzlich Optionen die man mitschicken muss, z.B. Homelink, oder sie erwarten spezifiscje values, z.B. "vent" für die Fenster.

[dbweb]

Oder /set_temps ist such ein gutes beispiel, das erwartet
api/1/vehicles/:id/command/set_temps?driver_temp=:driver_temp&passenger_temp=:passenger_temp

D.h. man muss mit mehr details auf die einzelnen Commands eingehen und kann nicht einfach alles als state übernehmen.

[tombox]

@dbweb
Sleep check ist jetzt auch drin
https://github.com/TA2k/ioBroker.tesla-motors/blob/34dc6ba5de214b226e19e27f8b131ca8594b9d35/main.js#L592

Es sollten jetzt auch alle remote befehle funktionieren

Ich werde dann noch die powerwalls datenpunkten erweitern

[dbweb]

@tombox sieht ziemlich gut aus.
Ein paar Sachen habe ich aufgrund meiner Erfahrung mit Teslaschnittstelle und Teslausern im Code gesehen:

• Du lässt Updates maximal alle 60 Sekunden zu. Für jemanden der seinen Weg mit dem Tesla aufzeichnen will, ist das zu wenig oft. Einige User wollten das so niedrig wie möglich. Ich denke Ideal wären hier Einstellungen wie: "Refresh time while moving", "Refresh time stillstand") oder sowas.
• Du rufst die Updates mit "interval" auf. Teslas können je nach Empfang manchmal sehr lange brauchen, bis sie antworten, mit Interval riskierst du ein "bubble up" an Events wenn die Abfrage länger dauert als der Interval, was komisches verhalten und hohen Speicherverbrauch zu Folge haben kann. Besser wäre mit setTimeout zu arbeiten.
• beim wake_up wartest du statisch 15 Sekunden, das kann manchmal länger dauern, und falls das Auto nicht erreichbar ist, wird es gar nicht klappen. Ich habe auch öfters gesehen, dass das Aufwachen erst nach einigen Versuchen geklappt hat, deswegen habe ich dort etwas mehr "Logik" eingebaut, siehe: https://github.com/dbweb-ch/ioBroker.tesla-motors/blob/8fd1d74f8d818822e1100a998f38e05627550d71/main.js#L643
• Ich hab deine Logik vom Refresh-Token nicht ganz verstanden, aber sie scheint mir no nicht ganz korrekt. Du musst das Token refreshen, bevor es abläuft (z.B. nach 30 der 45 Tagen), oder mindestens 1 Tag vor Ablauf. Du solltest das Token aber auch nicht zu häufig refreshen, das mag Tesla nicht und es kann gut sein, dass man damit auf die "blacklist" gesetzt wird.
• Du machst statisch 10 Sekunden nach jedem Befehl einen refresh der Daten. Das kann zu früh oder zu spät sein, und kann aber auch gleichzeitig mit dem interval-refresh zusammenfallen. Besser wäre, auf den erfolgreichen Befehl zu warten und dann ein Refresh zu machen.
• checkWaitForSleepState() -> du prüft dort auf Veränderung von bestimmten States. Das macht nur teilweise sinn, und wird teilweise fehlschlagen. z.B. ändert sich die battery_range immer mal wieder auch im Stillstand wenn das auto schlafen soll.
  Eher müsstest du auf die einzelnen States eingehen, so oder ähnlich wie ich das hier gemacht habe: https://github.com/dbweb-ch/ioBroker.tesla-motors/blob/8fd1d74f8d818822e1100a998f38e05627550d71/main.js#L133
  bei chargeState ist das auf Userwunsch so implementiert, damit das Laden sauber überwacht werden kann, er aber bei nichtladen und anschgeschlossen trotzdem mal schlafen kann.

Das wäre was ich jetzt so im Code gesehen habe, noch ohne zu testen.

Gute Arbeit soweit!

[tombox]

@dbweb
Das Minimum war bei 30sek aber habe es auf 10 Sekunden reduziert. Aber so eine niedrige Anzahl kann leicht zur Sperrung führen. Die zwei Intervalle kann ich machen wenn ich nochmal lust habe.

Bei sehr niedrigen Intervallen kann das passieren ja. Aber so ein request bricht ja nach 20 Sekunden eh ab.

Ich wecke jetzt bis der status online ist

Bisher habe ich immer ein neuen ownerToken geholt wenn der auth Token refresht werden muss. Also alle 8h. Eigenartig das man für AuthToken gesperrt werden kann. Ich hole jetzt ein ownerToken bei 0.75 der expiration time

Ich warte jetzt auf die Übermittlung des Befehls aber das heißt nicht das er ausgeführt ist das kann man denke ich nicht feststellen.

Ich habe battery_range auf battery_level geändert. Was spricht dagegen dass wenn sich keiner dieser states ändert auf den sleep zu warten. Wenn geladen wird dann muss sich ja innerhalb von 15min der battery_level ändern.

[dbweb]

@tombox
Sperrung wegen zu häufiger Abfrage habe ich bisher noch nicht gesehen. Die TeslaApp von Tesla selbst fragt bei fahrendem Fahrzeug sehr oft ab, man sieht die Bewegung fast "live", also denke ich im Bereich von 1s.
Bisher war das Auth-Token 45 Tage gültig, nicht nur 8h.
Was spricht dagegen dass wenn sich keiner dieser states ändert auf den sleep zu warten.
Umgekehrt, nicht zu schlafen, nur weil sich battery_level ändert wäre schlecht. Die Batterie entlädt sich immer etwas und "bewegt" sich daher ständig. Hab mal nen Pull-Request gemacht.

Ansonsten können wir hier jetzt wohl mal auf Rückmeldung der User warten.

[tombox]

@dbweb Ich denke nicht das die App die daten über Rest pullt, das würde die API nicht aushalten.
Ich denke die App wird die Daten streamen. Das macht auf jeden Fall mehr sinn als die Api zu bombardieren
https://github.com/dirkvm/teslams/blob/9467f7264961ecc1a609af25a68df3b57c9eb521/examples/streamws.js#L245

Auth Token 8h. OwnerToken 45Tage
Habe den PR übernommen. Aber die battery_level schwankt alle 15min?

[keksn]

@tombox Hallo, danke für den Adapter!! Ich sehe den Adaptern den Instanzen nur wenn ich ihn über den alten Installiere. Wenn ich den alten deinstalliert und dann den neuen installiere sehe ich keine Instanz trotz dessen die Version in der Adapter Übersicht als Installiert angezeigt wird und die Objekte sind auch vorhanden.

[tombox]

@keksn Du musst dann unter Adapter gehen nach tesla suchen und dann auf +

um eine Instanz zu erzeugen

[keksn]

oh Gott Anfängerfehler..Danke LG

[dbweb]

@tombox ah die streamapi hatte ich überlesen, ja das macht durchaus mehr sinn, können wir ja mal als "feature" für die Zukunft planen, klingt ja auch nicht sehr kompliziert zum implementieren.

weis nicht genau was du mit "authToken" und "OwnerToken" meinst, bisher kenne ich das "access_token" welches bei jedem Request mitgeschickt wird und 45 Tage gültig ist, und das "refresh_token" welches verwendet wird, um ein neues Access-Token zu holen. Evtl. haben wir aneinander vorbei geredet.