SW2: Einfache MQTT-Topics zum setzen des Lademodus etc

[Gero]

Gerade beim letzten Parameter würde ich es sehr viel deulticher machen, dass es eine globale Einstellung und keine der Ladepunkte ist.

Solar_Charging: ev_first, battery|home_first, custom

Und dann muss natürlich noch custom einstellbar sein. Zumindest mal der SoC.

Ich verstehe sehr gut, dass eine http-API gerade im Hinblick auf den HomeAssitant Vorteile gegenüber MQTT und seiner Implemetierung im HA bietet. Ich fänd‘ es aber trotzdem schön, wenn das alles auch per MQTT ginge.

[openWB]

Gerade beim letzten Parameter würde ich es sehr viel deulticher machen, dass es eine globale Einstellung und keine der Ladepunkte ist.

erledigt

Den Namensvorschlag finde ich allerdings unklar.

Und dann muss natürlich noch custom einstellbar sein. Zumindest mal der SoC.

SoC von was?

Ich verstehe sehr gut, dass eine http-API gerade im Hinblick auf den HomeAssitant Vorteile gegenüber MQTT und seiner Implemetierung im HA bietet. Ich fänd‘ es aber trotzdem schön, wenn das alles auch per MQTT ginge.

Irgendeinen Nenner sollten wir nun schon finden. MQTT ist für viele doch eine Hürde.
Welcher Anwednungsfall kann nur MQTT und kein HTTP?
Und welcher davon kann dann nicht direkt schon per MQTT bedient werden?

[gvz]

Erst mal Danke für das "Nachdenken am Wochenende"!
Zum Glück als frisch gebackener 2.x-Umsteiger von 1.9 im zweiten Anlauf fehlt mir in der Tat das "Simpel-API". Meine liebevoll gestrickte Alexa-Integration über FHEM geht nicht mehr ("Alexa, schalte Sofortladen auf 8%" (% = Ampere)) u.s.w., und in FHEM macht JSON-lesen/editieren/rücksenden keinen Spaß.
MQTT oder HTTP ist mir egal, daher eine völlig verrückte Idee:
Wie wäre es, wenn einfach die alten MQTT-Befehle von der 1.9 gingen? ("openWB/set/ChargeMode 0")

Meine Zufallsstichprobe jüngst auf X waren 2 "1.9 OpenWBler" (man erkennt sich ja am Color-Theme als OpenWBler) und 0 "2.1 OpenWBler".

Wenn's aber HTTP sein soll: Die go-e-Charger haben ein sehr hässliches, aber eben existierendes HTTP-API. Das hätte den Charme, dass man vielleicht mit bestehenden Adaptern für die go-e WBs für verschiedene HA-Systeme schon eine Anbindung hat. Der Nachteil wäre allerdings: Die Anzahl der "API-Keys" (= Topics / Register / Settings) bei go-e ist elend hoch, die Dokumentation schlecht: Es wäre also schwer herauszufinden:
a) Wie es denn wirklich gemeint ist?
b) Was an "Registern" zu implementieren ist, damit ein bereits real existierender Client X läuft.

Die go-e API findet man hier: https://github.com/goecharger/go-eCharger-API-v2/, bzw die "Register" hier:
https://github.com/goecharger/go-eCharg ... keys-en.md

Aber zusammengefasst:
- Der Vorschlag hat, was ich gerne hätte. Noch lieber wären mir die alten MQTT-Befehle
- Wenn HTTP: Hat Kompatibilität zu go-E nicht Vorteile?

Noch eine Anmerkung / Fernziel / Geschäftsidee:
Ich weiß nicht, wie "Schlacht um EEBUS auf OSS-Systemen für §14a" ausgehen wird / ausgegangen ist. Wenn ich nicht selbst meine EEBUS-Instanz als EMS hochziehen darf, dann wäre meine nächste Hoffnung natürlich, dass im System des BSI-Wahnsinns dann meine OpenWB-Hardware das staatsgeprüfte EEBUS-EMS sein darf. Falls es dazu käme, wäre OpenWB dann das EMS, über das
- Wallbox (Überraschung, ist OpenWB schon)
- Speicher (Stichwort: Speichersteuerung)
- PV (Anbindung habt Ihr teilweise schon)
- Wärmepumpe (SG-Ready über Shelly?)
liefe. Käme es dazu, würde ich eine natürlich eine API zum EMS haben wollen, die mir z.B. sagt: "Du bist jetzt gedimmt". Oder der ich sagen kann: "Lass das Auto verhungern: Die Wärmepumpe ist mir gerade wichtiger" (oder umgekehrt).

[aiole]

EEBUS läuft zunächst über die BSI-zertifizierte VNB-Steuerbox. Daran kann man dann openWB anschließen. EEBUS soll in openWB in 2025 kommen.

[Gero]

SoC von was?

Na, den von Mindest. ich drehe an dem auch ganz gerne mal rum, je nach zu erwartender Sonne oder Fahrgelüsten. Der ganze Mindest-SoC Ist aber eh nur was für Leute mit zu viel Speicher. Die mit korrekt dimensioniertem kommen bestimmt mit Prio Speicher / EV aus.

Irgendeinen Nenner sollten wir nun schon finden. MQTT ist für viele doch eine Hürde.
Welcher Anwednungsfall kann nur MQTT und kein HTTP?
Und welcher davon kann dann nicht direkt schon per MQTT bedient werden?

Ich habe dank openWB MQTT und damit nodered erst kennen und auch lieben gelernt. Ich denke, dass die Handvoll simple-API-Befehle auch als simple MQTT-Topics Sinn machen würde. Auch für Erfahrene ist so ein JSON, in dem man nur einen Wert ändern will, nicht offensichtlich.
Genauso wie ja auch alle Topics per zuschaltbarer, vollständiger http-API herausgereicht werden, könnten ja auch die vom das JSON-Objekt befreiten, simple-MQTT-Tipics parallel existieren. Vielleicht kann man ja auch die volle MQTT-API abschaltbar machen? Aber im Grunde genommen dürften ja bei einer http-Anbindung des HA die Konfigurations-Unfälle per MQTT deutlich abnehmen.

[openWB]

Na, den von Mindest.

Ist nun im Entwurf mit drinnen.

Wenn's aber HTTP sein soll: Die go-e-Charger haben ein sehr hässliches, aber eben existierendes HTTP-API.

Halte ich nichts von. Alles gibt es da ja eh nicht, heißt es müsste erweitert werden.
Dann können wir es auch gleich zugeschnitten machen und als dedizierte openWB simple API deklarieren.

Wie wäre es, wenn einfach die alten MQTT-Befehle von der 1.9 gingen? ("openWB/set/ChargeMode 0")

Das geht leider nicht. In 1.9 war der Lademodus global. In SW2 geht das je Ladepunkt (und es gibt andere).
Ist also aufjedenfall nicht kompatibel darstellbar.

Käme es dazu, würde ich eine natürlich eine API zum EMS haben wollen, die mir z.B. sagt: "Du bist jetzt gedimmt". Oder der ich sagen kann: "Lass das Auto verhungern: Die Wärmepumpe ist mir gerade wichtiger" (oder umgekehrt).

In der regulären API ist das aufjedenfall. Ob auch in dieser einfachen kann man dann noch diskutieren was der Anwendungsfall ist.

[gvz]

EEBUS läuft zunächst über die BSI.zertifizierte VNB-Steuerbox. Daran kann man dann openWB anschließen. EEBUS soll in openWB in 2025 kommen.

Soweit ist das klar. Der ganze Sinn der Steuerbox ist ja, dass sie das Gateway zur Schmuddelwelt bereitstellt, weil selbst dem BSI aufgefallen ist, dass jede Wärmepumpe mit BSI-abgenommener Software und sicherer Lieferkette ins Haus zu liefern, nicht ganz machbar ist. Also die Idee des Übergangs zur Schmuddelwelt.
Damit ist aber noch nicht die Frage geklärt, ob die Steuerbox per EEBUS jetzt mit jedem EMS reden darf, das sich im LAN per EEBUS-Discovery als EMS vorstellt, z.B. einem OpenSource-HomeAssistant-Plugin, das der Hauseigentümer installiert hat. Sprich: Gibt es wieder weitere Vorgaben, was ein EMS über EEBUS für Vorgaben an "Abgeschlossenheit" mitbringen muss?
Mein Ärger in dieser Sache ist: Wir gehen hier von einem installierten SmGW aus - es werden also 15-minütig Werte erfasst. Diese Werte können reflektieren, ob das Steuern klappt oder nicht. Der VNB darf inzwischen auch testen, ob alles funktioniert (war früher anders). Ob Dimmen über Herstellercloud ganz ohne CLS-Steuerbox für "gar keine Zusatzkosten", oder eben "halbwegs simpel" über CLS-Box und EEBUS: Die "Wir treiben die Kosten & Komplexität ins Absurde"-Fraktion scheint immer noch umtriebig.

[openWB]

Gibt es wieder weitere Vorgaben, was ein EMS über EEBUS für Vorgaben an "Abgeschlossenheit" mitbringen muss?

Jein, du solltest dir natürlich eines suchen (wie openWB) das der Pflicht der Dokumentation über die Dimmung entsprechend nachkommt.
Heartbeat und co sind hier Features die du haben willst. Ein HA Plugin hat das eher nicht.

[gvz]

Wenn's aber HTTP sein soll: Die go-e-Charger haben ein sehr hässliches, aber eben existierendes HTTP-API.

Halte ich nichts von. Alles gibt es da ja eh nicht, heißt es müsste erweitert werden.
Dann können wir es auch gleich zugeschnitten machen und als dedizierte openWB simple API deklarieren.

Okay

Ich finde das e-go-Interface potthässlich. Aber einen cleveren Move haben sie beim schnellen Überfliegen m.E. gemacht:
Sie bieten MODBUS/TCP, MQTT und HTTP - und mutmaßlich findet - egal, welcher Kanal - stets nur ein simples Mapping von Modbus-Register / MQTT-Topic oder "HTTP-API-Key" auf den gleichen Funktionsaufruf statt.

Wie wäre es, wenn einfach die alten MQTT-Befehle von der 1.9 gingen? ("openWB/set/ChargeMode 0")

Das geht leider nicht. In 1.9 war der Lademodus global. In SW2 geht das je Ladepunkt (und es gibt andere).
Ist also aufjedenfall nicht kompatibel darstellbar.

Natürlich "geht" das für 80% - 95% der Kunden (die Zahlen kennt Ihr natürlich besser):
Die Frage "Ja, welcher Ladepunkt denn?" ist ja in diesen 80-95% mit "Na, der EINE, den ich habe" beantwortet.
Will man mit dem gleichen MQTT-Topic mehrere Ladepunkte ansprechen, ist eben die Doku:

Code: Alles auswählen

"openWB/set/ChargeMode 0" = 1. Ladepunkt Sofortladen
"openWB/set/ChargeMode 0/<id>" = Ladepunkt mit ID <id> auf Sofortladen

... und schon ist man rückwärtskompatibel.


Ich bin sehr gespannt, was zu EEBUS / §14a kommen wird!

[BJ Axel]

Ich bin sehr gespannt, was zu EEBUS / §14a kommen wird!

Im Jahr 2045 wird mit großem medialen Getöse vom Digitalministerium eine fälschungssichere Lochkarte vorgestellt. Die Locher-Baupläne werden vom BSI veröffentlicht. Die Lochmuster widerstehen jeglichem Hackingversuch über das Internet, und wir sind der Digitalisierung einen großen Schritt weitergekommen.

Sorry, aber da fällt mir echt nichts besseres zu ein...

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