Test Tesla-Motors v1.0.0

[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 ...

[tombox]

@funcarv3r Ist denn das Auto wach? sieht eingeschlafen aus.
Kann ich machen

[funcarv3r]

@tombox
Er hatte tatsächlich "geschlafen", hab ihn mal geweckt, hat aber nichts verändert. Adapter beendet, den Baum vom Auto gelöscht und Adapter gestartet. Der Baum wurde sofort wieder hinzugefügt, aber wieder ohne RR...