openWB Forum

Ja, ist richtig. Du hattest mich leider zitiert bevor ich meine Aussage nochmal geändert habe. Allerdings würde ich dieses Szenario per Automation lösen. Meines wissens musst Du doch sowieso das Fahrzeug am Ladepunkt auswählen? Oder kann OpenWB mittlerweile eine Fahrzeugerkennung ohne die Pro?

Wie du an meiner Signatur erkenen kannst, habe ich das Problem mit zwei Wallboxen gelöst. Hab‘ ja auch zwei Stellplätze. Es geht aber sicherlich auch anders, das passende Fahrzeug auszuwähen. Aber bei der Vielzahl an Einstellungen eine Art von „Einstellungsmonglomerat“ zu erfinden, ist doch naheliegend, oder? Es ist ja mittlerweile deutlich mehr als PV-Überschuss oder Netz, was man da einstellt.

Bitte beim Thema bleiben.

Ich freue mich auf konstruktive Kritik.
Die Simple APi ist dazu da persistent zu bleiben.

Tatsächlich hinterfrage ich den Nutzen des Zurücksetzens auf das Ladeprofil auch. Es wäre schön, wenn man das grundsätzlich ein/ausschalten könnte. (auch wenn hier offtopic)

Die aktuelle Implemetierung mit den Ladeprofilen und warum es keine gute Idee ist, im Ladepunkt-UI die Konfiguration der Ladeprofile zu überschreiben, wurde hier geführt: viewtopic.php?t=8070

Den aufwendigen Weg, wie man per nodered das komplexe JSON-Objekt handhabt, habe ich hier im Faden ganz oben als erstes veranschaulicht.

Beides kein guten Ideeen, wie ich finde. Und deshalb viewtopic.php?t=11231 gestartet, was ja so gelöst wird, dass sich die HomeAssistant-Nutzer sich ein bissl leichter tun. Diese ganze Fäden mag ich jetzt nicht mehr heraussuchen.

Sorry, aber das ist doch alles nur Symptom-Bekämpfung ohne das eigentliche Problem anzugehen. Ihr solltet in meinen Augen die Diskussion führen die Ladeprofile komplett abzuschaffen und die darin enthaltenen Einstellungen entweder dem Ladepunkt ODER dem Fahrzeug zuzuordnen. Das würde zig Probleme auf einmal lösen, die Usability erhöhen, sowie die Komplexität und Fehleranfälligkeit verringern.

Die Sinnfrage der ganzen redundanten / unnötigen Profile habe ich vor 2 Jahren schon beim ersten OpenWB 2 Release gestellt. Selbst für große Ladeparks macht das keinen Sinn, weil dort die Fahrzeuge zu 99% identisch geladen werden. Ob Ladeprofil, Fahrzeugprofil oder wie auch immer man es zum Schluss nennen mag, ist ja zweitrangig.

KLez hat geschrieben: Fr Okt 24, 2025 11:01 am Die Sinnfrage der ganzen redundanten / unnötigen Profile habe ich vor 2 Jahren schon beim ersten OpenWB 2 Release gestellt. Selbst für große Ladeparks macht das keinen Sinn, weil dort die Fahrzeuge zu 99% identisch geladen werden. Ob Ladeprofil, Fahrzeugprofil oder wie auch immer man es zum Schluss nennen mag, ist ja zweitrangig.

OT - bitte passenden thread nutzen.

Ich habe mal kurzerhand einen neuen Branch der simpleAPI erstellt der die per HTTP verfügbaren schreibbaren Befehle auch auf MQTT zur Verfügung stellt.
siehe -> https://github.com/openWB/simpleAPI/tree/simplemqtt

Trifft es diese Kombination?

Liest sich sehr gut, vollständiger wäre es aber, wenn auch die lesenden http-requests ebenfalls in MQTT vorhanden wären. So wie es sich aktuell liest, sind nur die schreibenden MQTT-Topics implementiert. Insbesondere plug_state und vehicle_connected als Startevent stelle ich mir für eine eigene Steuerung als sehr sinnvoll vor.

Und schade, dass meine Vorschläge es nicht geschafft haben realisiert zu werden. (Insbesondere vehicle_PV_soc wird bei einer Erweiterung des EV-Mindest-SoC-Features wieder zu Unbill führen oder man mant einen separaten vehile_eco_soc, der inhaltlich keinen so rechten Sinn macht)

Sehe ich das richtig, dass man altuell als Besitzer einer Kaufbox zum ausprobieren erst mal einen Raspi mit openWB aufsetzen muss, auf dem man dann die simpleAPI zusätzlich installiert? Ich denke aber mal, dass das nur temporär ist und man später die simple-API im master finden wird.

Und schade, dass meine Vorschläge es nicht geschafft haben realisiert zu werden. (Insbesondere vehicle_PV_soc wird bei einer Erweiterung des EV-Mindest-SoC-Features wieder zu Unbill führen oder man mant einen separaten vehile_eco_soc, der inhaltlich keinen so rechten Sinn macht)

Wenn ich dich richtig verstanden habe wäre das dann aber ein Wert der in unterschiedlichen Lademodi gelten soll, anstatt den dedizierten Wert zu haben?

Liest sich sehr gut, vollständiger wäre es aber, wenn auch die lesenden http-requests ebenfalls in MQTT vorhanden wären.

Das Json oder einzelwerte?

Sehe ich das richtig, dass man altuell als Besitzer einer Kaufbox zum ausprobieren erst mal einen Raspi mit openWB aufsetzen muss, auf dem man dann die simpleAPI zusätzlich installiert?

Stand aktuell, ja.

Ich denke aber mal, dass das nur temporär ist und man später die simple-API im master finden wird.

Das ist der Plan wenn Konsens herrscht.