SW2: Einfache MQTT-Topics zum setzen des Lademodus etc

[Gero]

Wozu EEBUS-over-BSI-Box? Wenn ich nur hausintern arbeiten will in meiner eigenen offline-DMZ, sollte es auch ohne gehen.

Du musst an die Mehrzahl der Internetnutzer denken, die eine Fritzbox haben. Da gibt's keine DMZ - also konfiguriert hat die da keiner. Und da handelt man sich eventuell einen alternativen Zugang zum heimischen LAN ein. Aber Fritzboxen sind nun auch weit davon entfernt vom BSI zertifiziert zu werden.

Hach, wie war das zu Lochkartenzeiten doch noch einfach!

[openWB]

Wenn gleich amüsant, bitte ontopic bleiben und Feedback zur Simple API

[gvz]

Ich habe jetzt auf "Nein" plädiert.

M.E. ist wichtiger, dass Ihr auf Rückwärts-Kompatibilität achtet, und das bestehende MQTT-API simpel haltet - gerade für den Fall "ein Fahrzeug", "ein Ladepunkt", "ein Ladeprofil", "eine PV-Anlage", "eine Batterie".
Eine intern vergebene ID fischt sich bitte OpenWB selbst heraus.

In einem zweiten Schritt kann man überlegen, einfach für alles, was es als MQTT-Topic lesend und schreibend gibt, ein äquivalentes HTTP-Interface zu bauen - mit gleichen Namen. Damit spart man sich Dokumentation und Entwicklungsaufwände.

Beispiel:
MQTT:
openWB/set/counter/0/get/exported
openWB/set/counter/0/get/imported

HTTP:
POST https://<meine-openwb/api/counter/0/get/exported
POST https://<meine-openwb/api/counter/0/get/imported

oder:

HTTP:
POST https://<meine-openwb>/api/settings:
Body:
{
"/counter/0/get/exported": 123.2,
"/counter/0/get/imported": 123.2,
}

Wäre sogar elegant, weil man in einem Rutsch mehrere Werte setzen kann.

[schrej]

Der Thread lautet "Einfache MQTT Topics...."
Jetzt wird hier eine HTTP-API diskutiert.
Das sollte erstens in einen separaten Thread und zweitens habe ich echt keinen Bock, auch noch ein zweites Protokoll zu pflegen.
Ich finde es, ehrlich gesagt unmöglich, Breaking Changes in einer Versionsänderung in der 3. Stelle hinter dem Punkt einzuführen.
Das zeugt nicht gerade von professioneller Programmierung.
Leider wurde die ganze MQTT-Programmierung mehr und mehr "verhunzt". MQTT-Daten mit "set" und "get" in einem Topic sagen schon alles. Und das ist nur ein Punkt.
Dazu kommt noch eine nicht vorhandene Dokumentation.

Also ich bin mit viel Aufwand von 1.9. auf 2.x umgestiegen, ohne anschließend irgendeinen Mehrwert für "normale" User (ein EV, ein Anschluss) zu erkennen.
Jetzt werde ich auf der 2.1.7 bleiben solange es geht, denn die 2.1.8 macht die ganze Sache nur noch schlimmer.
Im Zweifelsfall gehe ich zurück auf 1.9.

Sorry, dass musste mal sein.
Jörg

[Gero]

Mein Verständnis ist dass die simple-API - egal ob http oder MQTT oder beides - zusätzlich zum bisherigen MQTT-Topic-Baum implementiert wird. Das wäre dann die bevorzugte API der openWB und muss dementsprechend künftig unverändert bleiben, damit bestehende Integrationen nicht ins Leere greifen. Wenn jemand den vollständigen MQTT-Baum - auch über die bereits bestehende http-API - nutzt, geht er ein erhöhtes Änderungsrisiko ein.

Ich denke, wenn der HomeAssistant vermittels der openWB-Integration über die neue simple-API zugreift, und diese dann stabil bleibt, ist für die Zukunft viel erreicht. Die meisten, die sich hier im Forum gemeldet haben, kommen ja aus dem HA.

Nachtrag: Noch eins zu MQTT vs. http: Ich hatte den Thread hier eröffnet, weil ich der Meinung bin, dass die openWB eine einfache Art der Fernsteuerung braucht. Dazu in JSON-Objekten herumzufummeln halte ich nicht für zielführend im Sinne von allgemein benutzbarer Offenheit. Ich habe damit gewartet, bis die neue Logik der ebenso häufig gewünschten "Lademodus am Ladepunkt" implementiert wurde. Wir sind in der Diskussion von MQTT nach http abgedriftet, weil der populäre HomeAssistant mit seinem nur einen MQTT-Broker eine deutliche Einschränkung hinsichtlich der MQTT-Anbindung hat. Wenn nun die simple-API - genauso wie die aktuelle - sowohl per MQTT als auch per http ansprechbar ist, wären wir doch am Ziel.

[openWB]

M.E. ist wichtiger, dass Ihr auf Rückwärts-Kompatibilität achtet, und das bestehende MQTT-API simpel haltet - gerade für den Fall "ein Fahrzeug", "ein Ladepunkt", "ein Ladeprofil", "eine PV-Anlage", "eine Batterie".
Eine intern vergebene ID fischt sich bitte OpenWB selbst heraus.

Das wäre aber nur zutreffend wenn sichergestellt ist das es nur einen Ladepunkt gibt.
Kommt ein zweiter Ladepunkt dazu (oder ist schon da) würde das ja alles zerhauen.

In einem zweiten Schritt kann man überlegen, einfach für alles, was es als MQTT-Topic lesend und schreibend gibt, ein äquivalentes HTTP-Interface zu bauen - mit gleichen Namen. Damit spart man sich Dokumentation und Entwicklungsaufwände.

Das gibt es ja jetzt schon. Die implementierte HTTP API übersetzt 1:1 MQTT zu HTTP, siehe:
https://openwb.de/main/wp-content/uploa ... eries2.pdf

Der Thread lautet "Einfache MQTT Topics...."
Jetzt wird hier eine HTTP-API diskutiert.

Das ergab sich im Verlauf. Es liest ja heraus, und war in der Vergangenheit oft Thema, das u.a. mit HomeAssistant MQTT nicht trivial ist und viele überfordert. Der "einfachste" Nenner ist daher HTTP.

Das sollte erstens in einen separaten Thread und zweitens habe ich echt keinen Bock, auch noch ein zweites Protokoll zu pflegen.

Hier geht es primär um "simple", daher passt das schon hier rein.

Also ich bin mit viel Aufwand von 1.9. auf 2.x umgestiegen, ohne anschließend irgendeinen Mehrwert für "normale" User (ein EV, ein Anschluss) zu erkennen.
Jetzt werde ich auf der 2.1.7 bleiben solange es geht, denn die 2.1.8 macht die ganze Sache nur noch schlimmer.
Im Zweifelsfall gehe ich zurück auf 1.9.

Danke für das Feedback
Die simple API ist dazu gedacht auch künftig persistent zu sein sollten sich "interne" Topics ändern.
Daher der Wunsch von uns das Ihr euch mit einbringen könnt und sollt.

@gero
Gut zusammen gefasst. Das ganze zu spiegeln ist natürlich eine Option. Primär ist erstmal HTTP angedacht, schlicht eben wegen HA.

[gvz]

M.E. ist wichtiger, dass Ihr auf Rückwärts-Kompatibilität achtet, und das bestehende MQTT-API simpel haltet - gerade für den Fall "ein Fahrzeug", "ein Ladepunkt", "ein Ladeprofil", "eine PV-Anlage", "eine Batterie".
Eine intern vergebene ID fischt sich bitte OpenWB selbst heraus.

Das wäre aber nur zutreffend wenn sichergestellt ist das es nur einen Ladepunkt gibt.
Kommt ein zweiter Ladepunkt dazu (oder ist schon da) würde das ja alles zerhauen.

Dafür habe ich ja einen Lösungsansatz beschrieben:
- Man hängt OPTIONAL mit einem Trenner wie "/" abgegrenzt die Nummer des LP etc. an.
- Oder hinter counter/ etc. *kann* eine Nummer stehen, muss aber nicht:

openWB/config/set/sofort/lp/socToChargeTo = erster Ladepunkt
openWB/config/set/sofort/lp/1/socToChargeTo = Ladepunkt ID 1.

In einem zweiten Schritt kann man überlegen, einfach für alles, was es als MQTT-Topic lesend und schreibend gibt, ein äquivalentes HTTP-Interface zu bauen - mit gleichen Namen. Damit spart man sich Dokumentation und Entwicklungsaufwände.

Das gibt es ja jetzt schon. Die implementierte HTTP API übersetzt 1:1 MQTT zu HTTP, siehe:
https://openwb.de/main/wp-content/uploa ... eries2.pdf

Kannte ich nicht, finde ich im Prinzip gut, "riecht" aber zu sehr nach MQTT und zu wenig nach REST.
MQTT-Schreibfehler z.B. gehören in den HTTP-Status, das Topic m.E. in die URL statt in den Querystring.

Z.B. mit Beispiel 1 aus der Doku:

Code: Alles auswählen

GET-Request: https://192.168.1.25:8443/v1/?topic=openWB/internal_chargepoint/0/get/plug_state
{
 "status": "success",
 "topic": „openWB/internal_chargepoint/0/get/plug_state“,
 "message": false
}

Stattdessen:

Code: Alles auswählen

GET-Request: https://192.168.1.25:8443/api/internal_chargepoint/0/get/plug_state
{
 "plug_state“: "false"
}

Und

Code: Alles auswählen

GET-Request: https://192.168.1.25:8443/api/internal_chargepoint/0/get/

macht eine Abfrage: 'openWB/internal_chargepoint/0/get/#'
und liefert:

Code: Alles auswählen

{
 "fault_str": "Kein Fehler",
 "fault_state": 0, 
 "error_timestamp": 0,
 ...
}

[openWB]

Dafür habe ich ja einen Lösungsansatz beschrieben:
- Man hängt OPTIONAL mit einem Trenner wie "/" abgegrenzt die Nummer des LP etc. an.
- Oder hinter counter/ etc. *kann* eine Nummer stehen, muss aber nicht:

openWB/config/set/sofort/lp/socToChargeTo = erster Ladepunkt
openWB/config/set/sofort/lp/1/socToChargeTo = Ladepunkt ID 1.

Denkbar wäre den first match zu nehmen. Ob ich das gut finde weiß ich aber nicht.
Wie sieht der Rest das?
Auf den Entwurf betrachtet könnte man die angäbe der ID optional machen.

Kannte ich nicht, finde ich im Prinzip gut, "riecht" aber zu sehr nach MQTT und zu wenig nach REST.
MQTT-Schreibfehler z.B. gehören in den HTTP-Status, das Topic m.E. in die URL statt in den Querystring.

Die HTTP API (nicht simple) ist hier nicht Thema. Die gibt es schon seit Release 2.1.5 von 08/24. Wenn du dazu Feedback hast bitte einen extra Thread aufmachen. Änderungen an der dortigen v1 wird es aber nicht geben. Wenn berechtigt dann ggf. eine v2. Diese hat auch "nur" die Funktion das vorhanden MQTT auf HTTP 1:1 zu übersetzen

[rocko]

Ich bin erst einmal auf die 2.1.7. zurück. Mir ist die Integration in HA sehr wichtig.

[ChristophR]

Wir nutzen beim WiCAN OBD2-Dongle und beim SoC-Helper von zut das manuelle SoC-Modul, schreiben aber trotzdem per MQTT den aktuellen SoC in die openWB.
Dafür haben wir bisher in das Topic:
openWB/set/vehicle/x/soc_module/calculated_soc_state
unter manual_soc nur den aktuellen SoC-Wert geschrieben.
s. https://github.com/openWB/core/wiki/WiCAN
Auf den neuen Topics (openWB/set/mqtt/vehicle...) funktioniert das nicht mehr.
Ist das auch etwas für diesen Thread oder eher als Problem in der 2.1.9 Alpha zu melden, wenn die eröffnet ist?