SW2: Einfache MQTT-Topics zum setzen des Lademodus etc

[markus397]

Habe den Chargemode immer per IoBroker mit mqtt gelesen und gesetzt. So konnte ich immer schön PV Laden zu den Zeiten wo ich wollte. Das vermisse ich sehr.

[openWB]

Habe den Chargemode immer per IoBroker mit mqtt gelesen und gesetzt. So konnte ich immer schön PV Laden zu den Zeiten wo ich wollte. Das vermisse ich sehr.

Dafür der Thread

Eine Bitte, wenn Ihr mit Nein abstimmt dann bitte auch einen Post dazu weshalb. Das verfälscht sonst das Ergebnis.

[gvz]

Heute weiter etwas geärgert (ich verstehe es einfach nicht: Wer seine API ändert, verzwergt sich nicht nur als Hersteller in seiner Bedeutung für andere (OpenWB 1.9 vs. OpenWb X vs. OpenWB Y), sondern macht sich wg. offensichtlichem "Mir ist Rückwärtskompatibilität egal" auch für die Zukunft unglaubwürdig, aber andererseits habe ich bisher einen Punkt übersehen:
Bei jeder Form der API-Änderung nicht eine Rückwärtskompatibilität für aus Client-Sicht *schreibende* MQTT-Topics einzubauen: Ja, das macht man einfach nicht - zumal es so simpel ist, das (ggf. intelligente) Mapping in den OpenWB-MQTT-Client einzubauen. Aber: I.S. des *lesenden* Client-Zugriffs ist Rückwärtskompatibilität natürlich schwerer: Ich muss bei einer Umgestaltung der Topics rein auf Verdacht "Legacy-Topics" schreiben - nicht wissend, ob ich den Overhead sinnvoll leiste oder nicht. Da verstehe ich die Änderungsfreude schon eher.

Andererseits: HTTP ist m.E. auch einfach ggü. MQTT das schlechtere Protokoll. Mein Energie-Logging: Okay, da kann ich alle 5-Minuten pollen. Aber MQTT ist eben ein bidirektionales Protokoll, was HTTP erst mit Websockets erreicht. "Fahrzeug eingesteckt"-Event? Ggf. §14a-Manager? Oder wieder SmartHome mal angehen? Alles Events, für die Intervall-Pollen eine blöde Lösung ist. Mir missfällt auch die Aussage "MQTT ist Frontend/Backend". Meine Alexa-Integration ist auch ein Frontend, oder der Schalter X im Smarthome-System, whatever. Außerdem: "Wie kann ich X setzen?": Dafür habe ich nicht Doku gesucht (man weiß ja im Zweifelsfall auch nicht: Auf welche Version bezieht sie sich?), sondern MQTT mitgeschnitten, während ich am Frontend einen Wert eingestellt habe.

In diesem Sinne noch einmal der Appell: Erfindet kein HTTP-Api und blast den Dokuaufwand hoch! Sondern haltet die MQTT-Topics stabil und einfach - und gerne dann ein selbstdokumentierendes, weil MQTT-analoges, HTTP-Interface (das wie oben vorgeschlagen durch Abfrage eines MQTT-Topic-Baums dann ein längeres JSON-Objekt mit vielen Variablen zurückliefert).

[openWB]

Heute weiter etwas geärgert (ich verstehe es einfach nicht: Wer seine API ändert, verzwergt sich nicht nur als Hersteller in seiner Bedeutung für andere (OpenWB 1.9 vs. OpenWb X vs. OpenWB Y), sondern macht sich wg. offensichtlichem "Mir ist Rückwärtskompatibilität egal" auch für die Zukunft unglaubwürdig, aber andererseits habe ich bisher einen Punkt übersehen:

SW 2.x ist im Gegensatz zu 1.9 eine komplette Neuentwicklung.
Es gab kein einfaches Update und es war nie vorgesehen das eine API kompatibel ist noch wäre das aufgrund der Funktionen möglich gewesen.

Andererseits: HTTP ist m.E. auch einfach ggü. MQTT das schlechtere Protokoll.

Das kommt immer auf den Use Case an.
Ein großer Use Case ist die Anbindung an HA. Hier ist das aufgrund der bedeutend einfachereren Config die beste Wahl ohne einen Nachteil zu haben.

Mir missfällt auch die Aussage "MQTT ist Frontend/Backend".

Da habe ich mich wohl unglücklich ausgedrückt. Das ist einer unserer Use Cases für MQTT der auch nicht geändert wird.

In diesem Sinne noch einmal der Appell: Erfindet kein HTTP-Api und blast den Dokuaufwand hoch! Sondern haltet die MQTT-Topics stabil und einfach - und gerne dann ein selbstdokumentierendes

Die interne Struktur wird nicht angefasst. Gerne aber möchten wir dem Wunsch der Community nachkommen die Hürde des Zugangs runterzusetzen und diese zeitgleich stabil halten auch wenn sich die interne Struktur ändert.

Hier nochmal mein Appell, konstruktive Vorschläge mit einzubringen.

[Gero]

Ehrlich gesagt, war ich auch ein bisschen überrascht, dass die Änderung des Ladepunktverhaltens so einfach ohne extra-große Ankündigung gemacht wurde. Mir war nach meiner (notwendig gewordenen) Anleitung zur Ladepunktsteuerung klar, dass es viele gibt, die fernsteuern. Und wenn man das ändert, wirbelt das viel Staub auf.

Umso mehr begrüße ich den aktuellen Ansatz, der sich insbesondere an die HA-Integration richtet. Die hat ja in der Vergangenheit auch regelmäßig für Unbill gesorgt. Das Thema sollte sich mir der neuen Simple-API dann erledigt haben.

Nun noch inhaltlich:
- minimal_pv_soc würde ich umbenennen in minimal_Ev_soc, damit man den auch später mal für eco implementieren kann. Da macht er ja auch Sinn, weil nicht sofort losgeladen wird.
- und nochmal den Hinweis auf den Mindest_soc der Hausbatterie, damit man mit Wetterprognosen oder eigenen Kalenderplanungen sinnvoll spielen kann.

[gvz]

Hier nochmal mein Appell, konstruktive Vorschläge mit einzubringen.

HA ist m.E. #1, aber da besteht ja Kontakt. Ich versuche, zunächst die allgemeinen Usecases zu sammeln:
- OpenWB als führendes System
OpenWB ist das Hardware-Interface zu Zähler, PV & Speicher, z.B. weil ein Elektriker es so integriert hat, und ein anderes Smarthome-System später kommt. Dann möchte ich einfach und unter Standard-URLs (ohne vergebene IDs):
- Die div. Energieflüsse (PV / Zähler / WB / Speicher) abrufen (m.E. ist da MQTT als "Push-Protokoll" überlegen)
Integriert OpenWB z.B. die PV-Erzeugung aus mehreren Anlagen, hätte ich primär gerne trotzdem insbes. die Gesamtzahl.
- Den SoC des Speichers
- ... sowie Steuermöglichkeiten (dazu im nächsten Punkt)

- OpenWB als Lademanager
OpenWB soll seine raffinierten Lademöglichkeiten ausspielen, ist aber nur Datenempfänger der Energieflüsse. So ist auch mein Haus-Setup: Am Anfang war FHEM, und hat alle Daten. Ein anderer Usecase wäre vielleicht: "HA oder Clever-PV hat die Daten". Ich möchte also PV/Grid/Speicher-Infos in die OpenWB "schieben". Gegenwärtig kennt OpenWB nur HTTP-Poll. Eine HTTP-Api sollte m.E. auch "HTTP-Push" (OpenWB ist HTTP-Server) ermöglichen.
Auch hier bietet sich wg. der Messfrequenz m.E. eher MQTT an - aber der Systematik wegen sollte die Energiefluss-Einspeisung nach OpenWB auch per HTTP möglich sein.
Daneben möchte ich:
- Lademodi setzen
- Parameter des Laden (Anzahl Phasen, A-stärke setzen)
- Ich setze bei mir über den Tag den Mindest-SOC und die Reserveleistung für den Akku (Bis 11 Uhr will ich 40% haben, ab 14 Uhr ist 80% der Ziel-SOC, die Reserveleistung setze ich zwischen 1300 und 2400W je nach "Im Zeitplan".

- OpenWB als "dumme" WB
Ich habe vielleicht EOS von Akkudoktor oder EVCC am Laufen, und OpenWB soll nur tun, "was 'ich' sage":
- Lademodi & Parameter setzen.
Hatten wir oben schon, aber hier eine Besonderheit: M.E. wäre eine Art "Force" sinnvoll. Angenommen: Ich habe mal wieder viel zu viel eingestellt: "Laden bis Max.-SOC x, Energie-Menge Y" u.s.w. Es wäre m.E. sinnvoll, dass dieses "Setzen des Lademodus" - falls es noch Constraints bei "Sofort" etc. gibt - sowohl i.S.v. "force=false" (behalte Deine Constraints) oder "force=true" (ignoriere alle Contraints außer Schieflast / §14a) ginge.

Konkretes Beispiel:
Ich habe eine Integration von OpenWB 1.9 für Victron geschrieben (https://github.com/gvzdus/dbus-mqtt-openwb ). Damit das bei jedem auf Anhieb läuft (außer, die IP-Adresse der OpenWB in der config.ini einzutragen), benötigte ich:
- zum Schreiben: openWB/set/ChargeMode & openWB/config/set/sofort/lp1/current
- zum Lesen:
- /ChargingTime,
- VPhase, APhase, W (Spannung, Strom, Leistung)
- kWhDailyCharged
- ChargeStatus, boolPlugStat (angestöpselt), AConfigured (Soll-Ampere), ChargeMode
Wie viele das nutzen, weiß ich nicht. Aber die meisten wäre vermutlich völlig zufrieden, wenn einfach nur die erste von eventuell mehreren Ladebuchsen funktioniert.

[openWB]

HA ist m.E. #1, aber da besteht ja Kontakt. Ich versuche, zunächst die allgemeinen Usecases zu sammeln:
- OpenWB als führendes System
OpenWB ist das Hardware-Interface zu Zähler, PV & Speicher, z.B. weil ein Elektriker es so integriert hat, und ein anderes Smarthome-System später kommt. Dann möchte ich einfach und unter Standard-URLs (ohne vergebene IDs):
- Die div. Energieflüsse (PV / Zähler / WB / Speicher) abrufen (m.E. ist da MQTT als "Push-Protokoll" überlegen)
Integriert OpenWB z.B. die PV-Erzeugung aus mehreren Anlagen, hätte ich primär gerne trotzdem insbes. die Gesamtzahl.
- Den SoC des Speichers
- ... sowie Steuermöglichkeiten (dazu im nächsten Punkt)

Heißt schlicht aggregierte Werte "je Gruppe"?

- OpenWB als Lademanager
OpenWB soll seine raffinierten Lademöglichkeiten ausspielen, ist aber nur Datenempfänger der Energieflüsse. So ist auch mein Haus-Setup: Am Anfang war FHEM, und hat alle Daten. Ein anderer Usecase wäre vielleicht: "HA oder Clever-PV hat die Daten". Ich möchte also PV/Grid/Speicher-Infos in die OpenWB "schieben". Gegenwärtig kennt OpenWB nur HTTP-Poll. Eine HTTP-Api sollte m.E. auch "HTTP-Push" (OpenWB ist HTTP-Server) ermöglichen.
Auch hier bietet sich wg. der Messfrequenz m.E. eher MQTT an - aber der Systematik wegen sollte die Energiefluss-Einspeisung nach OpenWB auch per HTTP möglich sein.

In meinen Augen können wir diesen Fall in Bezug auf Simple API komplett ausklammern. Für PV/Speicher/EVU(Zähler) gibt es generische HTTP/JSON/MQTT Module. Hierüber kommen Daten von extern zur openWB rein.

- Lademodi setzen
- Parameter des Laden (Anzahl Phasen, A-stärke setzen)
- Ich setze bei mir über den Tag den Mindest-SOC und die Reserveleistung für den Akku (Bis 11 Uhr will ich 40% haben, ab 14 Uhr ist 80% der Ziel-SOC, die Reserveleistung setze ich zwischen 1300 und 2400W je nach "Im Zeitplan".

Wie sollte das am sinnigsten benannt werden um verständlich zu sein bzgl. des Mindest-SoC?
Lademodi und Ampere setzen ist schon vorgesehen. Anzahl Phasen könnte man mit aufnehmen. Für den Sofort Lademodus?

- OpenWB als "dumme" WB
Ich habe vielleicht EOS von Akkudoktor oder EVCC am Laufen, und OpenWB soll nur tun, "was 'ich' sage":
- Lademodi & Parameter setzen.

Dann läuft die openWB im Secondary Mode. Den Fall können wir auch ausklammern. Da gibt es schon die MQTT als auch Modbus Steuerung.

[gvz]

... OpenWB ist das Hardware-Interface zu Zähler, PV & Speicher, z.B. w...

Heißt schlicht aggregierte Werte "je Gruppe"?

Ja.

- OpenWB als Lademanager
... Eine HTTP-Api sollte m.E. auch "HTTP-Push" (OpenWB ist HTTP-Server) ermöglichen. ...

In meinen Augen können wir diesen Fall in Bezug auf Simple API komplett ausklammern. Für PV/Speicher/EVU(Zähler) gibt es generische HTTP/JSON/MQTT Module. Hierüber kommen Daten von extern zur openWB rein.

Das generische HTTP-Modul ist aber ein Client, kein Server. Zudem stelle ich mir den "Neuling" vor, der *die* API liest, und sich fragt: "Ja, aber fangen wir mit den Basics an: Wie pumpe ich diese Daten in die OpenWB?" Es wäre jetzt unsystematisch, dann an dieser Stelle diese Kernfunktion "Energieflüsse im Haus" nicht abzubilden. Zumal es oft schwierig ist, HTTP-Kommunikation beidseitig herzustellen.

- Lademodi setzen
- Parameter des Laden (Anzahl Phasen, A-stärke setzen)
- Ich setze bei mir über den Tag den Mindest-SOC und die Reserveleistung für den Akku (Bis 11 Uhr will ich 40% haben, ab 14 Uhr ist 80% der Ziel-SOC, die Reserveleistung setze ich zwischen 1300 und 2400W je nach "Im Zeitplan".

Wie sollte das am sinnigsten benannt werden um verständlich zu sein bzgl. des Mindest-SoC?
Lademodi und Ampere setzen ist schon vorgesehen. Anzahl Phasen könnte man mit aufnehmen. Für den Sofort Lademodus?

Die Namen können Fix und Foxi heißen. Vielleicht bin ich geistig schwerfällig, aber mir fällt selbst bei 2 Sätzen in der Hilfe in der GUI unterhalb von eines Einstellwert schwer, ganz sicher zu sein, was gemeint ist. Ich stoße auf eine einstellbare Größe und überlege: "Hat da etwa jemand ähnlich gedacht wie das, was mir gerade durch den Kopf geht?". Das ist wirklich keine Kritik: Nicht umsonst werden auf Youtube Videos über ein Setting bei einem Gerät gedreht. Der Name ist wirklich egal. Meinen Kopf würde man am ehesten mit etwas wie "bat_priority_min_soc" und "bat_priority_reserve_power" erreichen.

"Anzahl Phasen" unbedingt bitte mit rein!

- OpenWB als "dumme" WB
Ich habe vielleicht EOS von Akkudoktor oder EVCC am Laufen, und OpenWB soll nur tun, "was 'ich' sage":
- Lademodi & Parameter setzen.

Dann läuft die openWB im Secondary Mode. Den Fall können wir auch ausklammern. Da gibt es schon die MQTT als auch Modbus Steuerung.

Das ist jetzt ähnlich wie oben: Wenn eine komplett neue API, dann sollte sie auch die basalen Usecases komplett abdecken (zumal ich ja hier nur das "force" vorschlage). Irgendein Integrator "dreht doch durch", wenn dieser Usecase des reinen "Kommandos" dann mit einem anderen Protokoll oder einer anderen Kommunikationsrichtung abdeckt wird.

[openWB]

Das generische HTTP-Modul ist aber ein Client, kein Server. Zudem stelle ich mir den "Neuling" vor, der *die* API liest, und sich fragt: "Ja, aber fangen wir mit den Basics an: Wie pumpe ich diese Daten in die OpenWB?" Es wäre jetzt unsystematisch, dann an dieser Stelle diese Kernfunktion "Energieflüsse im Haus" nicht abzubilden. Zumal es oft schwierig ist, HTTP-Kommunikation beidseitig herzustellen.

Die Daten kommen über Module in die openWB. Das wird schon beim Einrichtungsassistent abgefragt. Ohne konfiguriertes Modul keine Daten. Wenn dir ein (generisches) Modul fehlt gerne einen Feature Request dafür auf machen.

"Anzahl Phasen" unbedingt bitte mit rein!

Du redest hier aber von sofort laden?

Das ist jetzt ähnlich wie oben: Wenn eine komplett neue API, dann sollte sie auch die basalen Usecases komplett abdecken (zumal ich ja hier nur das "force" vorschlage). Irgendein Integrator "dreht doch durch", wenn dieser Usecase des reinen "Kommandos" dann mit einem anderen Protokoll oder einer anderen Kommunikationsrichtung abdeckt wird.

Die simple API macht eigentlich nur bei einem Master Sinn.
Ist die openWB im secondary Modus Sind PV EVU Speicher Daten usw ja ohnehin nicht vorhanden.


Die simple API soll die einfache Basisanbindung zu HA und co abdecken, nicht aber jeden erdenklichen use case oder das Rad für den secondary Modus neu erfinden. Dann kommen wir von simple nämlich ganz schnell wieder weg.

Die aggregierten Werte finde ich allerdings eine sehr gute Idee.
Man könnte auf die ID verzichten und bräuchte für eine HA Anbindung nur die IP, zumindest solange es nur einen Ladepunkt gibt.

[gvz]

Ihr werdet viel besser als ich wissen, wie Elektriker "ticken".
Meine - möglicherweise komplett falsche - Vorstellung vom Elektrikerwunsch ist, dass ein typischer Elektriker die OpenWB anschließt, vielleicht noch ein Netzwerkkabel für den Kunden fixiert, weil er gut crimpen kann, den Typ2-Stecker ins Auto steckt und feststellt, dass 11 kW fließen, ausstöpselt und von dannen zieht. ("Das mit der Software machen Sie dann, da gibt es wahnsinnig viele Möglichkeiten"). Das hieße: Auspacken, Default-Module (Zähler & PV per MQTT oder HTTP-Push - was immer rein kommt, Default-Ladeprofil 11 kW Sofort, Default-Modus Sofortladen sind voreingerichtet, nach dem ersten Boot lädt die OpenWB mit 11 kW / 22 kW, wenn man den Stecker einstöpselt.
2. Schritt: Der Kumpel, der die OpenWB empfohlen hatte, kommt rum: "Jetzt mache ich Dir das mal mit dem PV-Überschuss-Laden - ich habe nächsten Sonntag Zeit".