Modul-Konzeption: Generic MQTT Bridge

Begonnen von hexenmeister, 21 Dezember 2017, 22:35:38

Vorheriges Thema - Nächstes Thema

hexenmeister

out of scope für diesen Modul. Seine Aufgabe ist lediglich die Readingsänderungen zu übertragen, so wie die sind. Und auch die ankommnde Werte aufzunehmen. Jegliche Logik gehört in eine andere Domäne.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

AH - Stimmt! hast absolut recht :-)

Jop müsste in das Modul was den eigentlich Device versorgt. Gut erkannt!  :-) 8)
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

hexenmeister

Habe jetzt endlich eine neue Testversion anzubieten. Hoffe auf flesiges Testen und Fehlerberichte :)
Diese Version ist konfigurationstechnish nicht mit dem ersten Wurf kompatibel.
Senden der Werte funktioniert schon aus meiner Sicht ganz gut.
Was noch gar nicht fertig ist: Empfangen (subscribe) und zentrale generische Konfiguration (damit man an einer Stelle definieren kann, dass (bestimmte) Readings aller Geräte nach bestimmten Schema gemappt und gesendet werden).

Etwas Doku:

Dieses Modul ist eine MQTT-Bridge, die gleichzeitig mehrere FHEM-Devices erfasst und deren Readings
per MQTT weiter gibt bzw. aus den eintreffenden MQTT-Nachrichten befüllt.
Die (minimal) Konfiguration der Bridge selbst ist grundsätzlich sehr einfach.

Definition:
  Im einfachsten Fall reichen schon zwei Zeilen:
    defmod mqttGeneric MQTT_GENERIC_BRIDGE [prefix] [devspc]
    attr mqttGeneric IODev <MQTT-Device>
  Alle Parameterim Define sind optional.
  Der erste ist ein Prefix für die Steuerattribute, worüber die zu überwachende Geräte (s.u.)
  konfiguriert werden. Dafaultwert ist 'mqtt'.
  Der zweite Parameter ('devspec') erlaubt die Menge der zu überwachenden Geräten
  zu begrenzen (sonst werden einfach alle überwacht, was jedoch Performance kosten kann).
  s.a. https://fhem.de/commandref_DE.html#devspec

Attribute:
  IODev
    Dieses Attribut ist obligatorisch und muss den Namen einer funktionierenden MQTT-Modulinstanz beinhalten.


Für die überwachten Geräte wird die Liste der möglichen Attribute automatisch um mehrere weitere Einträge ergänzt,
die alle mit vorher in der Bridge definierten Prefix anfangen. Über diese wird die eigentliche MQTT-Anbindung konfiguriert.

Defaultmäßig werden folgende Attribute verwendet: mqttDefaults, mqttAlias, mqttPublish, mqttSubscribe.
Sie haben folgende Bedeutung:
  mqttDefaults
    Hier wird eine Liste der "key=value"-Paare erwartet. Folgende Keys sind dabei möglich:
      'qos' definiert ein Default für MQTT-Paramter 'Quality of Service'.
      'retain' erlaubt MQTT-Nachrichten als 'retained messages' zu markieren.
      'base' wird als Variable ($base) bei der Konfiguration von konkreten Topics zur Verfügung gestellt.
             Sie kann entweder Text oder eine Perl-Expression enthalten.
             Perl-Expression muss in Geschweifte Klammern eingeschlossen werden.
             In einer Expression können Variablen  verwendet werden.
             ($reading = Original-Readingname, $device = Devicename, $name = Readingalias (s. mqttAlias).
             Ist keine Alias definiert, ist $name=$reading).

    Alle diese werte können durch vorangestelle Prefixe ('pub:' oder 'sub') in ihrer Gültigkeit
    nur auf das Senden bzw. Empfangen begrenzt werden. Werte für 'qos' und 'retain' werden nur verwendet,
    wenn keine explizite Angaben darüber für ein konkretes Topic gemacht worden sind.

    Beispiel:
      attr <dev> mqttDefaults base={"/TEST/$device"} pub:qos=0 sub:qos=2 retain=0

  mqttAlias
    Dieses Attribut ermöglicht Readings unter einem anderen Namen auf MQTT-Topict zu mappen.
    Nur sinnvoll, wenn Topicdefinitionen Perl-Expressions mit entsprechenden Variablen sind.
    Auch hier werden 'pub:' und 'sub:' Prefixe unterstützt.
 
    Beispiel:
      attr <dev> mqttAlias pub:temperature=temp

  mqttPublish
    Hier werden konkrette Topics definiet und den Readings zugeordnet.
    Weiterhin können diese einzeln mit 'qos'- und 'retain'-Flags versehen werden.
    Topics können auch als Perl-Expression mit Veriablen definiert werden ($reading, $device, $name, $base).
    Wird anstatt eines Readingsnamen ein '*' verwendet, gilt diese Definition für alle Readings,
    für die keine explizite Angaben gemacht worden.

    Beispiel:
      attr <dev> temperature:topic={"$base/$name"} temperature:qos=1 temperature:retain=0 *:topic={"$base/$name"} humidity:topic=/TEST/Feuchte

  mqttSubscribe
    Dieses Attribut konfiguriert das Empfangen der MQTT-Nachrichten und deren Mapping auf die Attribute.
    Die Konfiguration entspricht der für das 'mqttPublish'-Attribut.

    Beispiel:
      TODO


  Beispiele:
    Bridge für alle möglichen Geräte mit dem Standardprefix:
      defmod mqttGeneric MQTT_GENERIC_BRIDGE
      attr mqttGeneric IODev mqtt

    Bridge mit dem Prefix 'mqtt' für drei bestimmte Geräte:
      defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt sensor1,sensor2,sensor3
      attr mqttGeneric IODev mqtt

    Bridge für alle Geräte in einem bestimmten Raum:
      defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=Wohnzimmer
      attr mqttGeneric IODev mqtt
     
    Einfachste Konfiguration eines Temperatursensors:
      defmod sensor XXX
      attr sensor mqttPublish temperature:topic=/haus/sensor/temperature

    Alle Readings eines Sensors (mit ihren Namen wie sie sind) per MQTT versenden:
      defmod sensor XXX
      attr sensor mqttPublish *:topic={"/sensor/$reading"}
     
    Topicsdefinition mit Auslagerung von dem gemeinsamen Teilnamen in 'base'-Variable:
      defmod sensor XXX
      attr sensor mqttDefaults base={"/$device/$reading"}
      attr sensor mqttPublish *:topic={$base}

    Topicsdefinition nur für bestimmte Readings mit deren gleichzeitigen Umbennenung (Alias):
      defmod sensor XXX
      attr sensor mqttAlias temperature=temp humidity=hum
      attr sensor mqttDefaults base={"/$device/$name"}
      attr sensor mqttPublish temperature:topic={$base} humidity:topic={$base}


  Beispiel für eine zentralle Konfiguration in der Bridge für alle Devices, die Reading 'temperature' besitzen:
      defmod mqttGeneric MQTT_GENERIC_BRIDGE
      attr mqttGeneric IODev mqtt
      attr mqttGeneric defaults sub:qos=2 pub:qos=0 retain=0
      attr mqttGeneric publish temperature:topic={"/haus/$device/$reading"}

  Beispiel für eine zentralle Konfiguration in der Bridge für alle Devices
  (wegen schlechter Übersicht und einer unnötig großen Menge eher nicht zu empfehlen):
      defmod mqttGeneric MQTT_GENERIC_BRIDGE
      attr mqttGeneric IODev mqtt
      attr mqttGeneric defaults sub:qos=2 pub:qos=0 retain=0
      attr mqttGeneric publish *:topic={"/haus/$device/$reading"}
     

  TODOs
  - Subscribe ist noch nicht implementiert.
  - globale Defaults in der Bridge selbst (zentral für alle überwachte Geräte) sind nicht implementiert
  - damit beim Reconnect Subscriptions sauber wieder augebaut werden, ist ein Patch für IO (00_MQTT) notwendig (client_start und client_stop weiterreichen).

 
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

 :)
So! Ich schnapp mir das jetzt mal und bau mal mein Heizungsthermostat auf MQTT um :-)

Ich berichte dann.
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

hexenmeister

Wenn Du heute/gestern Update gemacht hast, wird es Probleme geben (Details hier: https://forum.fhem.de/index.php/topic,81765.msg772199.html#msg772199)
Ich stelle gleich eine neue Version hier rein.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

hexenmeister

#51
Probiere bitte diese Version.

Subscribe geht noch nicht, ist aber in Vorbereitung.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Master_Nick

#52
 ;D

Soo wenn das Subscribe noch geht ist es perfekt!  8) 8)

Habe mein Thermostat im Arbeitszimmer, Wohnzimmer und Kinderzimmer mal eben so auf MQTT gebaut.
Geht wirklich super einfach und ist absolut geil, dass man es IM Device und nicht woanders machen muss. So hat man alles genau da wo es hin gehört!
Große Klasse!

Es wartet nur noch auf das Subscribe  ;D ;D
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

carlos

Hallo,

Das Beispiel funktioniert leider nicht da die Attribute wohl anders lauten:
Beispiel für eine zentralle Konfiguration in der Bridge für alle Devices, die Reading 'temperature' besitzen:
      defmod mqttGeneric MQTT_GENERIC_BRIDGE
      attr mqttGeneric IODev mqtt
      attr mqttGeneric defaults sub:qos=2 pub:qos=0 retain=0
      attr mqttGeneric publish temperature:topic={"/haus/$device/$reading"}



Ich habe es dann so probiert:
defmod mqttGeneric MQTT_GENERIC_BRIDGE
      attr mqttGeneric IODev mqtt
      attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=0
      attr mqttGeneric globalPublish temperature:topic={"/haus/$device/$reading"}


aber es wird nichts gepublished.
Muss bei den  überwachten Geräten noch was eingestellt werden?
Gruß
Carlos
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly

Master_Nick

#54
Siehe Anleitung:   - globale Defaults in der Bridge selbst (zentral für alle überwachte Geräte) sind nicht implementiert  ;D
Scheint noch nicht nutzbar zu sein was du vor hast :-) Aber nutze doch solange einfach den Weg hier... ist pro Sensor dann halt 2 attr.

Einfach jedem Gerät, dass du in der generic bridge in der def angibst attribute setzen.

Z. B.:
Mein Device hat als attr
mqttDefaults base={"homeland/haushalt/heizung/Aussenthermometer"} pub:qos=2 sub:qos=2 retain=1
mqttPublish temperature:topic={"$base/$name"} temperature:qos=2 temperature:retain=1 humidity:topic={"$base/$name"} humidity:qos=2 humidity:retain=1


Ansonsten sehe ich in der Anleitung das ganze ohne deine globalDefaults:
  Beispiel für eine zentralle Konfiguration in der Bridge für alle Devices, die Reading 'temperature' besitzen:
      defmod mqttGeneric MQTT_GENERIC_BRIDGE
      attr mqttGeneric IODev mqtt
      attr mqttGeneric defaults sub:qos=2 pub:qos=0 retain=0
      attr mqttGeneric publish temperature:topic={"/haus/$device/$reading"}

Du hast globalPublish genutzt.
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

carlos

Hallo,
Ja genau, das habe ich überlesen:
- globale Defaults in der Bridge selbst (zentral für alle überwachte Geräte) sind nicht implementiert

Den anderen Weg hatte ich schon probiert, das hat funktioniert.

Ich kann warten bis das implementiert ist.
Super modul bis jetzt.
Danke

Gruß
Carlos
FHEM svn auf Intel NUC mit proxmox,1 UDOO, 3 Raspberry Pi, signalduino, nanoCUL, div. Homematic Komponenten, toom Baumarkt Funksteckdosen, einige sonoffs, hue, shelly

Shojo

Was ich noch nett finden für wenn man mehre Readings übergeben könnte.

z.B.

attr xxxx mqttPublish hvs|stateLight|rgb:topic={"Testing/$device/$name"}
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

Master_Nick

#57
Versteh ich was falsch?
Ich würde sagen, dass kann man doch.

mqttPublish desiredTemperature:topic={"$base/$name"} desiredTemperature:qos=2 desiredTemperature:retain=1 boost:topic={"$base/$name"} boost:qos=2 boost:retain=1 windowOpen:topic={"$base/$name"} windowOpen:qos=2 windowOpen:retain=1

Du musst halt nur den Eintag für jedes Reading wiederholen - das Ergebnis ist aber das gleiche.
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

Shojo

Ja das stimmt, das finde ich aber total überladen.

Daher wünschte ich mir eine sparsamere Schreibweise. 
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It

Master_Nick

Ok - dem Stimme ich zu als nice to have. :-)  8)
Aber, da das hier alles noch so neu ist, dass das subscribe noch nicht geht - würde ich sagen erst mal alles haben dann kann Feinschliff stattfinden :-)

Ist ja auch die Frage wieviel Umstellungsarbeit das im Modulcode so bedeuten würde *g*
Wir haben da eh gut reden - Hexenmeister legt ja hier die Glanzleistung ab.  ;D ;D
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)