NEWS
Test Tesla-Motors v1.0.0
-
@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@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 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.@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
-
@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.Du kannst z.B. hier nachlesen, wie das ein anderer implementiert hat:
http://visibletesla.com/Documentation/pages/SleepMode.htmlIst auch der Grund, weswegen mich der Adapter einiges an Arbeit gekostet hat
-
@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
-
@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.
Sieht man hier:
https://github.com/dbweb-ch/ioBroker.tesla-motors/blob/8fd1d74f8d818822e1100a998f38e05627550d71/main.js#L114Zusä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.
-
Sieht man hier:
https://github.com/dbweb-ch/ioBroker.tesla-motors/blob/8fd1d74f8d818822e1100a998f38e05627550d71/main.js#L114Zusä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.
Oder /set_temps ist such ein gutes beispiel, das erwartet
api/1/vehicles/:id/command/set_temps?driver_temp=:driver_temp&passenger_temp=:passenger_tempD.h. man muss mit mehr details auf die einzelnen Commands eingehen und kann nicht einfach alles als state übernehmen.
-
Oder /set_temps ist such ein gutes beispiel, das erwartet
api/1/vehicles/:id/command/set_temps?driver_temp=:driver_temp&passenger_temp=:passenger_tempD.h. man muss mit mehr details auf die einzelnen Commands eingehen und kann nicht einfach alles als state übernehmen.
@dbweb
Sleep check ist jetzt auch drin
https://github.com/TA2k/ioBroker.tesla-motors/blob/34dc6ba5de214b226e19e27f8b131ca8594b9d35/main.js#L592Es sollten jetzt auch alle remote befehle funktionieren
Ich werde dann noch die powerwalls datenpunkten erweitern
-
@dbweb
Sleep check ist jetzt auch drin
https://github.com/TA2k/ioBroker.tesla-motors/blob/34dc6ba5de214b226e19e27f8b131ca8594b9d35/main.js#L592Es sollten jetzt auch alle remote befehle funktionieren
Ich werde dann noch die powerwalls datenpunkten erweitern
@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 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!
@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
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.
@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.
-
@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#L245Auth Token 8h. OwnerToken 45Tage
Habe den PR übernommen. Aber die battery_level schwankt alle 15min? -
@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#L245Auth Token 8h. OwnerToken 45Tage
Habe den PR übernommen. Aber die battery_level schwankt alle 15min?@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 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.
-
@keksn Du musst dann unter Adapter gehen nach tesla suchen und dann auf +
um eine Instanz zu erzeugen
-
@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#L245Auth Token 8h. OwnerToken 45Tage
Habe den PR übernommen. Aber die battery_level schwankt alle 15min?@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.
-
@keksn Du musst dann unter Adapter gehen nach tesla suchen und dann auf +
um eine Instanz zu erzeugen
-
@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!
@dbweb eine Zwischenfrage: der Aktualisierungsinterval wird ja je nach Zustand des Fahrzeugs geändert. Kann man auch sagen welche Daten aktualisert weden oder werden immer alle aktualisiert?
Beispiel: beim Laden ist interessant charge_power relativ schnell zu aktualisieren, wohingegen eine Änderung der GPS-Daten und Fahrgeschwindigkeit keinen Sinn machen. Andersrum bei der Fahrt interessiert nicht charge_power. -
@dbweb eine Zwischenfrage: der Aktualisierungsinterval wird ja je nach Zustand des Fahrzeugs geändert. Kann man auch sagen welche Daten aktualisert weden oder werden immer alle aktualisiert?
Beispiel: beim Laden ist interessant charge_power relativ schnell zu aktualisieren, wohingegen eine Änderung der GPS-Daten und Fahrgeschwindigkeit keinen Sinn machen. Andersrum bei der Fahrt interessiert nicht charge_power.
Support us
776
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge