-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSA Car Controller SoC #2046
PSA Car Controller SoC #2046
Conversation
Das Modul scheint ja ein reiner HTTP Abruf zu sein. Ein HTTP SoC Modul gibts ja bereits, wäre es nicht ggf. geschickter das um die Möglichkeit JSON Felder auszuwerten zu erweitern? Die Funktionalität gibts in den Zählermodulen ja schon, sollte sich ja einfach übertragen lassen. |
PSA servers are slow, therefore timeout had to be increased.
Dafür müsste das HTTP-Modul so erweitert werden, dass es konfigurierbar nur einen Request macht (nicht zwei wie jetzt!) und daraus per JSON die zwei Datenfelder SoC und Reichweite auf einmal extrahiert. Außerdem müssten Optionen hinzugefügt werden für SoC-Berechnung während Ladung und ein Feld für das verlängerte Timeout. Der Datastore müsste eine Update-Funktion erhalten, die die neuen Einstellungen in bestehenden Konfigurationen hinzufügt. Außerdem müsste für PSA-Controller-User irgendwo ein umfangreicher Hilfetext angelegt werden, den die auch finden. Das schien mir alles zusammen unnötig kompliziert und benutzerunfreundlich. Im Zweifel würde man wohl eher noch ein generisches JSON-Modul inkl. Optionen "Berechnung während Ladung" und Timeout hinzufügen und das HTTP-Modul so lassen. So ist es ja auch bei den Zählern. Das hätte immer noch den Nachteil, dass für PSA-Controller-User irgendwo ein Hilfetext hinterlegt werden muss, damit die wissen, dass sie den PSA-Controller damit anbinden können und wie das konfiguriert werden muss. Ich werde dieses Modul für meine Zwecke so lassen, weil die Lösung auf meiner openWB gut funktioniert und keinerlei Seiteneffekte auf andere Teile der openWB-SW hat. Wenn ihr den PR ablehnen wollt, ist das kein Problem, das Modul läuft ja bei mir trotzdem weiter, kann dann nur von sonst niemandem genutzt werden. |
Wenn das json-Modul für die Fahrzeuge gemergt ist, könnte das dein Modul erben (ähnlich wie bei Benning für die Geräte). |
Erledigt. |
@LKuemmel Leider funktioniert das Modul in dieser Form nicht wie erwartet. Ich verstehe aber nicht, warum. Könnt ihr mir weiterhelfen?
Diese Werte werden aber trotzdem nicht in den Gesamtstatus des Fahrzeugs (sichtbar im MQTT oder in der GUI) übernommen. soc_timestamp=0 ist hier richtig, weil ich das System auf 2.1.6 Release laufen lasse. Die ursprüngliche direkte Variante meines Moduls ohne Vererbung vom JSON-SoC-Modul hat problemlos funktioniert. Ebenso funktioniert es problemlos, wenn ich das JSON-SoC-Modul direkt verwende. Was habe ich falsch gemacht? |
Ich habe den Fehler gefunden und gefixt. Ich habe wohl in meinem Leben zu viel C gelesen und geschrieben ... |
Requests SoC from PSA Car Controller via http, SoC is calculated while charging. This approaches reduces the number of PSA API calls compared to MQTT as PSA API is only called when openWB requests SoC values rather than generating a stream of samples pushed to openWB by MQTT.
Matching .vue file PR will follow.