SW2: Einfache MQTT-Topics zum setzen des Lademodus etc

[dk.mailbox]

+1 für "Komforttopics" - oder auch: Funktionalität wie sie jahrelang einfach existiert hat, und worauf Leute ihre Home-Infrastruktur aufgebaut haben.

Bitte nicht usern einfach so (in irgendwelchen Patch-Versionen) APIs und Schnittstellen unterm Hintern wegziehen!! (die API zu lassen aber dahinter die Funktionalität grundlegend zu ändern zählt in diesen Appell mit rein)

[juli_august]

Guten Abend,

Nein, hat es nicht. Das was Du früher aus deiner Automation heraus verändert hast, wird weiterhin verändert, das ist nämlich das Ladeprofil. Eine Änderung am Ladeprofi bewirkt nun - also mit 2.18 nicht mehr eine Änderung des Lademodus am Ladepunkt.

Dafür gibt es ein neues Topic. Bitte nimm dieses statt des Ladeprofils. Wie es heißt, steht oben. Inhaltlich ist es immer noch ein Ladeprofil.

Hab es leider mit dem neuen Topic auch nicht hinbekommen. Kann aber auch definitiv an mir liegen. Oder meiner Methode.
Was nun jedoch funktioniert. Json einlesen --> manipulieren --> ausgeben.

Gruß Julian

[Gero]

Was nun jedoch funktioniert. Json einlesen --> manipulieren --> ausgeben.

Genau so habe ich es ja auch in meiner Anleitung zum setzen des Lademodus bis 2.1.8 auch gemacht. Siehe viewtopic.php?t=9171

[Gero]

und es ist auch zum Auslesen und weiterverarbeiten deutlich komplizierter geworden da man für jeden Einzelwert um ihn in seine Anwendung zu bekommen nun mit komplexen JSON Strukturen arbeiten muss. Früher konnte man einfach den payload direkt weiter verarbeiten, jetzt muss man ihn sich erstmal mühsam aus einem JSON extrahieren.

Nein, ist es nicht, das war auch vorher schon so. Nur das Ladeprofil, welches den Ladepunkt steuert ist nun am Ladepunkt und nicht mehr das in der Konfiguration. Siehe viewtopic.php?t=9171, das ist die Anleitung bis 2.1.8

[Requiem]

@openWB

Die Änderung führt bei Entwicklern leider auch zu dieser Reaktion: https://github.com/a529987659852/openwb ... 3370727719

Als nicht-Programmierer bin ich halt auf Plugins angewiesen. Die Changenotes haben mich auch nicht vermuten lassen, dass es ein Problem geben könnte....

[openWB]

Ja, da müssen (werden) wir was machen.

Ich frag dann einfach mal, wie sieht denn die Wunsch API aus?
MQTT?
JSON?
über http oder https?
Muss diese über die Cloud auch erreichbar sein?

[BJ Axel]

Mein Favorit: stabile HTTP / HTTPS-API

[openWB]

gerne präziser, analog hierzu:
https://openwb.de/main/wp-content/uploa ... eries2.pdf

oder eher mit GET / POST und values wie topic / message?

[gernot_gernot]

Bin selbst kein Entwickler und kein MQTT Experte, nutze aber das HA Plugin von https://github.com/a529987659852/openwb2mqtt sowie schreibe den SOC direkt per MQTT über HA an die OpenWB.

Da vom obigen Home Assistant Plugin bereits MQTT verwendet wird plädiere ich für weiterhin MQTT.
Erreichbarkeit über die Cloud benötige ich persönlich nicht;

Für den SOC und die Range nutze ich folgende Topics (die aber ja weiterhin zu funktionieren scheinen)
"openWB/vehicle/0/get/soc"
"openWB/set/vehicle/0/get/range"

Essentiell finde ich:
- Charge Mode (ist glaube ich openWB/set/vehicle/template/charge_template/0/chargemode/selected)

Sehr angenehm und sinnvoll wären:

Profil PV:
- Minimaler Dauerstrom
- Begrenzung (AUS, EV-SOC, Energie)
- SOC-Limit für das Fahrzeug
- Mindest-SOC für das Fahrzeug
- Mindest-SOC Strom

Profil Sofort:
- Sollstrom
- Begrenzung
- SOC Limit für das Fahrzeug

Hier eine Doku des oben angeführten HA Plugins:
https://github.com/a529987659852/openwb ... Topics.txt

Wenn die alle wieder gehen wäre das schon super!

[a4320909533]

oder eher mit GET / POST und values wie topic / message?

Hi zusammen,
aus meiner Sicht wären saubere GET/POST API-Endpunkte am einfachsten.
Beim Programmieren meiner openWB-Integration (https://github.com/a529987659852/openwb2mqtt) für Home Assistant hab ich mir wegen MQTT doch eher "die Finger wund programmiert", da dies deutlich aufwendiger und schwieriger ist als einen einfachen API-Call zum Lesen/Schreiben aus HA zu machen.
Zudem gibt es immerwieder Fragen/Probleme/Schwierigkeiten bei den Usern bzgl. MQTT-Server. Die Problematik ist, dass openWB einen eigenen MQTT-Server hat und viele User einen zweiten, auf dem sie ihre übrige IoT-Infrastruktur laufen lassen. Da HA nur einen MQTT-Server ansprechen kann, muss man immer vom einen auf den anderen MQTT-Server auf Nachrichten subskribieren bzw. dorthin pushen.
Eine weitere (spezielle) MQTT-Problematik, die insbesondere beim letzten Update von openWB aufgetaucht ist, ist dass man teilweise dynamisch auf MQTT-Topics subscribieren muss (z.B. Details des Sofortlademodus, da die Werte nicht mehr am Ladepunkt, sondern an irgendeinem Profil hängen - an Details kann ich mich jetzt nicht mehr erinnern).

Das alles gäbe es mit sauber dokumentierten und nach außen stabilen HTTP-APIs nicht mehr.

Bitte beachtet, dass das die genannte Datei
https://github.com/a529987659852/openwb ... Topics.txt nicht zwangsläufig aktuell ist. Es kann sein, dass ich das ein- oder andere Thema vergessen habe.

Eine offizielle HA-Integration von openWB begrüße ich natürlich sehr! Ich gebe nur zu bedenken, dass HA auch relativ "dynamisch" programmiert und dort öfter mal Änderungen an Integrationen erforderlich sind, die aus Architekturänderungen bei HA resultieren. Üblicherweise hat man zwar ca. 6 Monate Zeit, diese zu implementieren - ich würde aber den Aufwand trotzdem nicht unterschätzen.

Falls ihr an einem weiteren Austausch über die HA-Integration in Vorbereitung auf euer eigenes Plugin interessiert seid --> PN.

Gruß
Andreas