openWB Forum

Bin echt gespannt, wann die 2.1.9 rauskommt und wie die API dann mit HomeAssistant tut. Das war genau der Grund, warum ich die openWB gekauft habe.

@a4320909533
und wie schalte ich die Integration im HA dann auf HTTP-api um?
irgendwie steh ich grad auf nem Schlauch

BJ Axel hat geschrieben: Sa Nov 08, 2025 2:06 pm Bin echt gespannt, wann die 2.1.9 rauskommt und wie die API dann mit HomeAssistant tut. Das war genau der Grund, warum ich die openWB gekauft habe.

Hast du kein separates Testsystem, um auf alpha / beta mitzutesten?
Aktuell habe ich die 2.1.9-Alpha.3 sogar produktiv im Einsatz (mit einer 2.1.8-Backup-SDC daneben liegend). Letztlich bekommt man die letzten bugs nur mit Live-tests raus.

Soma1975 hat geschrieben: Sa Nov 08, 2025 3:03 pm @a4320909533
und wie schalte ich die Integration im HA dann auf HTTP-api um?
irgendwie steh ich grad auf nem Schlauch

Device entfernen. Gleichen Device wieder einrichten. Nur diesmal mit API statt MQTT

Gero hat geschrieben: Do Nov 06, 2025 5:52 pm Hier sucht jemand den eingestellten Mindeststrom. Schreibend ist er drin, lesend fehlt er.

viewtopic.php?p=135575#p135575

ja, genau darüber bin ich heute auch beim Testen der neuen API Struktur gestolpert. Im lesbaren topic:

openWB/simpleAPI/chargepoint/4/set/charge_template/chargemode/pv_charging/min_current

ändert sich leider nix bei mir, vermutlich weil das das persistente Charge_template ist. Aber die nicht persistente temporäre Änderung die auch korrekt umgesetzt wird (im webinterface und es wird auch mit min Strom geladen) finde ich in der simpleAPI nirgendwo, brauche sie aber als Status für die externe Steuerung um den minPV Modus auch wieder sauber beenden zu können. Oder ist das wirklich so gedacht und auch sichergestellt daß auch immer der aktuelle Status (egal ob über Webinterface oder externe Steuerung) immer auch das SET topic

openWB/simpleAPI/set/chargepoint/4/minimal_permanent_current

den aktuellen Status beinhaltet? Wäre zumindest ein Logikbruch im get/set Konzept...

Wahrscheinlich gilt selbes Verhalten auch noch für weitere set topics, es sollte aber für jedes Set topic auch ein korrektes (temporäres) Statustopic geben. Habe das aber nicht alles durchgetestet vermutlich aber relevant für die ganzen topics des Chargeprofils (ECO Preis, instant limits,...)?!

Ansonsten vielen Dank für die nun deutlich schlankere und übersichtlichere SimpleAPI. Ich hätte sie noch weiter verschlankt und zumindest die GET/SET Pfade für den "ersten Ladepunkt" auch in eine Passende Unterstruktur (z.B. "Default") wie die Einzel ID Chargepoints gepackt. Oder noch besser: ganz weggelassen da diese 100% redundant zu dem Ladepunkt mit der niedrigsten ID sind und in der SW dann intern handeln (wenn keine ID im topicpfad, dann muss diese mit der ersten niedrigsten intern durch die SW ergänzt werden), da das den Enduser einfach nur verwirrt wenn er doppelte Datenstrukturen vorfindet... Selbiges gilt analog für die Strukturen pv, bat, counter, das ist auch alles redundant und unnötig aus Endusersicht!

Und auch vielen Dank für den Sendefilter, da ist nun deutlich weniger traffic mit doppelten Werten und ich kann ein paar externe Vorschaltlogiken nun wieder aufräumen bzw. löschen

Von den Inhalten ist das jetzt doch recht umfangreich und es sollte erstmal nichts grundsätzlich wichtiges fehlen, TOP!

ganz weggelassen da diese 100% redundant zu dem Ladepunkt mit der niedrigsten ID sind und in der SW dann intern handeln (wenn keine ID im topicpfad, dann muss diese mit der ersten niedrigsten intern durch die SW ergänzt werden), da das den Enduser einfach nur verwirrt wenn er doppelte Datenstrukturen vorfindet... Selbiges gilt analog für die Strukturen pv, bat, counter, das ist auch alles redundant und unnötig aus Endusersicht!

Hier kann ich dir nicht folgen.
Wenn es jeweils mehr als eins gibt willst die IDs unbedingt haben. Davor ist es optional.

Andi hat geschrieben: Sa Nov 08, 2025 6:57 pm Oder ist das wirklich so gedacht und auch sichergestellt daß auch immer der aktuelle Status (egal ob über Webinterface oder externe Steuerung) immer auch das SET topic

openWB/simpleAPI/set/chargepoint/4/minimal_permanent_current

den aktuellen Status beinhaltet? Wäre zumindest ein Logikbruch im get/set Konzept...

Eben noch getestet ob das als Workaround taugen würde: NEIN, wenn man über webinterface den Mindeststrom setzt wird auf diesem set topic weiter der alte und dann falsche Status angezeigt, es braucht also noch ein aktuell fehlendes Statustopic das konsistent immer den aktuellen Zustand anzeigt.

a4320909533 hat geschrieben: Sa Nov 08, 2025 4:26 pm

Soma1975 hat geschrieben: Sa Nov 08, 2025 3:03 pm @a4320909533
und wie schalte ich die Integration im HA dann auf HTTP-api um?
irgendwie steh ich grad auf nem Schlauch

Device entfernen. Gleichen Device wieder einrichten. Nur diesmal mit API statt MQTT

habe nur diese Möglichkeit beim Device-einrichten:


naja egal, möchte den Thread als Support-Thread missbrauchen
Wenn jemand mag gerne Unterstützung per PN
Danke!

openWB hat geschrieben: Sa Nov 08, 2025 7:02 pm Hier kann ich dir nicht folgen.
Wenn es jeweils mehr als eins gibt willst die IDs unbedingt haben. Davor ist es optional.

Betrachte es anders rum: Wenn jemand mehr wie ein Ladepunkt hat, bekommt er leider immer einen Ladespunkt mehr angezeigt und hat diese unnötige Zwischenstruktur mit get/set über den eigentlichen Ladepunkten und muss erstmal drauf kommen daß diese get und set Struktur im Prinzip dieselben Infos wie die niedrigste ID Unterstruktur enthält. Das verwirrt m.E. ungemein.

Und ich weiss auch nicht wie es ist mit nur einem Ladepunkt?! Gibt es da dann gar keine Struktur mit einer ID oder auch die get/set auf Hauptebene und zusätzlich mit ID? Ersteres wäre für diesen Fall zumindest eine nachvollziehbare, cleane Struktur. Zweiteres dann maximal verwirrend: Welchen Pfad nimmt man jetzt? Gibt es da vielleicht doch Unterschiede? Mist muss ich mal durchschauen... Ah doch kein Unterschied und einfach nur doppelte Infos! Wer denkt sich so was aus?!

Ich würde aus SW Architektursicht aber bei mehr wie einem Ladepunkt immer zwingend eine ID vorschreiben um eine eindeutige Ladepunktzuordnung zu gewährleisten und dann die get/set auf der Hauptebene gar nicht mehr ausgeben/anbieten. Oder wenn zwingend ohne ID ein Pfad für Einezlladepunktkonfig gewünscht wird würde ich SW intern eine "master" default Struktur anlegen:

chargepoint
> master
>> get
>> set
> 1
>> get
>> set
> 2
>> get
>> set
> 3
>> get
>> set

und die voltages und frequency im chargepoint Level sind auch aktuell komplett fehl am Platz und gehören da raus da sie ja eh schon im jeweiligen get Pfad drin sind.

Es wären dann in der Hauptstruktur nur noch master und ggf. weitere Ladepunkt IDs auf der Hauptebene siehe oben! Gleiches wie gesagt auch für pv, bat, counter, etc... Dann wäre das eine runde, einfache Sache.

und wenn ich mir das Gesamtbild ansehe würde ich gleich noch einen Schritt weiter gehen um den Supportaufwand und auch Pflegeaufwand in der Entwicklung weiter zu reduzieren:

Ich würde nur noch die neue simpleAPI Standardmäßig ausgeben, die interne Struktur würde ich nur in einem in den Einstellungen optional konfigurierbaren MQTT Expertenmodus freischalten mit dem Hinweis daß diese Struktur ggf während der Entwicklung sich ändern kann und auch Risiken bei falscher Anwendung von z.B. Schreibbefehlen existieren, Supportausschluss, ...!

Dann hat ein Otto Normaluser eine extrem übersichtliche, einfache Struktur wenn er sich das z.B. im MQTT Explorer anschaut und findet ziemlich schnell was er sucht/braucht und ihr müsst auch nur diese Struktur nach aussen warten, stabil halten, dokumentieren, etc. und habt in der Entwicklung für die internen komplexeren Strukturen freiere Hand ohne murren von ein paar nerds wie mir die sich da alles mögliche ziehen und nutzen und sich dann bei Änderungen beschweren