Impressum / Datenschutz Regeln Cookies
TFF FORUM TFF E.V. SUPERCHARGE-ME
TFF Forum

Powerwall 2 - Abfragen der API per ESP8266

Moin, wahrscheinlich findet sich hier ja jemand, der mir bei diesem Problem helfen könnte… Also, ich habe dieses Projekt zum Laufen gebracht, um Daten auf einem LCD-Bildschirm mit einem angeschlossenen ESP8266 anzuzeigen. Es ist Open Source, ich habe es vor etwa zwei Tagen veröffentlicht.

Das Problem ist, dass ich mich mit dem ESP8266 nicht mehr mit der Powerwall verbinden kann. Wenn ich es mit curl auf meinem PC mache, ist alles in Ordnung. Ich denke, dass es an dem Update auf Version 21.20.6 liegt. Das wird also wahrscheinlich die Ursache dafür sein, dass mein Projekt nicht mehr funktioniert. Ich habe bereits einige Leute gefragt, aber leider haben wir noch keine Lösung gefunden. In meinem Code wird bereits die Authentifikation wird mittels AuthCookie vorgenommen.

Gibt es hier jemanden, der genauere Informationen hat, was das API-Update bewirkt hat? Oder jemand, der ähnliche Probleme mit der ESP8266-Plattform hat?

Bei mir keine Probleme seit dem upgrade auf 21.20.6. daher meine folgenden Fragen:

-welche API nutzt du?
-hast du geprüft ob das cookie gültig ist?

Ich nutze folgende zwei Befehle

Cookie (alle 24h):
/usr/bin/curl -k -c /tmp/pw2.cookie -X POST -H „Content-Type: application/json“ -d ‚{„username“:„customer“,„password“:„XXXXXXX“, „email“:„irgendetwas“,„force_sm_off“:false}‘ https://192.168.1.152/api/login/Basic

API Abfrage (alle 20 sek.):
/usr/bin/curl -k -b /tmp/pw2.cookie https://192.168.1.152/api/system_status/soe

Das Passwort musst du oben noch für dich anpassen und die IP Adresse deines Gateway. Dann sollte es ebenfalls laufen

1 „Gefällt mir“

@marlan99 Bei mir ist alles gültig. Die API Requests funktionieren auch mit curl, das ist also nicht das Problem. Curl benutze ich allerdings nicht in meinem Projekt, da dieses Tool nicht für die Platform gedacht/gemacht ist. Ich muss halbmanuell HTTPS Requests machen. Ich kann einfach keine Verbindung mit dem ESP über https zur Powerwall aufbauen.

API requests sehen bei mir wie bei Dir aus. Also alles nach der inoffiziellen Dokumentation: https://github.com/vloschiavo/powerwall2

Wenn ich mir die tieferen Debug Ausgaben ausgeben lasse, kriege ich folgenden Error: BSSL:_wait_for_handshake: failed (Problem liegt also bei httpsClient.connect(powerwall_ip, 443) z.B. hier)

Das Projekt lief ja bis vor zwei Tagen in etwa Problemlos… Bis zu dem Update auf 21.20.6… Da ging dann absolut nichts mehr. Ich kann einfach nicht mehr mit https eine Verbindung aufbauen… Mit http gehts, allerdings kriegt man da ja dann nur einen 301, da nur https verwendet werden soll.

Als wir im Juli das Problem hatten, lag es an einem selbstsigniertem SSL-Zertifikat. Wir haben in FHEM damals die SSL-Validierung abgeschaltet und seitdem funktioniert es. Handshake Fehler deutet auf das selbe Problem hin.

1 „Gefällt mir“

Hey @Jaykoert, die SSL-Zertifikatsvalidierung überspringe ich ebenfalls, wie man hier im Code sieht. Es liegt wahrscheinlich an der Plattform… Ich gehe mal nicht davon aus, dass FHEM bei dir auf einem ESP8266 o.Ä. läuft… Wahrscheinlich nimmst du dafür einen Raspi oder so…

Hast du mal den Fehler gegoogelt? Meine C+±Kenntnisse sind nur sehr oberflächlich.
Ich habe in FHEM zwei Varianten, um die Powerwall auszulesen. Analog marlan99 Beispiel mit curl und ein Perl-Modul. Läuft beides auf einem Mac mini. Unsere Implementierung ist hier Zeile 427 und ab 887 sind vielleicht hilfreich.
In Perl gab es auch verschiedene sslArgs, viele davon haben nicht geholfen. Vielleicht musst du auch eine andere Funktion verwenden?

1 „Gefällt mir“

Hi @Jaykoert,

ich habe den Fehler schon gegoogelt. Leider findet man da recht wenig, bis auf eine mögliche Ursache. Die wäre, dass der Handshake zu lange dauert und die Powerwall dann die Verbindung kappt. Fände ich aber sehr komisch, wenn Tesla da so tief etwas geändert hätte und quasi die ganze Kommunikation umgekrempelt hätte. Könnte aber natürlich sein, ausschließen will ich das nicht, ich muss es aber noch versuchen zu testen.

Dein Code ist recht ähnlich wie meiner, ich habe mir ihn angeschaut, allerdings weiß ich nicht, ob mir da etwas weiter hilft. Trotzdem Danke.

Viele Grüße, Moritz

Hallo @moritzlerch ,

Die Änderung im FHEM Modul sah wie folgt aus:
(In Perl) sslargs => { SSL_hostname => 0, verify_hostname => 0, SSL_verify_mode => 0 },
Ich habe bisher durch Googeln nicht sicher herausgefunden was das heißt.
Aber es scheint damit zusammen zu hängen, dass der Client beim SSL dem Server mitteilen kann über welchen Namen er die Identität prüfen möchte. Da erwartet die Powerwall wohl seit dem Update eine Information (und wenn die Fehlt kommt wahrscheinlich die Aushandlung nicht zum Ziel…

Ursache ist wahrscheinlich eine geänderte Bibliothek die Tesla da verwendet…

Viele Grüße Michael

1 „Gefällt mir“

Ich habe einen ähnlichen Effekt mit IOBroker. Die API-Anfragen funktionierten bis jetzt immer, ich konnte mir auch immer neue Token holen. Seit dem Update schlägt die Authentisierung permanent fehlt und deshalb rückt Tesla auch keine frischen Token mehr heraus. Ich wundere mich auch, dass man davon zur Zeit im Netz noch nichts liest - kommt wahrscheinlich noch, wenn auch bei anderen das Token abläuft.

1 „Gefällt mir“

Hallo zusammen,

Nach meiner Einschätzung geht es um SNI als Server Name Indication. Keine Ahnung ob der ESP das kann.
Ich habe mal etwas gegoogelt, da gibt es wohl Bibliotheken die das können.

Viele Grüße Michael

1 „Gefällt mir“

Ich nutze in ioBroker die obigen beiden Befehle in blockly mit dem exec Baustein.
Wie beschrieben, läuft es bei mir inkl. täglichem Zertifikatsupdate und 20-sekündlicher Abfrage problemlos und kann euren Fehler leider nicht reproduzieren.

Problem liegt ja auch eher in einem „niedrigeren“ System, nämlich dem ESP8266. ioBroker o.Ä. laufen ja auf leistungsfähigeren Systemen, wie zum Beispiel einem Raspi. Allerdings war für mein Projekt der Anspruch, nicht so teure / leistungsfähige Komponenten einzusetzen und das ganze Standalone betreiben zu können.

Könntest du das bitte nochmal erläutern? Also wie du drauf gekommen bist und was du denkst, das man anders machen müsste. Danke!

Hallo @moritzlerch,

Du hast Dir aber schon mal die Mühe gemacht zu schauen wie das im FHEM Modul gelöst ist?
Ich habe mir das DIV angesehen, dass im Zusammenhang mit der 21.20.x Version eingebaut worden ist.
Die Version die mit der 20.49.x lief, lief bei der 21.20.x nicht mehr.
Wenn ich mir die Änderung ansehe, scheint mir das am plausibelsten.

Die Anmeldung ist identisch und auch das Self Signed Zertifikat war vorher auch so. Ebenso die verwendeten Codierungen der Zertifikate.

Bleibt also nach meinem Ermessen nur das.
Ggf. macht es Sinn mal mit dem Maintainer des FHEM Moduls zu sprechen. Der hat es ja geschafft. Wenn Du nach „esp8266 SNI“ googelst, findest Du Hinweise zu dem Thema, jedoch nicht speziell für Tesla.

Viele Grüße Michael

Hi @Elektron79,

danach habe ich schon gegoogelt, aber noch nichts plausibles gefunden. Ich werde morgen noch einmal recherchieren, allerdings muss ich schauen, ob das umsetzbar ist.

VG, Moritz