Test Tesla-Motors v1.0.0

[tombox]

@dbweb Ja habe ich auch gesehen wenn das auto nicht fährt dann disconnected das fahrzeug nach 30sek. Wenn es Fährt dann erst nach ca 5min

[dbweb]

Ich habe mal noch etwas nachgelesen und getestet.
Die WS-Api könnte man auch dazu brauchen, den Schlafprozess zu optimieren.
Ich habe die WS-API bei mir mal als "immer aktiv" eingebaut.
Was ich festgestellt habe:
Aufwecken: Das Auto schläft, ich wecke es auf indem ich die TeslaApp öffne. Sobald das auto wach war, habe ich sofort ein "update" über WS erhalten.
D.h. man könnte einbauen, dass falls das Auto schläft, bei einem WS-Received sofort ein checkState läuft, ein Aufwachen würde man somit sofort bemerken und nicht erst nach dem eingestellten Interval. Wenn das Stabil läuft, könnte man beim schlafen sogar ganz auf die RestApi verzichten und nur noch per WS überwachen.
Einschlafen: Ich habe das auto einschlafen lassen, dabei aber die WS-Api aktiviert gelassen.
Das Auto ging nach 10 Minuten schlafen. WS hat das Auto nicht am schlafen gehindert, hat aber noch bis 30 Sekunden vorm Schlafen updates geliefert.
D.h. man müsste nicht mehr 30 Minuten warten bis "Waiting for sleep" beginnt, sondern könnte schon viel früher damit beginnen, dank der WS-Api würde man ein Losfahren trotzdem bemerken (shift_state) und das einschlafen abbrechen.
während das Auto schläft kriegt man vom WS auch keine Updates, ich kriege nur 1x pro Minute beim Wiederaufbau der Verbindung ein "control:hello" zurück.
Fahren:
Ich habe das Auto mal rasch umparkiert. Sobald man fährt, liefert WS sehr viel häufiger Daten. Die ersten 4 Datensätze kamen innerhalb von 12ms (gemäss log), danach im Schnitt 2x pro Sekunde. Sobald das auto wieder auf "P" umgestellt war kam ein "disconnected" und danach war der Stream wieder langsam, also auf ca. 10 Sekunden.

Ich lasse die WS-Api jetzt mal einen Tag aktiv, mal schauen wie sie reagiert, wenn das Auto bewegt wird. Interessant dürfte auch noch sein wie sich das ganze verhält, wenn das Auto nicht erreichbar ist.

Kleines Detail noch vom WS-Stream:

State value to set for "tesla-motors.0.1234567891234567.streamData.speed" has to be type "string" but received type "number"

[tombox]

@dbweb Das ist ja wirklich interessant. Wenn es nicht erreichbar ist versucht er trotzdem wieder zu verbinden.
Mann könnte für alle nicht disconnect fehler vielleicht ein timeout einbauen.
Das wichtige ist auch ob es sich auf den Akkustand auswirkt also wenn er im wach zustand diese daten liefern muss.

Lösche mal den ordner streamdata ob dann die type warning weg ist und dann noch die letzte aktuelle version installieren

[dbweb]

@tombox noch was, das Aufwecken ist grad etwas zu aggressive, evtl. hier noch ein sleep einbauen:
https://github.com/TA2k/ioBroker.tesla-motors/blob/476afe9c698be32daef5838c9501d4aa7af2fe95/main.js#L486

Waren bei mir grad 33 "wake_up" innerhalb von 10 Sekunden, das arme Auto brutal aus dem Schlaf gerissen

zudem erhalte ich manchmal:

	websocket error: Error: WebSocket was closed before the connection was established

10 Sekunden nach dem letzten sauberen WS received, 500ms vor dem "WS open", kein anderer Fehler dazwischen. Erschliesst sich mir jetzt nicht ganz wieso das gemeldet wird, WS war ja da offen.

[dbweb]

@tombox Testfahrt gemacht, testladen auch.

Funktioniert bisher wie angedacht, sobald man fährt, kommen sehr häufig Daten rein. Sobald man auf P schaltet kommt genau eine Meldung mit "P", danach nur noch "" als shift_state.
Es gibt aber immer mal wieder Aussetzer, so dass 10 Sekunden keine Daten kommen, in der Zeit kommen aber trotzdem aktuelle Daten von der Rest API, hat also nichts mit Empfang zu tun.
Das ist natürlich sehr interessant, u.a. sehe ich meine "Vollbremsung" von heute Mittag wegen eines Fussgängers klar in den Daten, innerhalb von 1.5s von 30 auf 0. Aber:
Ich vermute, die Stream-API ist nur für das "Summon"-Feature gedacht, also für das Autonome fahren des Teslas via TeslaApp. Es sind fast zu viele Daten die dabei auf den IO-Broker einprasseln, man erhält wirklich im Schnitt 2 Updates pro Sekunde. Ob das Tesla längerfristig zulassen wird finde ich eher fragwürdig.

Ich würde das daher eher so implementieren:
Streaming API nutzen für verbesserte Schlafüberwachung
Sobald das Auto fährt, aber nicht mehr auf Stream setzen sondern mit einstellbarem Interval abfragen
Usern einen Datenpunkt bieten, wo sie das Streamen während er Fahrt einschalten können.

Bei mir würde ich das dann z.B. so nutzen, dass wenn man in der VIS auf die Kartenansicht geht, man sieht, wo der Tesla genau ist, und das mit der StreamAPI schön "flüssig". Ansonsten würde ich die StreamAPI bei der Fahrt nicht nutzen, sind mir zu viele Daten die ich nicht brauche, ich würde dann auf einen Interval 1x pro Minute setzen. Andere User können das aber nach belieben einstellen.

Ich denke nicht, dass sich das auf den Akkustand im Wachzustand auswirkt, solange der Wagen nicht fährt kommen ja auch meist nur 1x Daten pro WS-Verbindung, also gleich viel wie über die Rest-API. Akku sparen ist ja v.a. wichtig im Schlafzustand.

Hier noch die "Warnungen" (neuste Version installiert, streamdata-ordner gelöscht):

State value to set for "tesla-motors.0.12111324123434326.charge_state.charger_phases" has to be stringified but received type "number"
State value to set for "tesla-motors.0.12111324123434326.drive_state.speed" has to be stringified but received type "number"

[marlan99]

@tombox ist es damit bei den Powerwalls auch möglich die prozentuale Notreserve zu verändern?
Ich meine damit den Minimalwert welcher für Notstrom verfügbar sein soll.

[tombox]

@marlan99 Ich habe blind eine remote option backup hinzugefügt bitte mal testen ob es das richtige backup ist. Ich habe es jetzt auf die energy_site gemacht und nicht die powerwall. Ich kenne den unterschied nicht. Einfach neuinstallieren

[marlan99]

@tombox Danke dir. Ich hatte es bisher noch gar nicht installiert gehabt.
Das habe ich nun nachgeholt und die Konfiguration mit deiner Anleitung im ersten post funktioniert perfekt.

Wenn ich über die App den Wert ändere sehe ich es in keinem verfügbaren Objekt.
Dann hab ich in dem von dir erstellten Objekt auf den Wert 6 gesetzt, wird jedoch in der App auch nicht übernommen.

Im Anhang mal ein Screenshot der Objekte von mir

Ich nehme an du hast keine Powerwall zum testen?

Zur Info: Aktuell gibt es zwei Einstellmöglichkeiten für die Powerwall:

1. Die Notstromreserve prozentual einstellen (0% - 100%)
2. Die prozentuale Limite bis wohin die Powerwall entladen werden darf, wenn bei Stromausfall das Auto geladen wird

[marlan99]

Hallo nochmal,

Ich denke die Powerwall Daten schlagen enorm auf die performance des ioBroker.
Ich habe in untenstehendem Screenshot zwei Objektbäume mit Namen "historyPower" und "powerHistory" die je 500 Ordner mit je 6 oder 8 Objekte beinhalten

Ich zeichne die In/Out Daten auf und bei untenstehendem Foto ist ersichtlich, dass jede Minute (Defaultabfrage 60 sek.) für 15 Sekunden lang Masse an Daten geliefert werden:

[tombox]

@marlan99 sind da hilfreiche Information dabei. Könnte auch limitieren

[marlan99]

@tombox es sind history Daten im 5 Minuten Intervall

aus meiner Sicht können beide Ordner ignoriert werden.
Falls jemand history Daten haben will kann man diese evtl. optional einmal pro Tag runterladen?
Oder man speichert via ioBroker die Daten in eine influxDB

[tombox]

@marlan99 Ich habe die powerhistory mal deaktiviert und dafür energy history und self consumption aufgenommen das sollte besser sein für I/O

hast du schon den remote punkt für notstromreserver probiert

[marlan99]

@tombox die history Daten hat er nun nur noch einmal drin und nicht mehr im 5 Minuten Intervall. sieht besser aus. Der Peak ist einmalig beim starten der Instanz

Habe nach dem aktualisieren des Adapters heute den Punkt Notstromreserve nochmal getestet.

• Der aktuelle Wert (bei mir 0%) wird nicht gesetzt. Initial steht der Datenpunkt auf "(null)"
• Wenn ich den Prozentwert in der Powerwall ändere bleibt der Datenpunkt auf "(null)"
• Wenn ich den Datenpunkt im ioBroker auf einen Zahlenwert setze, wird in der Powerwall der Prozentwert nicht übernommen.

[tombox]

@marlan99 In der Api gibt es backup für energy_site und powerwall. Was ist der Unterschied?

[marlan99]

@tombox ich kann da nur raten. Evtl. sind es die beiden Einstellmöglichkeiten die ich in der App habe? Siehe Screenshot.
Und ich sehe gerade, dass ich im Protokoll noch ein paar Fehlermeldungen erhalte.

[tombox]

@marlan99 ich habe mal das command auf powerwall geändert.. installier mal neu und probier nochmal

[marlan99]

@tombox leider keine Veränderung. Im System erfolgt keine Anpassung. Auch umgekehrt nicht, wenn ich den Wert lokal ändere, bleibt der Datenpunkt beim alten Wert

Hast du den Datenpunkt absichtlich "backup-backup_...." gewählt? Nicht dass es da evtl. einen typo drin hat.

[funcarv3r]

Der sieht ja richtig gut aus der Adapter, ich habe ihn vor gut einer Woche mal installiert und heute mal aktualisiert, ist echt was passiert.

Was aber letzte Woche angezeigt wurde und seit heute nicht mehr ist die Restreichweite des Tesla, hatte mir hierzu ein kleines Script geschrieben welches Meilen in KM umrechnet. Seit heute kam dann eine Warnung

tesla-motors.xxx.charge_state.battery_range

ist nicht mehr vorhanden, letzte Woche konnte ich hier noch die RR ablesen...

[tombox]

@funcarv3r eigentlich müsste der state da sein vielleicht liefert die api ihn nicht immer.
ich habe die km konvertierung integriert ist glaube besser als via skript

[funcarv3r]

@tombox
Ich hab jetzt noch mal komplett deinstalliert und den Adapter und die Instanz neu hinzugefügt, ohne Erfolg:

Kannst du Die Prozente der Powerwall und beim Auto auch einkürzen? Mache ich auch mit einem Script da mir 10 Stellen hinterm Komme zu lang ist ...