MQTT rewrite mit MQTT BRIDGE oder MQTT_GENERIC_BRIDGE

Begonnen von pcjogi, 18 August 2019, 01:01:16

Vorheriges Thema - Nächstes Thema

pcjogi

Hallo zusammen,

ich habe einige MQTT Devices, die mir über /SYSTEM/# ihre Werte an einen mosquito Broker schicken. Jetzt kommen z.B. für einen 4-fach Schalter die Topics
/CSS/System/SONOFFCH4PRO01/state/POWER1
/CSS/System/SONOFFCH4PRO01/state/POWER2
/CSS/System/SONOFFCH4PRO01/state/POWER3
und
/CSS/System/SONOFFCH4PRO01/state/POWER4

Ich würde jetzt gerne diese Topics mit
/CSS/IOT/Warmwasser
/CSS/IOT/StellantriebWohnzimmer
/CSS/IOT/LichtHeizungsraum

wieder als MQTT meinen Systemen (fhem, iobroker, indirekt für grafana) zur Verfügung stellen.

Ist so etwas mit der MQTT_BRIDGE möglich und sinnvoll?

Wenn ja würde ich mich damit tiefer beschäftigen, würde das aber ungerne tun um am Ende festzustellen das das alles für die Tonne war.

Vielen Dank


Haupt-Fhem (Docker auf Synology), Sub-Fhem (433Mhz und 833Mhz) auf RasPi, Sub-Fhem (Heizungssteuerung) auf RasPi, Sub_Fhem (System) auf RasPi, IoBroker zur Darstellung (Docker auf Synology), alles verbunden über einen MQTT Broker, insgesamt ca. 100 Sensoren/Aktoren

Beta-User

MQTT_BRIDGE ist dafür da, ein bestehendes FHEM-Device, das _nicht_-MQTT "spricht" (z.B. eines vom TYPE=CUL_HM) an MQTT anzubinden (1:1, also pro FHEM-Device nochmal jeweils eine Bridge).

Damit kommt es m.E. für deinen Gedankenansatz "gar nicht" (Aushahme s.u. zur Gen-Bridge) in Frage. Heute sollte man für diesen Typ Aufgabe sowieso MQTT_GENERIC_BRIDGE verwenden, das erlaubt 1:n-Anbindungen und (außer ein paar Grundeinstellungen, die in der Bridge stehen) alles wird innerhalb des eigentlichen Devices konfiguriert.

Weiter stellt sich die Frage, wie die Infos erst mal "nach FHEM" kommen. Grundsätzlich sollte es gehen, das innerhalb von FHEM zu verarbeiten und ggf. dann auch weiterzuleiten. Wenn es eine 1:1 Weiterleitung wäre (was ich nicht vermute...), könnte es mit einem notify auf ein RAW-Events zulassendes MQTT2_CLIENT-Device gehen, wobei z.B. die "Zuordnungstabelle" irgendwo stehen müßte (z.B. in einem userattr bei dem betreffenden IO).
Wenn eine Weiterverarbeitung stattfindet (und z.B. bereits ein Device "StellantriebWohnzimmer" (TYPE=ROLLO?) exisitert, ist es _vermutlich_ einfacher, die MQTT_GENERIC_BRIDGE zu bemühen (oder eben alternativ auch für die Weiterleitung aus einem MQTT(2)_DEVICE heraus), und das jeweilige Reading darüber nochmal zu publishen (wobei mir das "Umpacken" an sich suspekt ist, auch für Grafana oder iobroker sind in der Regel die "Rohdaten" ausreichend und weniger fehleranfällig; ggf. ausgenommen "echte" Auswertungen wie für einen Stellmotor@ROLLO).

Just my2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files