[46_TeslaPowerwall2AC] neues Modul für Tesla Stromspeicher

[Eckat]

Hallo Michael,

Ich glaube nicht daß ich es zeitlich schaffe mich dessen an zu nehmen.



Grüße
Marko

Hallo Marko,

ich habe für 46_TeslaPowerwall2AC bzw. lib/FHEM/Devices/Tesla/Powerwall.pm einen Patch erstellt und auf meinem System ausführlich getestet.

Ausgangspunkt war, dass der Powerwall-Gateway gelegentlich den bestehenden Auth-Token verwirft und anschließend nur noch 401 Invalid bearer token zurückliefert. Das Modul hat sich davon bei mir nicht mehr selbst erholt, sondern erst nach manuellem Löschen des Tokens bzw. Neustart wieder funktioniert.

Im Zuge der Analyse sind noch einige weitere Punkte aufgefallen, die wir mit behoben bzw. bereinigt haben:

Automatische Recovery bei ungültigem Auth-Token

• Erkennung von HTTP/API 401 unabhängig von JSON-Key-Reihenfolge bzw. exakter Response-Formatierung
• ungültigen Token verwerfen
• Queue zurücksetzen
• automatisch neu einloggen
• anschließend das normale Polling ohne manuellen Eingriff fortsetzen

Queue-/Timer-Race beseitigt

• Bislang konnte Timer_GetData() durch ein breites RemoveInternalTimer($hash) auch einen bereits geplanten Write()-Timer entfernen.
• Zusätzlich war die Queue bereits leer, während ein asynchroner HTTP-Request noch lief.
• Dafür gibt es jetzt einen expliziten requestInFlight-Status, sodass nur ein Request gleichzeitig aktiv ist und kein zweiter Login/Poll-Zyklus parallel gestartet wird.

Defensiver Umgang mit leerer Queue

• Ein verspäteter bzw. überzähliger Write()-Aufruf auf leerer Queue wird sauber ignoriert, statt mit einem undefinierten Queue-Eintrag weiterzulaufen.

Robustere HTTP-/JSON-Fehlerbehandlung

• HTTP-Fehler werden vor dem JSON-Decoding behandelt.
• Plaintext-Antworten wie 404 page not found erzeugen dadurch keinen irreführenden JSON-Fehler mehr.
• Unerwartete Nicht-JSON-Antworten blockieren die Queue nicht.

Token nicht mehr im Log

• Die Login-Response wird nicht mehr vollständig ins Verbose-Log geschrieben.
• Stattdessen erscheint nur noch <token redacted>.

customer/registration als optionaler Endpoint

• Auf meiner aktuellen Gateway-Firmware 26.34.0 liefert /api/customer/registration reproduzierbar HTTP 404.
• Nach dem ersten 404 wird der Endpoint für die aktuelle FHEM-Laufzeit nicht weiter automatisch gepollt.
• Nach einem FHEM-Neustart wird er einmal erneut geprüft, falls eine spätere Firmware ihn wieder bereitstellt.
• Ein erwarteter 404 dieses optionalen Endpoints erzeugt bewusst kein lastRequestError.

Redundanten site_info/site_name-Request entfernt

• /api/site_info liefert bei aktueller Firmware bereits site_name und timezone.
• Der zusätzliche Request auf /api/site_info/site_name entfällt.
• Die bisherigen sitename-site_name- und sitename-timezone-Readings werden aus Kompatibilitätsgründen weiterhin aus der site_info-Antwort gepflegt.

Getestet habe ich das u. a. mit einem absichtlich ungültig gesetzten Token. Dabei wurde genau einmal ein 401 erkannt, automatisch neu eingeloggt und anschließend das normale Polling ohne Neustart oder manuellen Eingriff fortgesetzt. Mehrere nachfolgende Poll-Zyklen liefen ebenfalls sauber durch.

Ich würde das gern als Pull Request gegen

git.cooltux.net/FHEM/mod-TeslaPowerwall2AC

einreichen.

Auf git.cooltux.net sehe ich allerdings nur die Anmeldung über ,,IAM COOLTUXNET Auth". Dort gibt es bei mir keine Möglichkeit zur Registrierung. Ein separates Konto bei gitea.com hilft erwartungsgemäß ebenfalls nicht, da das eine andere Instanz ist.

Wie ist aktuell der vorgesehene Weg, um einen Account für einen Pull Request zu bekommen bzw. wie möchtest du den Patch am liebsten erhalten?

Den konsolidierten Patch und eine Beschreibung der Änderungen habe ich bereits fertig.

[CoolTux]

Guten Abend,

Wenn Du gerne möchtest kannst Du Dich nun registrieren. Gib mir Bescheid wenn das geklappt hat dann schaue ich bezüglich der weiteren Vorgehensweise.



Grüße

[Elektron]

Hi @cooltux,

Wäre super wenn Du Dir die Änderungen anschauen könntest und ggf. ein neues Release zur Verfügung stellen könntest.
Ich bin auch noch immer von ungültigen Tokens betroffen und muss regelmäßig neu starten.
Zusätzlich fragt das Modul schon seit einiger Zeit Daten ab, die es nicht mehr gibt. (Wo die 404 kommt.).
Ich weiß nicht welche Version Eckat als Basis genommen hat. Ich nutze auf einer Installation die 2.0.0 und auf einer die 2.1.0 aus Deinem Repository (die verhalten sich in Bezug auf das Verhalten wenn der Token ungültig wird - nicht wirklich unterschiedlich.

Eine Anregung vielleicht noch an Eckat, vielleicht macht es noch Sinn zwei Update-Rythmen zu haben. Es gibt ja eine ganze Reihe von Informationen die sich nicht schnell ändern, dafür könnte Mann ggf. die Ladeleistung, Entladeleistung und SoC etwas öfter abfragen...


Vielen Dank für Euren Einsatz und viele Grüße Michael

[Eckat]

Hallo ihr beiden 

Marko, ich habe mich registriert (gerade). Das hat auch soweit funktioniert.
Er meldet jetzt "nur": Die Anmeldung mit diesem Konto ist nicht gestattet. Bitte kontaktiere den Administrator.

Michael, Basis von meinen Änderungen war 2.1.0

Gruß, Carsten

[CoolTux]

Hallo ihr beiden 

Marko, ich habe mich registriert (gerade). Das hat auch soweit funktioniert.
Er meldet jetzt "nur": Die Anmeldung mit diesem Konto ist nicht gestattet. Bitte kontaktiere den Administrator.

Michael, Basis von meinen Änderungen war 2.1.0

Gruß, Carsten

Probiere bitte noch einmal. Sollte nun funktionieren. Musste Dich noch der Gruppe hinzufügen.

[Eckat]

Hallo ihr beiden 

Marko, ich habe mich registriert (gerade). Das hat auch soweit funktioniert.
Er meldet jetzt "nur": Die Anmeldung mit diesem Konto ist nicht gestattet. Bitte kontaktiere den Administrator.

Michael, Basis von meinen Änderungen war 2.1.0

Gruß, Carsten

Probiere bitte noch einmal. Sollte nun funktionieren. Musste Dich noch der Gruppe hinzufügen.

Ja, hat funktioniert.
Sei bitte gnädig, ist mein erster öffentlicher PR 

[CoolTux]

Ist ja gar nicht öffentlich. Es gibt nur 4 Leute auf meinem persönlichen Git.

Ist dein PR fertig für einen merge oder soll ich noch warten. Der steht aktuell noch als Work in Progress

[Eckat]

Sorry, das war ein unüberlegter Klick 
Ja, der sollte fertig sein.

Bin aber für jede Kritik offen! Perl ist nicht meine "Haupt-Programmiersprache".

[CoolTux]

Ich werde wohl keine Zeit finden mir das groß an zu sehen. Wenn Du sagst das es bei Dir funktioniert dann geben wir es so zum testen an andere. Schaffe es aber erst kommende Woche das für andere frei zu geben.

[Eckat]

Bei mir funktioniert es jetzt etwas mehr als 1 Woche.
Worauf man vermutlich nicht warten kann, das Tesla eine neue Software Version aufspielt. Das erfolgt mehr oder weniger unregelmäßig (ganz grob ca. 1x im Monat).

[CoolTux]

Ich habe mal ein wenig versucht das Modul einem refactoring zu unterziehen.

Kann das bitte jemand testen? Aber mit ganz viel Gefühl. Kann sein das ein neuladen schon fhem zum Absturz bringt. Kann aktuell leider nicht testen.



https://git.cooltux.net/FHEM/mod-TeslaPowerwall2AC/raw/branch/patch-refactoring/lib/FHEM/Devices/Tesla/Powerwall.pm

[Eckat]

Ich habe mal ein wenig versucht das Modul einem refactoring zu unterziehen.

Kann das bitte jemand testen? Aber mit ganz viel Gefühl. Kann sein das ein neuladen schon fhem zum Absturz bringt. Kann aktuell leider nicht testen.



https://git.cooltux.net/FHEM/mod-TeslaPowerwall2AC/raw/branch/patch-refactoring/lib/FHEM/Devices/Tesla/Powerwall.pm

Das Refactoring finde ich insgesamt sehr gelungen. Gerade die Vereinfachung und das Zusammenfassen der bislang teilweise doppelten Logik macht den Code aus meiner Sicht deutlich übersichtlicher und wartbarer.

Bevor ich den Branch bei mir teste, ist mir beim Durchsehen von

Code Auswählen Erweitern

Flatten_JSON() allerdings eine mögliche Regression bei den Reading-Namen aufgefallen.

Aktuell wird dort mit

Code Auswählen Erweitern

$k =~ s/s$//xg if $prefix ne '';

bei jedem verschachtelten JSON-Key ein abschließendes

Code Auswählen Erweitern

s entfernt.

Dadurch würde z.B.

Code Auswählen Erweitern

status

zu

Code Auswählen Erweitern

statu

werden.

Gleichzeitig bleibt beim Root-Array

Code Auswählen Erweitern

powerwalls das abschließende

Code Auswählen Erweitern

s erhalten, weil dort der Prefix noch leer ist.

Bisher entstehen bei mir z.B. Readings wie:

Code Auswählen Erweitern

powerwalls-powerwall_0_commissioning_diagnostic_check_0_status

Mit der neuen

Code Auswählen Erweitern

Flatten_JSON()-Logik würde daraus nach meinem Verständnis:

Code Auswählen Erweitern

powerwalls-powerwalls_0_commissioning_diagnostic_check_0_statu

Die bisherige Implementierung hat die Singularisierung nach meinem Verständnis gezielt bei Array-Bezeichnungen vorgenommen, also z.B.

Code Auswählen Erweitern

powerwalls -> powerwall
checks     -> check

und nicht generell bei jedem Hash-Key.

War die Änderung der Reading-Namen so beabsichtigt?

Falls nicht, müsste die Singularisierung vermutlich in den ARRAY-Zweig verschoben werden, statt sie auf jeden Hash-Key anzuwenden.

Ich würde den Refactoring-Branch gerne auf meinem Gateway testen, wollte das aber vorher klären, weil mein Test leider nur auf meinem produktiven FHEM möglich ist.

[CoolTux]

Müsste ich mir noch mal in Ruhe anschauen. Beabsichtigt war es in der Tat eher nicht.

Ich schau da die Tage noch mal.

[CoolTux]

Ich bilde mir ein das ich es gefixt habe. Vielen Dank für Deine Aufmerksamkeit.

Die Ersetzung würde versehentlich auf jeden Kind-Knoten angewandt, sobald man sich nicht mehr auf der Root-Ebene befand. Deswegen der Käse mit "status".
Ich mache es jetzt so, daß ich die Regex-Ersetzung nur noch dann anwende, wenn der Wert hinter dem aktuellen Hash-Key vom Typ ARRAY ist.



Grüße