Seit etwa einer Woche liefert das Modul 46_TeslaPowerwall2AC.pm bei mir keine Readings mehr. Eine erste Analyse hat ergeben, dass alle API-Endpoints an das Tesla Energy Gateway nur mehr eine Fehlermeldung zurückgeben:
{"code":403,"error":"Unable to GET to resource","message":"User does not have adequate access rights"}
Offenbar erfordert das Gateway-API mittlerweile eine Anmeldung, die das FHEM-Modul leider (noch) nicht unterstützt. Hat hier eventuall bereits jemand eine Lösung oder ein Workaround für dieses Problem?
Edit: Die TEG-Version (zu sehen auf der Login-Seite des Energy Gateways) ist 20.49.0
So, jetzt antworte ich mir selber, weil ich einen Workaround gefunden habe.
Wie es scheint, hat sich das Format des Authentication-Headers geändert. Bisher war folgende Headerzeile bei den API-Abfragen nötig Authentication: Bearer <token> Neu ist es Cookie: AuthCookie=<token>;
Ich habe das Gefühl, dass das API bisher ganz ohne Authentication funktioniert hat, denn die im Modul hartcodierte Berechnung des Passworts aus der Gateway-Seriennummer funktioniert natürlich nur, solange das Passwort nicht manuell geändert wurde. Nun, ich hatte es geändert und bekam dennoch die Readings. Seit letzter Woche dann allerdings nicht mehr.
Offen gestanden habe ich den Code des Moduls nicht wirklich verstanden, vor allem nicht, wie es mit dem Rest von FHEM interagiert und was genau wann aufgerufen wird. Als quick fix habe ich die Funktion CreateUri so modifiziert, dass bei jedem API-Aufruf ausser login die Headerzeile mit dem Cookie hinzugefügt wird. Leider habe ich es nicht geschafft, die Reihenfolge der API-Aufrufe zu kontrollieren, so dass login als Erstes kommt. Das Ergebnis ist nun, dass die ersten paar Aufrufe alle fehlschlagen, bis dann login kommt. Alle folgenden API-Calls schicken dann das AuthCookie mit.
Nicht schön, funktioniert aber. Meine Perl-Fähigkeiten sind halt nicht weit genug entwickelt, um das sauber umzuschreiben. Ehrlich gesagt habe ich im Moment auch nicht die Zeit, mich da tiefer einzuarbeiten. Mit einem dauerhaften Provisorium kann ich prima leben 8)
Hallo lacleman,
Könntest du bitte genauer beschreiben wie du das gemacht hast mit der api von Tesla?
Danke und Gruß
ather
Ich benutze das Modul 46_TeslaPowerwall2AC.
Neu ist es Cookie: AuthCookie=<token>;
und wo bzw. wie gibst du das genau ein? Wie kommst du an den Token?
Ich kann zwar ein cookie generieren aber ich weiss nicht wo man das im modul umstellt.
Gruß
Ather
Zitat von: lacleman am 09 Februar 2021, 19:59:37
So, jetzt antworte ich mir selber, weil ich einen Workaround gefunden habe.
Wie es scheint, hat sich das Format des Authentication-Headers geändert. Bisher war folgende Headerzeile bei den API-Abfragen nötig Authentication: Bearer <token> Neu ist es Cookie: AuthCookie=<token>;
Ich habe das Gefühl, dass das API bisher ganz ohne Authentication funktioniert hat, denn die im Modul hartcodierte Berechnung des Passworts aus der Gateway-Seriennummer funktioniert natürlich nur, solange das Passwort nicht manuell geändert wurde. Nun, ich hatte es geändert und bekam dennoch die Readings. Seit letzter Woche dann allerdings nicht mehr.
Offen gestanden habe ich den Code des Moduls nicht wirklich verstanden, vor allem nicht, wie es mit dem Rest von FHEM interagiert und was genau wann aufgerufen wird. Als quick fix habe ich die Funktion CreateUri so modifiziert, dass bei jedem API-Aufruf ausser login die Headerzeile mit dem Cookie hinzugefügt wird. Leider habe ich es nicht geschafft, die Reihenfolge der API-Aufrufe zu kontrollieren, so dass login als Erstes kommt. Das Ergebnis ist nun, dass die ersten paar Aufrufe alle fehlschlagen, bis dann login kommt. Alle folgenden API-Calls schicken dann das AuthCookie mit.
Nicht schön, funktioniert aber. Meine Perl-Fähigkeiten sind halt nicht weit genug entwickelt, um das sauber umzuschreiben. Ehrlich gesagt habe ich im Moment auch nicht die Zeit, mich da tiefer einzuarbeiten. Mit einem dauerhaften Provisorium kann ich prima leben 8)
Kannst du deine Änderungen im Modul kurz hier posten? Am besten als Quellcode o.ä. dann könnten wir es als Fork einstellen in GitHub,..
Zitat von: lacleman am 09 Februar 2021, 19:59:37
So, jetzt antworte ich mir selber, weil ich einen Workaround gefunden habe.
Wie es scheint, hat sich das Format des Authentication-Headers geändert. Bisher war folgende Headerzeile bei den API-Abfragen nötig Authentication: Bearer <token> Neu ist es Cookie: AuthCookie=<token>;
Ich habe das Gefühl, dass das API bisher ganz ohne Authentication funktioniert hat, denn die im Modul hartcodierte Berechnung des Passworts aus der Gateway-Seriennummer funktioniert natürlich nur, solange das Passwort nicht manuell geändert wurde. Nun, ich hatte es geändert und bekam dennoch die Readings. Seit letzter Woche dann allerdings nicht mehr.
Offen gestanden habe ich den Code des Moduls nicht wirklich verstanden, vor allem nicht, wie es mit dem Rest von FHEM interagiert und was genau wann aufgerufen wird. Als quick fix habe ich die Funktion CreateUri so modifiziert, dass bei jedem API-Aufruf ausser login die Headerzeile mit dem Cookie hinzugefügt wird. Leider habe ich es nicht geschafft, die Reihenfolge der API-Aufrufe zu kontrollieren, so dass login als Erstes kommt. Das Ergebnis ist nun, dass die ersten paar Aufrufe alle fehlschlagen, bis dann login kommt. Alle folgenden API-Calls schicken dann das AuthCookie mit.
Nicht schön, funktioniert aber. Meine Perl-Fähigkeiten sind halt nicht weit genug entwickelt, um das sauber umzuschreiben. Ehrlich gesagt habe ich im Moment auch nicht die Zeit, mich da tiefer einzuarbeiten. Mit einem dauerhaften Provisorium kann ich prima leben 8)
Da ich sehr wenig Zeit aktuell habe, kannst Du mir Deinen Code zukommen lassen. Kannst mir gerne Deine ganze pm Datei schicken. Sprich mich einfach mal über PN an.
Zitat von: TimoD am 26 Februar 2021, 09:58:23
Kannst du deine Änderungen im Modul kurz hier posten? Am besten als Quellcode o.ä. dann könnten wir es als Fork einstellen in GitHub,..
So eine Aussage ist totaler Mist. Warum arbeitet Ihr nicht mit den Entwickler zusammen und versucht ihn zu unterstützen!!!!! Richtig wäre es einen Patch zu erstellen oder auf Github zum Modul einen pull Request.
Grüße
Hallo zusammen,
ich werde aus dem Hinweis auch nicht ganz schlau.
Die einzige Stelle die ich gefunden habe die "so ungefaehr" passt ist in Zeile 808:
Hier der erste Teil der Funtion, die Aenderung muesste dann ganz unten stehen...
sub CreateUri($$) {
my ( $hash, $path ) = @_;
my $host = $hash->{HOST};
my $method = 'GET';
my $uri;
my $header;
my $data;
if ( $path eq 'powerwallsstop'
or $path eq 'powerwallsruns' )
{
$uri = $host . '/api/' . $cmdPaths{$path};
}
else {
$uri = $host . '/api/' . $paths{$path};
}
if ( $path eq 'sitemasterrun' ) {
$header = 'Authorization: Bearer' . $hash->{TOKEN};
}
Alleine mir ist nicht klar, ob das ersetzt oder zusaetzlich in den Header muss...
Wenn ich das verstanden habe, schicke ich auch gerne einen Pull request.
Viele Gruesse
Michael
Zitat von: CoolTux am 26 Februar 2021, 10:25:07
So eine Aussage ist totaler Mist. Warum arbeitet Ihr nicht mit den Entwickler zusammen und versucht ihn zu unterstützen!!!!! Richtig wäre es einen Patch zu erstellen oder auf Github zum Modul einen pull Request.
Grüße
Da es mir genauso geht wie dir
Da ich sehr wenig Zeit aktuell habe und ich auch nicht die Zeit habe mich mit Dingen auseinander zu setzen, von denen ich keine Ahnung habe,... außerdem würde das dir doch hoffentlich genauso helfen,..
Zusätzlich: Ich sehe einen Workaround als nichts an, was ins eigentlich Release gehört,... da ich dachte, da du an einem wirklichen Fix dran bist.
Also vielen Dank fürs betiteln als "totaler Mist" ;-)
Zitat von: TimoD am 26 Februar 2021, 14:59:42
Da es mir genauso geht wie dir Da ich sehr wenig Zeit aktuell habe und ich auch nicht die Zeit habe mich mit Dingen auseinander zu setzen, von denen ich keine Ahnung habe,... außerdem würde das dir doch hoffentlich genauso helfen,..
Zusätzlich: Ich sehe einen Workaround als nichts an, was ins eigentlich Release gehört,... da ich dachte, da du an einem wirklichen Fix dran bist.
Also vielen Dank fürs betiteln als "totaler Mist" ;-)
Ok ich hätte besser zitieren sollen. Der totale Mist bezog sich einzig und alleine auf die Aussage mit dem Fork. Sorry das war sehr schlecht von mir zitiert.
Hallo zusammen,
ich habe das mal nach bestem Wissen und Gewissen ausprobiert und versucht nachzubasteln.
Bisher ohne Erfolg!
Was habe ich gemacht?
Mit curl am Tasla Gateway angemeldet und den Auth-Token in einer Datei (cookies.txt) gespeichert.
Zeile 808 geaendert: $header = 'Cookie: AuthCookie=Jy_ABCDEpsABCDEzMY8Pp1234567890120Q1234567890pBR_1234567890tF1234567890Kf1234567890Lgw==' . $hash->{TOKEN};
Hier den AuthToken aus der cookies.txt verwendet.
Ich habe da auch hinten den Teil mit .$hash->{TOKEN} mal weggelassen, macht aber nei mir keinen Unterschied.
Ich bekomme jetzt immer noch die 403, manchmal aber auch einen Timeout...
Wie gesagt, das tut noch nicht, aber vielleicht hat einer eine Idee.
Viele Gruesse
Michael
Es gibt eine neue Version zum testen
https://forum.fhem.de/index.php/topic,78145.0.html