[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