Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

[hexenmeister]

@Master_Nick
Mit MQTT funktioniert Retain definitiv. Habe zwar nicht mit NodeRed getestet, sondern mit MQTT-Spy. Sende ich etwas mit Retain, dann wird eine neue Lasche, die danch geöffnet wird und diese (oder alle) Topics aboniert gleich mit diesem Wert beliefert. Sende ich ohne Retain, passiert das nicht.

[hexenmeister]

Hallo zusammen,

folgendes Problem,

ein Dummy ist wie folgt definiert:

Code Auswählen Erweitern

define display dummy
  attr display userReadings rechteck
  attr display mqttPublish rechteck:topic=/display1/rectangle
 
dazu gibt es ein notify, welches das userReading rechteck des dummy display verändert sobald state des dummy display auf 1 gesetzt wird:

Code Auswählen Erweitern

define display_notify_1 notify display:1 setreading display rechteck 1,1,10,10,50000


das notify funktioniert auch soweit und setzt das userReading rechteck des dummies auf den gewünschten Wert. Allerdings wird der Wert nicht gepublisht.

Setze ich jedoch im Webinterface von fhem mit dem gleichen Befehl des notifys,

Code Auswählen Erweitern

setreading display rechteck 1,1,10,10,50000

so wird gepublisht.

Hab ich irgendwo einen Denkfehler?

VG

joschi2009

sehr komisch. Muss ich nachstellen...

[Master_Nick]

Okay dann muss ich mal analysieren.

Also mit dem wie ich es da eingestellt habe passt es laut dir?

Code Auswählen Erweitern

mqttDefaults base={"homeland/haushalt/heizung/$device"} pub:qos=2 sub:qos=2 retain=1
   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 valvePosition:topic={"$base/$name"} valvePosition:qos=2 valvePosition:retain=1
   mqttSubscribe desiredTemperature:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set desiredTemperature:qos=2 boost:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/boost/set boost:qos=2

[hexenmeister]

Habe gerade genau dein Code-Schnippsel verwendet mit einem Dummy. Dann disiredTemperature gesetzt und danach mit mosquitto_sub abgefragt.

Code Auswählen Erweitern

$ mosquitto_sub -h 192.168.0.15 -t homeland/haushalt/heizung/testr/desiredTemperature
12
^C

Prompt kam der Wert. Dann den Wert gelöscht.

Code Auswählen Erweitern

mosquitto_pub -t homeland/haushalt/heizung/testr/desiredTemperature -n -r
Schon kommt nicht mehr.

Testdummy:

Code Auswählen Erweitern

defmod testr dummy
attr testr mqttDefaults mqttDefaults base={"homeland/haushalt/heizung/$device"} pub:qos=2 sub:qos=2 retain=1
attr testr 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 valvePosition:topic={"$base/$name"} valvePosition:qos=2 valvePosition:retain=1
attr testr mqttSubscribe desiredTemperature:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set desiredTemperature:qos=2 boost:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/boost/set boost:qos=2
attr testr readingList desiredTemperature
attr testr room TEST_Reported
attr testr setList desiredTemperature

[Master_Nick]

Dann muss der Fehler in meinem function Block liegen, dass ich einfach von einer Abarbeitung ausgehe die so nicht stattfindet :-D

Danke für deine Mühe!

[Dersch]

Hi,

ich stelle grade komplett von FHEM2FHEM und RFHEM auf MQTT um (und da ist so einiges). Klappt mit Sensoren auch wunderbar welche einfach nur ihre Readings  zum Broker werfen sollen auch deren State erhalte ich problemlos.

Ich beisse mir nur grade an schaltbaren devices die Zähne aus deren state zu erhalten

Hier mal ein bsp Device:

Code Auswählen Erweitern

Internals:
   DEF        MCP23017:PortB4
   DEVICE     MCP23017
   NAME       GarageLicht
   NOTIFYDEV  MCP23017,global
   NR         36
   NTFY_ORDER 50-GarageLicht
   READING    PortB4
   STATE      off
   TYPE       readingsProxy
   CONTENT:
     MCP23017   1
   READINGS:
     2019-01-05 02:14:54   lastCmd         off
     2019-01-05 01:28:41   state           off
Attributes:
   group      MCP23017 Outputs
   mqttPublish *:topic={"garage/GarageLicht/$reading"}
   mqttSubscribe state:stopic={"garage/GarageLicht/set"}
   room       GPIO-Devices
   setFn      {($CMD eq "on")?"PortB4 off":"PortB4 on"}
   setList    on off
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
   valueFn    {($VALUE eq "on")?"off":"on"}

Und hier das Device als MQTT_CLIENT:

Code Auswählen Erweitern

Internals:
   CFGFN     
   IODev      mqtt
   NAME       GarageLicht
   NR         30848
   STATE      off
   TYPE       MQTT_DEVICE
   qos        *:2
   OLDREADINGS:
   READINGS:
     2019-01-05 01:27:02   state           off
     2019-01-05 01:27:02   transmission-state outgoing publish completed
   message_ids:
   publishSets:
     :
       topic      garage/GarageLicht/set
       values:
         on
         off
         toggle
         on-for-timer
         off-for-timer
   sets:
     off       
     off-for-timer
     on         
     on-for-timer
     toggle     
   subscribe:
     garage/GarageLicht/state
   subscribeExpr:
     ^garage\/GarageLicht\/state$
   subscribeQos:
     garage/GarageLicht/state 0
   subscribeReadings:
     garage/GarageLicht/state:
       cmd       
       name       state
Attributes:
   IODev      mqtt
   cmdIcon    on:general_an off:general_aus
   group      Licht
   icon       light_ceiling
   publishSet on off toggle on-for-timer off-for-timer garage/GarageLicht/set
   qos        2
   room       Garage
   subscribeReading_state garage/GarageLicht/state

Kann mir wer helfen wo da mein Fehler ist?

[freddie]

Bist Du sicher, daß Du nicht das publish und das subscribe vertauscht hast?

Attributes:
   group      MCP23017 Outputs
   mqttPublish *:topic={"garage/GarageLicht/$reading"}
   mqttSubscribe state:stopic={"garage/GarageLicht/set"}

[Master_Nick]

Hehe ja das vertauscht man gerne mal.

Wobei ich in meinem Setup auch den Fall habe, dass je nachdem wer am Ende das Device schaltet (FHEM oder eben ein ESP8266 der im Wifi ist) dann ist das set entweder als publish (garage/GarageLicht/set) (wie es die Regel ist) oder aber wenn  FHEM einen Device schaltet der z. B. 433 Mhz wäre dann wäre das publish garage/GarageLicht/$reading.


Ich denke man kann das immer ganz schön so erklären oder sich selber verdeutlichen.
Den aktuellen Zustand eines Gerätes erfährt man auf "garage/GarageLicht/" und Schaltbefehle gehen gegen "garage/GarageLicht/set". Wenn nun aber so spezial Krams dazu kommt wie ein Gerät hat kein eigenes MQTT sondern FHEM schaltet da was völlig eigenes. Dann muss man halt nochmal ne Ecke mehr mit bedenken


@Dersch so wirklich 100% klar was sagen, kann ich bei deinem Beispiel nur, wenn ich die Seite des Garagenlichts kennen würde also die Config der Topics auf der Seite (Achtung Wifi Config meist mit enthalten)

Eines fällt mir aber direkt auf.

Bei mir würde es immer wenn das eine "garage/GarageLicht/$reading" ist beim set "garage/GarageLicht/$reading/set" lauten.

[christiantf]

Hallo,

ich würde mich freuen, wenn mir bezüglich dem globalen Subscribe jemand helfen könnte.
Ich bin mir nicht sicher, ob das in der aktuellen Version (deren Versionsnummer ich im übrigen auch nirgends gefunden habe, jedenfalls der letzte 'update'-Stand) schon funktioniert.

Aktuell erstelle ich die MQTT_GENERIC_BRIDGE und bekomme alles auf den Broker:

Code Auswählen Erweitern


define mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev lb_mosquitto
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"}


Jedoch habe ich den generischen umgekehrten Weg nicht gefunden. Ehrlich gesagt bin ich erschlagen vor Optionen bei mqttSubscribe, und weiß noch nicht mal, ob das überhaupt das richtige ist.

Im Prinzip möchte ich einfach nur generisch, für alle in FHEM angelegten Geräte, ein SET über MQTT auslösen. Muss ich da jetzt für jedes einzelne Gerät jetzt ein eigenes Topic erstellen, damit ich einen Befehl empfangen kann, oder geht das generisch, und wenn, wie würde so eine Zeile ausschauen.

Exemplarisch habe ich eine HS100-Steckdose

Code Auswählen Erweitern


define Kueche_HS100 TPLinkHS110 192.168.1.2


Via Broker möchte ich jetzt sowas publishen wie
set/fhem/Kueche_HS100 = on
Gleichermaßen sollte das auch bei anderen Devices funktionieren beispielsweise
set/fhem/NUKIDevice1234 = lock

Wie müsste so eine generische Subscription aussehen? Ich werde leider aus der Doku nicht schlau.

Danke und viele Grüße,
Christian

[hexenmeister]

Die Doku sagt:

globalSubscribe ! TODO - wird derzeit nicht unterstuetzt und wird moeglicherweise gar nicht implementiert !

Und genau so ist es auch. Ich habe diese Feature angedacht, aber nicht fertiggestellt. Ehrlich gesagt, halte ich so ein globales 'Setzen' für etwas gefählich, man kann sich damit schnell Sicherheitslücken 'einbauen'. Daher bin ich mir nicht sicher, ob ich es wirklich machen soll. Es ist aus meiner Sicht besser, nur die Geräte damit bestücken, die man wirklich schalten will. Da es sich um einen eimaligen Aufwand handelt  (viel Copy-Paste), halte ich es für vertretbar.

[bismosa]

Hallo!
Sorry...ich werde auch irgendwie nicht ganz schlau daraus.
Ich mache gerade meine ersten gehversuche mit MQTT. Ich möchte gerne das Dashboard von Node-RED ausprobieren.
Ich habe eine Definition:

Code Auswählen Erweitern


defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev MQTT
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric globalPublish *:topic={"/fhem/$device/$reading"}

Und lasse mir alle Events in FHEM übermitteln. Diese kommen auch problemlos in Node-Red an.

Sehe ich das richtig, dass dieser Weg zu viele Events erzeugt? Und die Systemauslastung dadurch stark ansteigt? Wie ist denn dann der empfohlene Weg? Nur die wirklich benötigten Readings alle einzeln hinterlegen? Oder für jedes Device dann eine eigene MQTT_GENERIC_BRIDGE?

Ich habe im EventMonitor gesehen, dass die Bridge ebenfalls viele Events erzeugt. Diese sind doch eigentlich für die Funktion niht weiter relevant...oder? Dann könnte ich diese deaktivieren.

Das Empfangen der Nachrichten habe ich ebenfalls noch nicht verstanden. Die generische Subscription ist nicht eingebaut. Das hatte ich gelesen. Aber der Weg über mqttSubscribe sollte doch eigentlich funktionieren?
Ich bekomme hier nur "this attribute is not allowed here" sobald ich versuche etwas einzutragen.

Vielen Dank für dieses Modul!

Gruß
Bismosa

[hexenmeister]

globalPublish erzeugt zu viele Events, da vieles übertragen wird, was nicht weiter von Interesse ist. Man kann ggf. etwas mit Exclude ausfiltern.
Systemlast? Je nach Installationsgröße, aber trotzdem unnötig.

Eine Bridge reicht völlig aus. Definiere die benötigten Readings für publish und subscribe (mittels mqttPublish und mqttSubscribe) direkt in den betroffenen Devices, nicht in der Bridge selbst.

[bismosa]

Hallo!

Danke für die schnelle Antwort. Nun ist der Groschen gefallen.
Im Test ist meine Systemlast sehr gering. Frische Installation nur mit MQTT und einem Dummy auf einer Virtuellen Maschine auf dem PC zum testen. Daher interessiert mich das...damit ich später nicht darauf reinfalle.
Ich bin nicht darauf gekommen, dass ich die Readings in den entsprechenden Devices setzen muss. Damit klappt es auf Anhieb! Danke!

Nun kann ich weiter testen.

Gruß
Bismosa

[Billy]

Meine Frage betrifft das mapping von state.

Hintergrund:
wenn ich bei einem Dummy z.B. normal state mit

Code Auswählen Erweitern

mqttPublish state:topic=cmnd/sonoff_pw2/POWER1 publishe

ist das Ergebnis in Mosquitto z.B. on oder off

wenn ich im Dummy -->

Code Auswählen Erweitern

eventMap used:on stop:off setze dann wird wie gewünscht
mit

Code Auswählen Erweitern

mqttPublish state:topic=cmnd/sonoff_pw2/POWER1 used und stop zum Mosquitto gepublished

Bei einem Homematic Switch z.B. HM-LC-SW1-PL2 geht das mit dem eventMap nicht.
Da behelfe ich mir mit einem notify das dieses mapping zu mosquitto macht.

Wäre es denkbar dieses state mapping in die MQTT_GENERIC_BRIDGE einzubauen oder gibt es das schon?
Habe ich was übersehen oder gibt es eine andere einfache Lösung.

Billy

[hexenmeister]

Kann leider nichts dazu sagen. eventMap ist ja genau dafür da, warum das bei HM-Device nicht funktioniert müsste man in einem entsprechenden Forum-Zweig fragen.
Ansonsten könnte man das mit der Bridge mit hilfe von 'expression' (s. Commandref) schon bewerkstelligen. Auch wenn das nicht dafür gedacht war.