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
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
Fuer das MQTT2_DEVICE das setList Attribut passend setzen.
Alternativ einen der vielen attrTemplates anschauen/anwenden.
Kann es sein, dass du nach der Funktion von MQTT_GENERIC_Bridge suchet?
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)
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)
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?
@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.
@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
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.
@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.
Danke für den Schubs. [emoji3][emoji106]
Ich werde das dann mal in der vorgeschlagenen Richtung probieren.
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. ::)