Und gerade getestet: LÄUFT!
3 Likes
DANKEEEEE!
Wenn wir euch nicht hätten…
1 Like
Nur so interessehalber.
Die neue URL ‚https://pc-api.polestar.com/eu-north-1/mystar-v2/‘ ist ja nun dieselbe wie für die Abfrage der Battery und Odometer Daten.
Hast du mal geschaut ob da nun noch einige interessante Daten mehr zur Verfügung stehen?
Es gab hier mal den Versuch das gesamte GraphQL Schema aufzulisten: the whole graphql schema · pypolestar/polestar_api · Discussion #19 · GitHub
Bin mir aber nicht sicher, ob das noch aktuell ist 
Kaum vorstellbar, dass das noch aktuell ist. Das stammt ja aus einer Dokumentation, also einer Webseite, auf der man das ganze Schema durchklicken konnte. Das finde ich nur grad nicht mehr.
…und ewig grüßt das Murmeltier. Egal was ich mache ich bekomme nur Fehlermeldungen und Abbrüche:
Was mache ich falsch?
Edit: Da antworte ich mir 'mal selbst:
man muss natürlich vorher den Container stoppen! !!! - Hätte mir auch früher einfallen können…
1 Like
mit den EVN Variablen hat das SUPER funktoniert! danke dir für die Hilfe!
1 Like
Top Arbeit! Vielen Dank!
Das klappt aktuell super und ist Basis für eine Home Assistant Visualisierung
Eine Frage: Der Wert bei
„POLESTAR_CYCLE: 300 # seconds`“
ist fix/bewusst so gewählt? Oder kann das variiert/kleiner gewählt werden, um z.B. PV gesteuertes Laden zu realisieren?
Alle Werte in der docker-compose.yml sind (bei allen Containern) dafür da, dass man sie an die eigenen Bedürfnisse anpasst. Also nein, ein vernünftiger Default, also bewusst so gewählt
Ja, könnte man, aber weniger als 5 Minuten macht eigentlich keinen Sinn und würde schlimmstenfalls zur Sperrung des Accounts führen können, wenn die API das abfragt.
Aber ich verstehe auch Deinen Use-Case nicht ganz.
Bei PV-gesteuertem Laden interessiert mich der SOC nur am Rande (ist eh nicht besser als 1% aufgelöst) und spannend ist der Netto-Hausverbrauch.
Wofür brauchst Du dann noch aktuellere Daten als alle 5 Minuten?
Hallo @CONSULitAS: du hast natürlich vollkommen recht, der SoC ist weniger von Interesse, aber die Watt (charging Power). Aber faktisch bin ich noch nicht so weit. Ziel wäre das dann mit Evcc zu regeln.
Ich habe testweise probiert den Wert auf 100 runter zu setzen, aber dann kamen keinen Werte mehr. Kann aber auch sein, das ich da was falsch gemacht habe. Mit Docker mache ich gerade die ersten Schritte in einem Proxmox Container;-)
Dann probiere ich das einfach noch mal……
Was mir auch noch aufgefallen ist: in mqtt bleibt die charging Power auf dem ‚alten‘ Wert und sinkt nicht auf 0, wenn das Laden beendet ist oder pausiert. Das ist für die Anzeige auch etwas misslich. Ich habe mir dann einen Helfer gebaut, der den Wert auf 0 setzt……
Wenn du evcc verwendest brauchst du die info vom Überschuss(überschüssige Leistung die ins Netz gespeist wird) und die wallbox, die kontrolliert werden kann von evcc.
Der SoC ist interessant, aber nicht zwingend notwendig.
1 Like
@CONSULitAS vielen Dank für die Arbeit. 
Nachdem ich keine NodeRED Installation habe und auch nicht vor hatte eine aufzubauen, hab ich mal einen PR aufgemacht für optionales direktes MQTT forwarding.
Mosquitto selbst hat zwar auch ein Topic Remapping, allerdings kann man den lokalen Prefix nicht weg konfigurieren, daher musste eine Erweiterung für das Python Script her.
im Endeffekt gibt es 4 neue Environmentvariablen:
OPENWB_HOST = os.getenv("OPENWB_HOST", "localhost")
OPENWB_PORT = int(os.getenv("OPENWB_PORT", 1883))
OPENWB_TOPIC = os.getenv("OPENWB_TOPIC", "openWB/set/lp/1/%Soc")
OPENWB_PUBLISH = os.getenv("OPENWB_PUBLISH", False)
von denen man normalerweise nur zwei setzen muss:
OPENWB_HOST: 192.168.1.100 # oder welche IP auch immer
OPENWB_PUBLISH: True # um die neue Funktion zu aktivieren
@yeti Da ich ja auch eine openWB habe und ich es eigentlich vorziehe nicht so viele Zwischenschritte zu machen, um die Ausfallsicherheit zu erhöhen, gefällt mir das ganz gut.
Auch der Code sieht ordentlich aus.
Ich hätte da (neben squashen der Commits, siehe GitHub) noch einen Vorschlag:
Für die weniger bedarften User unter uns würde ich OPENWB_TOPIC aufteilen in
OPENWB_LP = 1 # oder 2
OPENWB_TOPIC = "openWB/set/lp/{OPENWB_LP}/%Soc"
Und dann im Code halt mit f("...") auflösen.
Dann muss der normale User nur seinen LP setzen und sich nicht mit den MQTT-Feinheiten der openWB auseinandersetzen.
Na?
1 Like
klingt gut. Ja, ich hatte mir auch schon Gedanken gemacht, wie man das am besten konfigurierbar macht. Aber dein Vorschlag, gefällt mir gut! Soll ich das nachziehen, oder bist du da eh schon dran?
Ja, bitte!
Done. hab die angeregten Changes in einen extra Commit gesteckt um die Änderungen leichter sichtbar zumachen.
1 Like
Jetzt kommt doch noch eine Frage auf:
Der MQTT läuft bei mir unter dem IOBroker auf einem Raspi. Die Werte der Polestar-API werden nur dann neu beschrieben wenn sich tatsächlich ein neuer Wert auf dem Polestar -Server vorliegt. Das ist zwar ökonomisch und verhindert unnötige Schreibzugriffe, hat aber einen entscheidenden Nachteil: sollte der Polestar-Server nicht erreichbar sein bekommt das der IOBroker nicht mit.
Meine vorherige (Tibber-) Lösung von @Electrified hatte die Kommunikation zum Server abgefragt und einen Status übermittelt (200= alles OK, 400=Login nicht möglich etc.). Diesen Status habe ich dann in meinem IOBroker-Skript verarbeitet, z.B. ist der übermittelte SoC wirklich ein aktueller Wert oder „Schnee von gestern“. Irgendwie wußte die Abfrage auch wann das Auto das letzte Mal Daten an den Server geschickt hat - diese Info habe ich für mein Zielladen gerne genutzt (war der SoC nicht aktuell, habe ich auf geladene kWh geschaltet).
Das geht jetzt nicht mehr. Darum die Frage: wäre es möglich so etwas zu realisieren, oder gibt es einen Work around den ich nicht sehe?
@CONSULitAS der letzte Commit von mir, läuft auf meinem Odroid seit ein paar Tagen problemlos und unauffällig.
Das sollte sich aus einer Kombination von QoS, Retain und Keep Alive möglich sein. Bedarf dann aber noch einiger Anpassungen
Wenn ich das richtig sehe würde das erlauben die Verbindung MQTT ← Polestar-Server zu überprüfen. Das würde mein Hauptproblem (keine Antwort vom Server) lösen. Muss ich mir 'mal ansehen ob ich das eingebaut bekomme.
Die Verbindung Auto → Polestar-Server (die Aktualität der vorliegenden Daten) kann von Extern ohnehin nur logisch auf Plausibilität geprüft werden - oder?
