Richtig publishen mit MQTT2

[volschin]

Hallo zusammen,
ich mache gerade meine ersten Gehversuche mit MQTT2 in FHEM.
Mein Mosquitto läuft, die MQTT2_CLIENT's von 2 FHEM-Instanzen connecten sich sauber auf den Mosquitto Broker.

Mir ist auch klar, wie ich die per MQTT empfangenen Nachrichten in ein MQTT2_DEVICE übernehme.   

Ein testweises

Code Auswählen Erweitern

set raspi1Broker publish /home/Bad/CO2/voc 565
wurde korrekt an einen Client übertragen.

Aber ich habe keine richtige Idee, wie ich die Sachen jetzt automatisch aus einem FHEM-Device publishe. Ich kann dafür jetzt zwar ein NOTIFY schreiben, habe aber Zweifel, dass das der richtige Weg ist. 

Gibt mir jemand einen Schubs in die richtige Richtung?

Danke und Gruß
Veit

[rudolfkoenig]

Fuer das MQTT2_DEVICE das setList Attribut passend setzen.
Alternativ einen der vielen attrTemplates anschauen/anwenden.

[Beta-User]

Kann es sein, dass du nach der Funktion von MQTT_GENERIC_Bridge suchet?

[dirk.k]

Hallo,
Keine Ahnung, ob es nicht anders/besser geht. Bei mir läuft das Ganze so:
zu einem Reading XYZ gibt es ein Attribut publishSet_XYZ:
"attr WeMos_S3 publishSet_RGBg fhem/sensors/3425514/setRGBg"
Ändert sich das Reading, wird publisht.
Beispiel (ein RGB Wert wird per userreading in 3 Einzelwerte zerlegt und diese gesendet)

Code Auswählen Erweitern

defmod WeMos_S3 MQTT_DEVICE
attr WeMos_S3 IODev mqtt_local
attr WeMos_S3 publishSet_RGBb fhem/sensors/3425514/setRGBb
attr WeMos_S3 publishSet_RGBg fhem/sensors/3425514/setRGBg
attr WeMos_S3 publishSet_RGBr fhem/sensors/3425514/setRGBr
attr WeMos_S3 subscribeReading_Temperatur fhem/sensors/ESPEasy_03/in/Sensor1/Temperature
attr WeMos_S3 userReadings \
RGBr {(hex(substr(ReadingsVal("WeMos_S3","RGB",0),0,2))*ReadingsVal("WeMos_S3","RGBv",0)/100)},\
RGBg {(hex(substr(ReadingsVal("WeMos_S3","RGB",0),2,2))*ReadingsVal("WeMos_S3","RGBv",0)/100)},\
RGBb {(hex(substr(ReadingsVal("WeMos_S3","RGB",0),4,2))*ReadingsVal("WeMos_S3","RGBv",0)/100)},\
\
attr WeMos_S3 webCmd RGB:RGB ff00ff:RGB ff0000:RGB ffff00:RGB 8CFF08:RGB 00ff00:RGB 05FF82:RGB 00FFff:RGB 088CFF:RGB 0000ff:RGB 000000:RGB FFFFFF
attr WeMos_S3 widgetOverride RGB:colorpicker,RGB

Beispiel2  (hier wird der Status gesendet)

Code Auswählen Erweitern

defmod Sonoff_S20_01 MQTT_DEVICE
attr Sonoff_S20_01 IODev mqtt_local
attr Sonoff_S20_01 publishSet 1 0 fhem/sensors/sonoff_S20_01/out/Relay
attr Sonoff_S20_01 subscribeReading_Button fhem/sensors/sonoff_S20_01/in/BtnState
attr Sonoff_S20_01 webCmd 0:5:15:60:900:3600:36000

PS: das mit der attrTemplates hört sich spannend an. Wo kann ich diese finden oder wie setze ich diese ein?

[Beta-User]

@dirk.k: Die Frage ging dahin, wie das mit MQTT2(_DEVICE) geht, bzw. wie man vorgeht, wenn man nicht TYPE=MQTT als IO-Device nutzt, sondern MQTT2_CLIENT .

Zu der template-Sache findest du Hinweise hier: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele. Das funktioniert aber noch nicht so ohne weiteres mit Geräten des Typs MQTT_DEVICE.

Wenn es aber darum gehen sollte, z.B. Werte, die man in  einem Temperatursensor in FHEM_1 erhält dann direkt auch an FHEM_2 via MQTT zu schicken (die dann typischerweise dort in einem Reading eines MQTT2_DEVICE landen), dann kann man das via notify mit direktem publish oder via set+setList machen, oder man nutzt eben die MQTT_GENERIC_BRIDGE, die mit beiden Arten von IO's funktioniert... Geht alles als "Alternativweg" zu FHEM2FHEM.

@volschin: Wäre nett, wenn du etwas näher erläuterst, was du eigentlich erreichen willst, dann erübrigt sich die Raterei. hexenmeister hat übrigens einen Thread hier am laufen mit typischen Anwendungsfällen für das Modul.

[volschin]

@Beta-User: Ja, wahrscheinlich war ich nicht konkret genug. Das von Dir beschriebene Szenario passt glaube ich gut.

Ich habe in FHEM1 eine stinknormales Sensordevice

Code Auswählen Erweitern

Internals:
   FAIL       0
   FUUID      5d171a34-f33f-80dd-d520-6196feaf23139357
   ID         001:004
   INTERVAL   300
   LAST_POLL  2019-10-04 16:15:22
   NAME       RPi110_AQ_iAM01
   NOTIFYDEV  global
   NR         19
   NTFY_ORDER 50-RPi110_AQ_iAM01
   RECONNECT  0
   SERIALNUMBER
   STATE      710 ppm (2019-10-04 16:15:22)
   TYPE       CO20
   manufacturer AppliedSensor
   product    iAQ Stick
   READINGS:
     2017-06-03 09:56:56   debug           760
     2017-06-03 09:56:56   pwm             386
     2017-06-03 09:56:56   r_h             156.9
     2017-06-03 09:56:56   r_s             411089
     2019-10-04 16:15:22   state           open
     2019-10-04 16:15:22   voc             710
   helper:
     defined    none
     retries    3
     seq2       169
     seq4       1
     timeout    10000
Attributes:
   event-on-update-reading voc
   room       Sensor
   stateFormat {ReadingsVal("RPi110_AQ_iAM01","voc","")." ppm (".ReadingsTimestamp("RPi110_AQ_iAM01","voc",""). ")"}
   timeout    10000

Dessen Daten sollen nach FHEM2. Ich habe dafür aktuell übrigens FHEM2FHEM im Einsatz und möchte das ablösen. Dass dazu in FHEM2 ein MQTT2_DEVICE rein muss, das dann meinen aktuellen cloneDummy ablöst, ist mir klar.

Wie bekomme ich die Daten aus dem Sensor am Besten nach MQTT?

Auf den MQTT_GENERIC_BRIDGE bin ich gestoßen und davon ausgegangen, dass der für MQTT2 nicht einsetzbar ist.

[Beta-User]

@Volschin: Danke für die Klarstellung. Richtig ist: MQTT_GENERIC_BRIDGE kann seit längerem (knappes Jahr oder so) mit allen drei IO-Typen eingesetzt werden.

Wäre also hier daher m.E. das Mittel der Wahl, damit lassen sich auch MQTT-spezifische Einstellungen m.E. am einfachsten lösen (wie QoS-Level usw.); Oder eben doch ein eigener Eventhandler für's publishen, wenn's nur um ein paar Werte geht.

[volschin]

Danke für den Schubs. [emoji3][emoji106]
Ich werde das dann mal in der vorgeschlagenen Richtung probieren.

[volschin]

Ich habe das Publishen am Laufen, umgesetzt mit MQTT_GENERIC_BRIDGE. Alles sehr logisch zu implementieren.

Einen Schönheitsfehler hat das Ganze. Während MQTT2 ohne zusätzliche per cpan zu kompilierende Module funktioniert, muss man für die Bridge dann doch wieder Net::MQTT selbst bauen. Auf einem Raspi v1 dauert das.