EHZ Daten von FHEM per MQTT zu Victron VenusOS ??

[FHEMGerd]

Hallo,

ich beschreib mal die Aufgabe, später dann meine konkrete Frage bzw. mein aktuelles Problem:

Ich möchte eine bestehende PV Anlage (Überschusseinspeisung) um eine DIY Batterie erweitern. Sie soll AC-gekoppelt mit einem Victron Multiplus II (kurz MP2 = Ladegerät+WR) geladen werden. Ist wohl so eine Lösung bei der viele landen. Der MP2 muss die Leistung am Einspeisepunkt kennen, damit er weiß, ob grade Überschuss da ist (also die Batterie geladen werden kann) oder grade Leistung aus dem Netz bezogen wird (also die Batterie entladen werden soll). Mehrere Victron Komponenten kann man wohl mit einem raspi mit VenusOS (so eine Art Steuerzentrale) monitoren und steuern. Dieses VenusOS braucht also die Info bzgl. Leistung am Einspeisepunkt und steuert entsprechend den MP2. Victron verkauft zur Leistungsmessung ein sog. EM24 (Energy Meter), welches soweit ich es verstehe per proprietärem Protokoll angebunden wird.

Allerdings kenne ich (bzw. mein FHEM) bereits die Leistung am Einspeisepunkt, mein EHZ ist per IR Lesekopf und OBIS Modul angebunden. Ich würde also die Anschaffung dieses EM24 (kostet immerhin zwischen 250-350 Euro, braucht Platz in der Verteilung, der ist knapp und außerdem ist das Ding schlecht lieferbar) gerne vermeiden. Es gibt auch pfiffige Leute, die per python Skript VenusOS die notwendigen Daten so "unterjubeln" als ob sie von einem "Meter" kommen. Mein Problem dabei: das Skript erwartet die Daten von einem MQTT Server (der sie wohl wie man sagt publishen muss).

Jetzt ist mein FHEM schon MQTT Server (MQTT2_SERVER), allerdings habe ich das nie so im Detail durchdrungen. Ich nutze den MQTT Server eigentlich nur so, dass er die Daten von einigen tasmotisierten Sonoff S20 bzw. Teckin SP22 einsammelt bzw. diese ansteuert. Die Geräte wurden per autocreate angelegt (glaube ich, ist schon lange her). Ich habe wenige notifys und doifs, die z. B. eine S20 einschalten, wenn die PV Anlage Leistung bringt. Das geht ja per ganz "normalem" set befehl.

Wie kriege ich jetzt den MQTT Server dazu, Daten, die von einem nicht MQTT Gerät (dem EHZ eben) stammen, per MQTT zu publishen ? Und wie ist die Nomenklatur, d. h. wie muss ich die nennen (heissen die dann topic ?), damit ich sie dann entsprechend mit dem python Skript auf dem VenusOS einsammeln kann ?

Ich hab schon viel rumgelesen, evtl. hat es mit dieser MQTT_GENERIC_BRIDGE zu tun? Wie erreiche ich, dass das MQTT topic immer aktuell ist, wenn sich die EHZ Daten aktualieren ? Brauche ich dazu DOIFs oder notifys ?

Mir raucht der Kopf - vielleicht kann man mich jemand erleuchten.

Die Lösung würde mir vermutlich auch bei einem anderen Problem weiterhelfen: Meine OpenWB interessiert sich auch für die Leistung am Einspeisepunkt. Für die Funktion PV geführtes Laden. Und die nimmt die Daten auch von einem MQTT Server.

Danke und Grüße, Gerd

[rudolfkoenig]

Mit "set mqtt2_server publish <topic> <message>" kann man Nachrichten per MQTT2_SERVER verschicken.
Mit einem notify/DOIF/etc kann man so Daten weiterleiten.

Etwas intelligenter ist ein MQTT2_DEVICE, mit einem setList Attribut. Damit kann man eine Liste von FHEM Befehlen definieren, die zu einem Publish von bestimmten topic+message konvertiert werden. Hier braucht man zwar auch noch ein notify/DOIF zum Verbinden, aber es ist zivilisierter / strukturierter.

Die naechste Stufe ist MQTT_GENERIC_BRIDGE, was das Verbinden von notify/DOIF uebernimmt, indem man in der Quelle per Attribut spezifiziert, welches topic+message per publish gesendet werden soll, wenn sich was aendert.

Ich wuerde als erstes das python Skript richtung MQTT2_SERVER schicken.
Wenn es was sagt (selber publish macht), dann wird automatisch ein MQTT2_DEVICE angelegt.

Mit "list TYPE=MQTT2_SERVER" kriegt man die eigentliche Verbindung raus, und nach "list <Verbindungname>" sieht man unter subscriptions die topics, was die Gegenseite bestellt hat.

Wenn ich weiss, was die Gegenseite braucht, dann wuerde ich ein paar Tests mit "set mqtt2_server publish <topic> <message>" machen, und wenn das wie erwartet funktioniert, dann (je nach Komplexitaet/Bedarf) einen der vorher beschriebenen Verfahren implementieren.
Fuer Anfaenger empfehle ich eins nach dem anderen, da man so besser versteht, was passiert.

[FHEMGerd]

Danke! Wirklich gute Schritt für Schritt Anleitung, das lichtet den Wirrwarr in meinem Kopf deutlich!

Zu dem Punkt

Ich wuerde als erstes das python Skript richtung MQTT2_SERVER schicken.
Wenn es was sagt (selber publish macht), dann wird automatisch ein MQTT2_DEVICE angelegt.

Das Skript selbst publisht (soweit ich es verstanden habe) nichts, das empfängt (subscribed ?) nur.
Muss das Skript (bzw. das raspi mit dem VenusOS auf dem das Skript läuft) trotzdem als Device (vermutlich ein MQTT2_DEVICE wie z. B. meine S20 mit Tasmota) beim FHEM MQTT Server "bekannt" sein ?
Und dort für die fraglichen topics "subscribed" sein ?

Anders gefragt: Wenn man (mit einer der 3 beschriebenen Methoden) Nachrichten publisht, dann gehen die nur an die MQTT Clients, die sich für die topics "interessieren", hab ich das richtig verstanden ?

So ein topic, was das Skript gerne hätte heißt z. B. zaehler/strom/EVU/WirkleistungGesamt
Und egal mit welcher der 3 Methoden der Server das topic publisht, es muss (in FHEM) ein Gerät da sein, dass sich für das topic interessiert, richtig ?

Daher die Idee, das Skript einfach das, was es empfangen will senden zu lassen ?
Dann muss ich mich wohl mal in das python modul "paho mqtt client" einlesen ...

[rudolfkoenig]

Fuer die andere Richtung (script => FHEM) gibt es auch die gleichen 3 Methoden, mit folgenden Bemerkungen:

Fuer #1: ("bare-bone", mit notify) "attr mqtt2_server rawEvents .*" setzen, damit erzeugt MQTT2_SERVER fuer alle empfangenen MQTT Nachrichten ein Event, worauf man mit notify/DOIF reagieren kann.

Fuer #2: (mit MQTT2_DEVICE) das readingsList Attribut der MQTT2_DEVICE wird automatisch erweitert, und damit die MQTT Nachricht in Reading + Event fuer dieses MQTT2_DEVICE konvertiert, inkl JSON Dekodierung bzw. Topic-Vereinfachung.

Fuer #3: (mit MQTT_GENERIC_BRIDGE) wie bei Senden, braucht man fuer den Empfang auch kein MQTT2_DEVICE, es sind natuerlich andere Attribute, als beim Senden.

Man kann die Methoden auch mischen, also z.Bsp. MQTT2_DEVICE mit notify fuer Empfang, und MQTT_GENERIC_BRIDGE fuers Senden.

[Beta-User]

Danke! Wirklich gute Schritt für Schritt Anleitung

Kann da nur zustimmen!

Vielleicht noch eine direktere Antwort auf diese Fragen:

Daher die Idee, das Skript einfach das, was es empfangen will senden zu lassen ?
Dann muss ich mich wohl mal in das python modul "paho mqtt client" einlesen ...

MAn. brauchst du dich nicht mit den Untiefen auf der Script-Seite rumschlagen.

Anders gefragt: Wenn man (mit einer der 3 beschriebenen Methoden) Nachrichten publisht, dann gehen die nur an die MQTT Clients, die sich für die topics "interessieren", hab ich das richtig verstanden ?

So ein topic, was das Skript gerne hätte heißt z. B. zaehler/strom/EVU/WirkleistungGesamt
Und egal mit welcher der 3 Methoden der Server das topic publisht, es muss (in FHEM) ein Gerät da sein, dass sich für das topic interessiert, richtig ?

Ja. Aber da die Verbindung im Server ja steht, mußt du einfach nur den richtigen Wert an die richtige Stelle publishen, und wenn die Gegenstelle dann da ist, bekommt sie das auch mit. (Expliziter: ich würde nicht "retain" publishen).

Also (erst mal): Ein notify auf das Device:Reading legen, in dem der gewünschten Wert für "WirkleistungGesamt" jeweils triggernd aktualisiert wird. Als Anweisung dann den passenden publish-Befehl (an "zaehler/strom/EVU/WirkleistungGesamt") zusammenbasteln (vermutlich mit $EVTPART1). Danach sehen wir weiter, was die "beste Variante" für dein Anliegen ist.

[FHEMGerd]

Ich hab mal mit der OpenWB angefangen (erscheint mir einfacher, die topics sind da top dokumentiert), wie gesagt, die interessiert sich (für PV geführtes Laden) auch für die Leistung am Einspeisepunkt.
Das Notify, welches augenscheinlich funktioniert sieht so aus:

Code Auswählen Erweitern

defmod n_EHZ_P2OpenWB notify myEHZremote:power:.* { fhem("set openwb publish openWB/set/evu/W " . int($EVTPART1) ) }
Im Prinzip stammt die Vorlage dazu aus dem Wiki zum Thema OpenWB von Ch.eick.
Allerdings war in seinem notify ein Semikolon vor der letzten geschweiften Klammer. Das mochte FHEM nicht.

Außerdem wird m. E. das MQTT Gerät, welches sich für das topic interessiert im set Befehl angesprochen (in meinem Fall openwb).
Nicht das Gerät, das MQTT2_Server ist, wie im Vorschlag von rudolfkoenig.
Jedenfalls hat es bei mir nur so funktioniert.
Ich berichte, wenn es Fortschritte mit dem Skript gibt. Danke für Eure kompetente Hilfe!

[sledge]

Zur Ursprungsfrage zurück:

Victron / Venus OS möchte die Daten im Wesentlichen auf dem DBUS oder via MODBUS - gerade der letzte Weg ist gut dokumentiert und auch ohne Klimmzüge durch die FHEM-Seite zu erreichen. Eine Liste aller MODBUS Register gibt es auf der Victron-Homepage.

Für diverse Einspeisezähler gibt es ebenfalls auf github Erweiterungen für Venus OS (zB Datamanager von Fronius, SMA-Zähler etc).

Die Komplexität liegt (leider) nicht auf der FHEM-Seite, sondern auf der Victron-Seite (IMHO). Im Zweifelsfall wird man auch im Victron Forum, Bereich "Modifications" entsprechende Hilfe finden, auch im openWB Forum gibt es einige Threads, die sich mit dem Topic befassen.

Auf GITHUB gibt es Beschreibungen von Victron, wie man von MQTT zu DBUS kommt, wobei ich hier bisher nur lesend zugreife.

Update: https://github.com/victronenergy/dbus-mqtt

Hier steht auch, wie man schreibend via MQTT auf den DBUS zugreifen kann.

[rudolfkoenig]

Außerdem wird m. E. das MQTT Gerät, welches sich für das topic interessiert im set Befehl angesprochen (in meinem Fall openwb).

Aber nur dann, wenn man publish als Befehl im setList Attribut des MQTT2_DEVICE definiert hat.
Beim MQTT2_SERVER muss man dafuer nichts machen.

[FHEMGerd]

Ich seh konzeptionell immer noch nicht klar, drum frag ich nochmal nach:

..
Aber nur dann, wenn man publish als Befehl im setList Attribut des MQTT2_DEVICE definiert hat.

Also ich hab kein setList Attribut mit publish als Befehl im MQTT device, und es tut trotzdem:

Code Auswählen Erweitern

defmod openwb MQTT2_CLIENT 192.168.x.x:1883
attr openwb autocreate no
attr openwb room Wandkiste
attr openwb subscriptions openWB/lp/1/VPhase1 openWB/lp/1/VPhase2 openWB/lp/1/VPhase3 openWB/lp/1/boolPlugStat openWB/lp/1/boolChargeStat openWB/lp/1/W openWB/set/evu/W openWB/set/evu/WhExported openWB/set/evu/WhImported


Code Auswählen Erweitern

Internals:
   BUF       
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        192.168.x.x:1883
   DeviceName 192.168.x.x:1883
   FD         56
   FUUID      6213f34a-f33f-0ca6-514f-84baac27341ae3ba
   NAME       openwb
   NR         324
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   openwb
   eventCount 22434
   lastMsgTime 1666952312.61655
   nextOpenDelay 5
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2022-10-28 12:18:32   lastPublish     openWB/set/evu/W:-667
     2022-10-28 11:58:11   state           opened
Attributes:
   autocreate no
   room       Wandkiste
   subscriptions openWB/lp/1/VPhase1 openWB/lp/1/VPhase2 openWB/lp/1/VPhase3 openWB/lp/1/boolPlugStat openWB/lp/1/boolChargeStat openWB/lp/1/W openWB/set/evu/W openWB/set/evu/WhExported openWB/set/evu/WhImported

Mit einem set Befehl, der den FHEM MQTT Server anspricht funktionierts hingegen nicht. Obwohl ich die topics als subscribtions in der openwb ergänzt hatte. Letzteres spielt offenbar keine Rolle, wenn der set Befehl den Client (die openwb) anspricht. Allerdings verwirrend, dass das Gerät, dass eigentlich subscribed published (zumindest in der FHEM Syntax).

[Beta-User]

Warum taucht hier auf einmal ein MQTT2_CLIENT-Device auf?

Kannst du mal zeigen, wie der von dir genannte "FHEM MQTT Server" ausschaut?

Das hier sieht eher so aus, als würde auf der Wallbox ein eigener (MQTT-) Server laufen. Wenn das so wäre, wäre  auch klar, dass ein publish über den MQTT2_SERVER rein gar nichts bringt, weil niemand darauf hört...

Dann muss das publish an den MQTT2_CLIENT gehen.

[rudolfkoenig]

Also ich hab kein setList Attribut mit publish als Befehl im MQTT device, und es tut trotzdem:

"Trotzdem" ist so'ne Sache: MQTT2_CLIENT is genauso ein Ausgabegeraet (IODev) wie MQTT2_SERVER, deswegen gibts da auch publish.
Das gezeigte notify entspricht der beschriebenen ersten Stufe, nur dass der MQTT Server nicht FHEM ist.

Ich habe vom setList Attribut bei MQTT2_DEVICE gesprochen ("Stufe zwei")

[FHEMGerd]

Warum taucht hier auf einmal ein MQTT2_CLIENT-Device auf?

Also aus Sicht FHEM (der MQTT Server) sollte doch die OpenWB ein MQTT Client sein ?
Ja, im Wiki zu FHEM+OpenWB spricht ch.eick davon, dass in der OpenWB ein MQTT Server läuft.
Und man den per FHEM derat anspricht, dass man die OpenWB schlicht als Gerät vom Typ "MQTT" definiert.
Ich dachte aber, ein schlichtes MQTT Device wäre nicht mehr zeitgemäß ("überholt") und ein Client erschien mir passender.

Kannst du mal zeigen, wie der von dir genannte "FHEM MQTT Server" ausschaut?

Klar (bei "..." habe ich m. E. unwichtige Daten gelöscht):

Code Auswählen Erweitern

defmod myBroker MQTT2_SERVER 1883 global
attr myBroker autocreate simple
attr myBroker room MQTT

setstate myBroker 2022-09-10 21:44:26 .RETAIN {..}
setstate myBroker 2022-10-28 12:02:07 lastPublish openWB/set/evu/W:. 546
setstate myBroker 2022-10-28 11:04:25 nrclients 10
setstate myBroker 2022-09-10 21:44:49 state Initialized
Und noch ein list (bei "..." habe ich m. E. unwichtige Daten gelöscht)

Code Auswählen Erweitern

Internals:
   CONNECTS   1525
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        1883 global
   FD         8
   FUUID      5d795ab4-f33f-f36c-cacd-ce0bb9fd0a1e0924
   NAME       myBroker
   NR         18
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   eventCount 3106
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2022-10-28 13:48:42   RETAIN          {...}
     2022-10-28 12:02:07   lastPublish     openWB/set/evu/W:. 546
     2022-10-28 11:04:25   nrclients       10
     2022-09-10 21:44:49   state           Initialized
   clients:
     myBroker_192.x.x.106_49346 1
     myBroker_192.x.x.62_54014 1
     myBroker_192.x.x.63_51653 1
     myBroker_192.x.x.64_55434 1
     myBroker_192.x.x.65_1748 1
     myBroker_192.x.x.68_55486 1
     myBroker_192.x.x.90_57850 1
     myBroker_192.x.x.92_20990 1
     myBroker_192.x.x.93_57198 1
     myBroker_192.x.x.94_61222 1
   retain:
     shellies/announce:
       ts         1666941250.69279
       val        {"id":"shelly1-BCDDC27787AE","model":"SHSW-1","mac":"BCDDC27787AE","ip":"192.x.x.65","new_fw":false,"fw_ver":"20220809-123240/v1.12-g99f7e0b"}
     shellies/shelly1-BCDDC27787AE/announce:
       ts         1666941250.71542
       val        {"id":"shelly1-BCDDC27787AE","model":"SHSW-1","mac":"BCDDC27787AE","ip":"192.x.x.65","new_fw":false,"fw_ver":"20220809-123240/v1.12-g99f7e0b"}
     shellies/shelly1-BCDDC27787AE/info:
       ts         1666941250.73214
       val        {"wifi_sta":{"connected":true,"ssid":"xxxx","ip":"192.x.x.65","rssi":-81},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"09:14","unixtime":1666941251,"serial":249,"has_update":false,"mac":"BCDDC27787AE","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"source":"timer"}],"meters":[{"power":0.00,"is_valid":true}],"inputs":[{"input":0,"event":"","event_cnt":0}],"ext_sensors":{},"ext_temperature":{},"ext_humidity":{},"update":{"status":"idle","has_update":false,"new_version":"20220809-123240/v1.12-g99f7e0b","old_version":"20220809-123240/v1.12-g99f7e0b"},"ram_total":51688,"ram_free":39612,"fs_size":233681,"fs_free":149847,"uptime":2470935}
     shellies/shelly1-BCDDC27787AE/input/0:
       ts         1666957722.63006
       val        0
     shellies/shelly1-BCDDC27787AE/input_event/0:
       ts         1666941250.77825
       val        {"event":"","event_cnt":0}
     shellies/shelly1-BCDDC27787AE/online:
       ts         1666941250.67319
       val        true
     shellies/shelly1-BCDDC27787AE/relay/0:
       ts         1666957722.61851
       val        off
     tasmota/discovery/2CF4321B6FDB/config:
       ts         1666946001.2238
       val        {"ip":"192.x.x.68","dn":"OBI_Kueche","fn":["Tasmota",null,null,null,null,null,null,null],"hn":"OBI-Kueche","mac":"2CF4321B6FDB","md":"OBI Socket 2","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["off","on","toggle","hold"],"sw":"10.0.0","t":"tasmota_1B6FDB","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":0,"lt_st":0,"sho":[0,0,0,0],"ver":1}
     tasmota/discovery/2CF4321B6FDB/sensors:
       ts         1666946001.24112
       val        {"sn":{"Time":"2022-10-28T10:33:21"},"ver":1}
     tasmota/discovery/4C11AE110BB5/config:
       ts         1666538232.67323
       val        {"ip":"192.x.x.67","dn":"OBIBadOG","fn":["Tasmota",null,null,null,null,null,null,null],"hn":"OBIBadOG","mac":"4C11AE110BB5","md":"OBI Socket 2","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["off","on","toggle","hold"],"sw":"10.0.0","t":"tasmota_110BB5","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":0,"lt_st":0,"sho":[0,0,0,0],"ver":1}
     tasmota/discovery/4C11AE110BB5/sensors:
       ts         1666538232.69574
       val        {"sn":{"Time":"2022-10-23T17:17:12"},"ver":1}
     tasmota/discovery/500291F0ACB1/config:
       ts         1666947875.07675
       val        {"ip":"192.x.x.93","dn":"ShellyTerasse","fn":["Tasmota",null,null,null,null,null,null,null],"hn":"ShellyTerasse","mac":"500291F0ACB1","md":"Shelly 1","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["off","on","toggle","hold"],"sw":"10.0.0","t":"tasmota_F0ACB1","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":1,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":0,"lt_st":0,"sho":[0,0,0,0],"ver":1}
     tasmota/discovery/500291F0ACB1/sensors:
       ts         1666947875.09759
       val        {"sn":{"Time":"2022-10-28T11:04:22","Switch1":"off"},"ver":1}
     tasmota/discovery/5CCF7F7F470C/config:
       ts         1666289553.09432
       val        {"ip":"192.x.x.63","dn":"S20Flur","fn":["Tasmota",null,null,null,null,null,null,null],"hn":"S20Flur","mac":"5CCF7F7F470C","md":"Sonoff Basic","ofln":"Offline","onln":"Online","state":["off","on","toggle","hold"],"sw":"8.5.1","t":"tasmota_7F470C","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"btn":[0,0,0,0],"so":{"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"80":0},"lk":1,"lt_st":0,"ver":1}
     tasmota/discovery/5CCF7F7F470C/sensors:
       ts         1666289553.14558
       val        {"sn":{"Time":"2022-10-20T20:12:33","BME280":{"Temperature":19.0,"Humidity":59,"DewPoint":10.8,"Pressure":965.2,"SeaPressure":1016.2},"PressureUnit":"hPa","TempUnit":"C"},"ver":1}
     tasmota/discovery/84F3EBB0DE19/config:
       ts         1666941253.03827
       val        {"ip":"192.x.x.62","dn":"S20Garage","fn":["S20Garage",null,null,null,null,null,null,null],"hn":"S20Garage","mac":"84F3EBB0DE19","md":"Sonoff Basic","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"9.5.0","t":"DVES_B0DE19","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":1,"lt_st":0,"sho":[0,0,0,0],"ver":1}
     tasmota/discovery/84F3EBB0DE19/sensors:
       ts         1666941253.05916
       val        {"sn":{"Time":"2022-10-28T09:14:13"},"ver":1}
     tasmota/discovery/BCDDC209B3B0/config:
       ts         1666941248.58509
       val        {"ip":"192.x.x.94","dn":"TeckinTV","fn":["TeckinTV",null,null,null,null,null,null,null],"hn":"TeckinTV","mac":"BCDDC209B3B0","md":"BlitzWolf SHP","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["off","on","toggle","hold"],"sw":"10.0.0","t":"tasmota_09B3B0","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":0,"lt_st":0,"sho":[0,0,0,0],"ver":1}
     tasmota/discovery/BCDDC209B3B0/sensors:
       ts         1666941248.60337
       val        {"sn":{"Time":"2022-10-28T09:14:08","ENERGY":{"TotalStartTime":"2021-04-09T14:22:49","Total":55.385,"Yesterday":0.130,"Today":0.000,"Power": 0,"ApparentPower": 0,"ReactivePower": 0,"Factor":0.00,"Voltage":231,"Current":0.000}},"ver":1}
     tasmota/discovery/CC50E377CDCF/config:
       ts         1666941247.24152
       val        {"ip":"192.x.x.64","dn":"OBI_Pumpe","fn":["Tasmota",null,null,null,null,null,null,null],"hn":"OBIPumpe","mac":"CC50E377CDCF","md":"OBI Socket 2","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["off","on","toggle","hold"],"sw":"11.1.0","t":"tasmota_77CDCF","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":0,"lt_st":0,"sho":[0,0,0,0],"ver":1}
     tasmota/discovery/CC50E377CDCF/sensors:
       ts         1666941247.26008
       val        {"sn":{"Time":"2022-10-28T09:14:07"},"ver":1}
     tasmota/discovery/DC4F2233E435/config:
       ts         1666896350.01914
       val        {"ip":"192.x.x.90","dn":"TeckinBiblio","fn":["Tasmota",null,null,null,null,null,null,null],"hn":"TeckinBiblio","mac":"DC4F2233E435","md":"BlitzWolf SHP","ofln":"Offline","onln":"Online","state":["off","on","toggle","hold"],"sw":"8.5.1","t":"tasmota_33E435","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"btn":[0,0,0,0],"so":{"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"80":0},"lk":1,"lt_st":0,"ver":1}
     tasmota/discovery/DC4F2233E435/sensors:
       ts         1666896350.03963
       val        {"sn":{"Time":"2022-10-27T20:45:47","ENERGY":{"TotalStartTime":"2021-01-05T15:42:41","Total":76.176,"Yesterday":0.143,"Today":0.000,"Power":6,"ApparentPower":11,"ReactivePower":10,"Factor":0.50,"Voltage":230,"Current":0.048}},"ver":1}
     tele/DVES_B0DE19/LWT:
       ts         1666941252.75348
       val        Online
     tele/tasmota_09B3B0/LWT:
       ts         1666941247.84934
       val        Online
     tele/tasmota_110BB5/LWT:
       ts         1666539414.83501
       val        Offline
     tele/tasmota_1B6FDB/LWT:
       ts         1666945991.86314
       val        Online
     tele/tasmota_33E435/LWT:
       ts         1666919458.56501
       val        Online
     tele/tasmota_77CDCF/LWT:
       ts         1666941246.80836
       val        Online
     tele/tasmota_7F470C/LWT:
       ts         1666941247.30441
       val        Online
     tele/tasmota_F0ACB1/LWT:
       ts         1666947862.4768
       val        Online
     wasserzaehler/connection:
       ts         1666957512.69287
       val        connected
     wasserzaehler/main/error:
       ts         1662839099.51379
       val        Rate too high - Read: 1526.256 - Pre: 859.990
Attributes:
   autocreate simple
   room       MQTT
Interessant, dass mein Client (die OpenWB) in ihrem def überhaupt keinen Bezug zum IODev MQTT Server hat.
Bei den anderen Geräten, also den Tasmota WLAN Steckdosen ist das so.

Das hier sieht eher so aus, als würde auf der Wallbox ein eigener (MQTT-) Server laufen. Wenn das so wäre, wäre  auch klar, dass ein publish über den MQTT2_SERVER rein gar nichts bringt, weil niemand darauf hört...

Ich denke Du hast recht, die OpenWB ist ein MQTT Server. Ich hab auch mal eine Weile rumgelesen, wie man eine Server zur Server Kommunikation machen könnte. Ich bin aber nicht draus schlau geworden.
Es scheint ja aktuell zu tun. Findest Du ich sollte es ändern, wenn ja wie (Konzept) ?

[FHEMGerd]

Victron / Venus OS möchte die Daten im Wesentlichen auf dem DBUS oder via MODBUS - gerade der letzte Weg ist gut dokumentiert und auch ohne Klimmzüge durch die FHEM-Seite zu erreichen. Eine Liste aller MODBUS Register gibt es auf der Victron-Homepage.

Das ist eine sehr interessante Idee, bzw. ein klasse Hinweis, danke.
Nur dass ich es richtig verstanden habe:
Du meinst, "Modbus TCP" im Venus OS freischalten (hab mal ein Screenshot angehängt).
Und dann mit einem geeigneten FHEM Modul für Modbus TCP (hast Du einen Tip welches) das entsprechende Register im Venus OS mit dem EHZ Reading beschreiben - fertig ?

Soweit ich verstanden habe legt das genannte python Skript auch eine Art "Meter" in Venus OS an.
Das wäre dann gar nicht nötig bzw. überflüssig ?

[sledge]

Ad "Wallbox / MQTT": Die openWB als genannte Wallbox verwendet einen eigenen MQTT-Server zwecks Steuerung. Kann man seitens FHEM wunderbar via MQTT2_CLIENT einbinden, wird dann angelegt und lässt sich auch steuern.

Detaillierte Infos muss man sich vermutlich im openWB Forum in dem sehr (!!) langen MQTT Thread raussuchen. Aber geht generell.

Ad Victron.

Hier hast Du mehrere Möglichkeiten

• Verwendung eines Python-Moduls für einen von Dir verwendeten Zähler. Funktioniert mit SMA, Fronius und bestimmt noch ein paar anderen. Diese Module lesen die erfordelrichen Daten via HTTP von den Zählern und schieben sie auf den DBUS im Venus OS. So werden die Zähler auch in der Remote Console angezeigt usw. Mein Fronius Datamanager verhält sich wie ein EM24.
• Verwendung von MODBUS. Da gibt es mW in FHEM genau ein Modul von Stephan Strobel. Muss man sich ein bisschen reinfuchsen, aber im Wesentlichen legst Du das erforderliche MODBUS-Device an und liest / schreibst die definierten Register, die Du aus der Victron-Doku entnehmen kannst.
  
  Hinweis: Die MODBUS ID musst Du Dir unter Venus OS raussuchen - nach der Aktivierung des MODBUS TCP im Cerbo / Venus OS.
• Verwendung von MQTT, um Werte an den DBUS zu senden. Hier kommt der github Link meines vorherigen Beitrags zum Tragen. Du suchst also das richtige MQTT-Topic raus (via MQTT-Explorer zB) und sendest dorthin die Werte, die benötigt werden. Also vermutlich irgendwas mit "grid" und "power" und das je Phase, dazu noch den saldierten Wert... ist eine Annahme, da ich diesen Weg nicht verwende. Ich meine, schonmal eine Übersicht mit den DBUS-PFaden und zugehörigen MQTT-Topics gefunden zu haben - weiß aber nicht mehr wo.
  
  Hinweis: Wenn Du Werte abonnieren möchtest, unbedingt an das Keepalive denken. Ist aber alles sehr gut auf der github-Seite dokumentiert.

Ich bevorzug den ersten Weg - leider schreibst Du nicht, ob Du noch einen anderen Zähler hast - die meisten PV-Anlagen bringen da ja durchaus "was eigenes" mit - dann könnte man schnell recherchieren, ob es was passendes gibt für Venus OS. Weg 2 und 3 sind IMHO gleichwertig - BEi Wert 2 gehst Du halt via MODBUS - ich selber lese nur Werte aus, aber das Wiki enthält bestimt auch Beispiele für Schreiben. Weg 3 (inkl. Schreiben via MQTT auf DBUS) ist auf github dokumentiert.

[andremar6918]

Hallo,

ich habe ein vergleichbares System laufen. Der vorhandene Zähler wird mittels IR ausgelesen und in FHEM mit Obis ausgewertet.
FHEM sendet dann via MQTT an den Venus-MQTT-Server. Auf dem Venus muss ein Python-Script laufen, welches das eigentlich notwendige Smartmeter
simuliert.
Bezüglich Venus und Python kann man hier nachlesen: https://www.photovoltaikforum.com/thread/156974-victron-ess-mit-rasberry-steuern-ohne-gx-ohne-em24-weil-die-leistungsbilanz-scho/?postID=2670601#post2670601

VG

Andreas

[FHEMGerd]

Mal ein Update bzw. Status, vielleicht auch Abschluss des Threads 

@sledge:
Nach meinem Verständnis funktioniert Dein Vorschlag, dem VenusOS per Modbus die Leistung am Einspeisepunkt zu übermitteln nicht.
Ich habe mir die Liste mit den Modbus Registern runtergeladen. Da sind auch beschreibbare Register dabei.
Aber m. E. sind das "nur" Konfigurationsdaten, keine dynamischen Daten, insbesondere nicht die Leistung am Einspeisepunkt.

Inzwischen ist es mir gelungen, dem VenusOS, bzw. dem python Skript (Vorlage hier: https://github.com/Marv2190/venus.dbus-MqttToGridMeter) die Leistung am Einspeisepunkt per MQTT zu schicken.
Das python Skript schreibt das dann in den entsprechenden dbus Wert (m. E. "/Ac/Power").

Kurios dabei: Beim Publishen (per notifiy) von FHEM zur openwb (ein MQTT2_CLIENT Gerät) spreche ich eben die openwb an, siehe auch Beitrag vom 27.10.
Das Publish zum VenusOS geht aber sozusagen von FHEM aus m. E. "ins Blaue".
Das VenusOS ist in FHEM gar nicht als Gerät bekannt.
Es funktioniert aber trotzdem:

Code Auswählen Erweitern

defmod n_EHZ_P2venus notify myEHZremote:power:.* { fhem("set myBroker publish zaehler/strom/EVU/WirkleistungGesamt " . int($EVTPART1) ) }
Ich hatte zwar das python Skript auf dem VenusOS zu Testzwecken mal dazu gebracht etwas in Richtung FHEM zu publishen, und daraufhin wurde auch ein Gerät angelegt.
Das konnte ich aber löschen (ich will ja von VenusOS aus gar nichts publishen).
Vielleicht ist das VenusOS noch irgendwo in der Konfig des FHEM MQTT Servers vorhanden, aber ich konnte nichts finden, insbesondere nicht die IP Adresse.

Dass es trotzdem funktioniert heißt für mich nur, dass ich das Konzept, wie FHEM MQTT abbildet einfach nicht wirklich verstanden habe. 

Danke nochmal für Eure Hilfe.

[sledge]

Hi FHEMGerd,

nur kurz: Die gesuchten Register in der Modbus-Doku heißen meist *setpoint*, teilweise noch für die entsprechenden Phasen L1-L3. Und die Liste beinhaltet nicht nur "Konfigurationsparameter (die aber auch)", sondern auch die erfordelrichen Register für die aktuellen System-/Leistungsdaten.

Unter "com.victronenergy.grid" hättest Du alles gefunden.

Aber wenn es jetzt bei Dir läuft und Du mit der Geschwindigkeit Deiner Lösung zufrieden bist - there you go.

[Fachwerkbewohner]

Hallo FHEMGerd,

kannst Du mal bitte sagen, wie Du das Python-Script configuriert hast?
Also diese Zeilen hier:
broker_address = "IPADRESS"
MQTTNAME = "MQTTtoMeter"
Zaehlersensorpfad = "Path"

Ich habe bei Path den Pfad zum MQTT-Topic eingetragen und glaube, dass hier etwas falsch ist.
Zaehlersensorpfad = "zaehler/strom/EVU/WirkleistungGesamt"

Dieses Topic enthält bei mir nur einen int-Wert und das Script erwartet hier einen json-Ausdruck.
Mir fehlt aber eine debug-Möglichkeit, um sagen zu können, was das Script überhaupt empfängt.


Gruß
Mathias

[FHEMGerd]

Hallo Matthias,

entschuldige, ich sehe das erst jetzt. Hier die Zeilen, hoffe das hilft Dir noch:

Code Auswählen Erweitern

# MQTT Setup
broker_address = "192.x.x.x"
port = 1883
MQTTNAME = "FHEM"
Die Konstante bzw. den alias Zaehlersensorpfad benutze ich nicht, den habe ich entfernt.
Ich habe an der Stelle, an der sich das Skript als Client für die Topics subscribed diese direkt eingetragen:

Code Auswählen Erweitern

def on_connect(client, userdata, flags, rc):
    print("Verbunden mit MQTT Broker: " + broker_address)
    client.subscribe("zaehler/strom/EVU/WirkleistungGesamt")
    client.subscribe("zaehler/strom/EVU/Bezug")
Diese Topics publishe ich dann im FHEM wie beschrieben per notify.

Grüße, Gerd