MQTT veröffentlicht state von Rolladen nicht

[Atomius]

Moin zusammen,

ich bin gerade dabei meine Dooya Rolladenmotoren in fhem via MQTT an openhab2 anzubinden. Commandseitig funktioniert das Ganze schon super. Jetzt würde ich noch gern den state der Rolladen anzeigen, allerdings wird dieser schon im broker nicht angezeigt. Anbei meine MQTT Bridge Konfiguration und ein Blick auf den Broker. Wie man sieht, funktionieren die Command Befehle perfekt, der Rolladen reagiert auch darauf, aber das Ganze "state" Topic ist im Broker gar nicht vorhanden. Wo muss ich ansetzen?

Vielen Dank schon einmal im Voraus

Gruß

[Beta-User]

Wenn du ein list liefern würdest statt des screenshots, könnte man erkennen, ob state überhaupt vorhanden ist (vermutlich nicht). (afaik wird nur gepublisht, was als Event kommt).

Bißchen OT: Gibt es einen Grund, warum du hier MQTT_BRIDGE nutzt und nicht direkt MQTT_GENERIC_BRIDGE? Das doyaa-Device wird ja vermutlich nicht das einzige FHEM-Gerät bleiben, das mit openHAB kommunizieren können soll .

[Atomius]

Nein, ich bin einfach nur Stumpf nach dieser Anleitung vorgegangen, da sich entsprechende Anleitungen für diese Kombination leider in Grenzen halten:

https://community.openhab.org/t/rademacher-duofern-via-fhem-and-mqtt/26322

Du empfiehlst also einen Wechsel des Typs? Kannst du etwas näher erläutern was für Vorteile das bringt? Das Attribut publishReading gibt es in der Generic Brigde ja nicht mehr, wodurch wird das dann ersetzt?

Hier die Bridge als Liste:

Code Auswählen Erweitern

defmod mqtt_Rolladen_Wohnzimmer MQTT_BRIDGE Rolladen_Wohnzimmer
attr mqtt_Rolladen_Wohnzimmer IODev mosquitto
attr mqtt_Rolladen_Wohnzimmer publish-topic-base state/fhem/Rolladen_Wohnzimmer/
attr mqtt_Rolladen_Wohnzimmer publishReading_exact state/fhem/Rolladen_Wohnzimmer/exact
attr mqtt_Rolladen_Wohnzimmer publishReading_parsestate state/fhem/Rolladen_Wohnzimmer/parsestate
attr mqtt_Rolladen_Wohnzimmer publishReading_position state/fhem/Rolladen_Wohnzimmer/position
attr mqtt_Rolladen_Wohnzimmer publishReading_state state/fhem/Rolladen_Wohnzimmer/state
attr mqtt_Rolladen_Wohnzimmer subscribeSet_off set/fhem/Rolladen_Wohnzimmer/off
attr mqtt_Rolladen_Wohnzimmer subscribeSet_on set/fhem/Rolladen_Wohnzimmer/on
attr mqtt_Rolladen_Wohnzimmer subscribeSet_position set/fhem/Rolladen_Wohnzimmer/position
attr mqtt_Rolladen_Wohnzimmer subscribeSet_stop set/fhem/Rolladen_Wohnzimmer/stop

setstate mqtt_Rolladen_Wohnzimmer 2019-07-11 15:45:01 transmission-state incoming publish received


Hier die RAW Definition des eigentlichen Gerätes:

Code Auswählen Erweitern


defmod Rolladen_Wohnzimmer Dooya xxxxxxxxx_1
attr Rolladen_Wohnzimmer IODev sduino433
attr Rolladen_Wohnzimmer event-min-interval .*:300
attr Rolladen_Wohnzimmer event-on-change-reading .*
attr Rolladen_Wohnzimmer room Dooya

setstate Rolladen_Wohnzimmer closed
setstate Rolladen_Wohnzimmer 2019-07-11 15:45:01 exact closed
setstate Rolladen_Wohnzimmer 2019-07-02 23:45:24 parsestate on
setstate Rolladen_Wohnzimmer 2019-07-11 15:45:01 position 200
setstate Rolladen_Wohnzimmer 2019-07-11 15:45:01 state closed


[Beta-User]

Du empfiehlst also einen Wechsel des Typs?

Jein. Genauer: Wenn du neu in das Thema einsteigst: Ja. MQTT_DEVICE ist älter und für eine 1:1 Weitergabe an einen MQTT-Server gemacht, MQTT_GENERIC_BRIDGE ist neuer und kann (dasselbe, aber) 1:n (und das mit allen IO-Typen, die FHEM derzeit kennt).

Vielleicht schaust du dir im Wiki den MQTT-Artikel an (der genau so heißt), da ist ziemlich aktuell, aber evtl. noch überarbeitungswürdig, der aktuelle Stand der Dinge dargestellt, was FHEM und MQTT angeht, und da ist auch der Entstehungsthread sowie der Thread des Modulautors mit Beispielanwendungen verlinkt.

Ich habe das zwar jüngst wesentlich überarbeitet, aber grade die MGB ist noch etwas stiefmütterlich, da ich wenig Erfahrung damit habe (das aber eigentlich m.E. selbsterklärend ist, wenn man mal verstanden hat, wie MQTT an sich tickt...)

Hier die Bridge als Liste:

Das nennen wir hier RAW-Definition (ein list ist was anderes, siehe "help list" im Kommandofeld) und ist häufig (v.a. auch bei MQTT) fast genauso aufschlußreich (aber nicht immer...). Hier würde ich aber annehmen, dass MQTT_BRIDGE schlicht - wie viele andere Eventhandler auch - mit state-Events etwas anders umgeht (und dafür ein eigenes/anderes Attribut benötigt - sieh mal in die commandref zu diesem Modul, dann wird das evtl. etwas klarer, wichtig ist nur, dass du dir merkst, dass das "state"-Reading etwas "speziell" ist). Kann sein, dass das auch bei MQTT_GENERIC_BRIDGE zu beachten ist, aber dazu kommen wir dann, wenn du umgestellt hast und nicht weiterkommen solltest.

[Atomius]

Okay, das ist doch schon mal sehr hilfreich. Ich habe nun eine neue GENERIC_MQTT_BRIDGE erstellt in der alle Rolladen enthalten sind die angesteuert werden sollen:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        mqtt Rolladen_Wohnzimmer,Rolladen_Arbeitszimmer,Rolladen_Schlafzimmer
   FUUID      5d275533-f33f-d224-52e2-d15d6950e377074f
   NAME       mqttGenericRolladen
   NR         205
   NTFY_ORDER 50-mqttGenericRolladen
   STATE      ???
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    Rolladen_Wohnzimmer,Rolladen_Arbeitszimmer,Rolladen_Schlafzimmer
   prefix     mqtt
   READINGS:
     2019-07-11 17:39:55   device-count    0
     2019-07-11 17:26:43   incoming-count  0
     2019-07-11 17:26:43   outgoing-count  0
     2019-07-11 17:39:55   transmission-state unknown IO device
     2019-07-11 17:26:43   updated-reading-count 0
     2019-07-11 17:26:43   updated-set-count 0
   devices:
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
Attributes:
   IODev      1


jetzt benötige ich noch die Attribute für die einzelnen Geräte. In der Doku ist die Rede von "mqttPublish" was ich ja brauche, um meinen State auf einen Channel zu bringen. Dieses Attribut gibts es aber (auch nach einem update) nicht. Welche Attribute muss ich nun nutzen, um den State der Dooyas zu publishen und SET Commands auszuführen, sodass ich die alten Brücken löschen kann?

[Beta-User]

Die subscribe- und publish-Attribute werden nicht bei der MQTT_GENERIC_BRIDGE gesetzt (da sind dann lediglich ein paar defaults drin), sondern sind dann in den zu "ver-MQTT-enden" Devices zu finden, bei dir also Rolladen_Wohnzimmer usw.. Das ist gerade der "Trick" bei der Sache, dass alles, was zueinander gehört, auch beieinander ist und man auch die topics mit Variablen (wie dem Gerätenamen und Raum) automatisiert zusammenbasteln lassen kann, indem man sie an einer zentralen Stelle einmalig festlegt...)

Bitte dazu unbedingt den bereits genannten aufschlußreichen Thread von hexenmeister mal durchgehen!

[DasQ]

Ich würd des nicht nach so einer veralteten Methode machen.

Warum nutzt du nicht MQTT2_SERVER?

[Beta-User]

Für das hier ist das doch völlig egal... (Kurz da mobil)

[Atomius]

Ich würd des nicht nach so einer veralteten Methode machen.

Warum nutzt du nicht MQTT2_SERVER?

wie würde das Ganze denn mit diesem Modul aussehen?

[Beta-User]

Das Modul ersetzt mosquitto und das io-modul 00_MQTT.pm. Das bringt dich aber nicht weiter hinsichtlich der Rollläden.=> befasste dich ggf. damit, wenn das andere läuft.
@DasQ: m.E. für den Moment eher ein verwirrender Hinweis an den TE...

[Atomius]

Okay ich muss sagen die Syntax Beschreibung des Attributes ist eher verwirrend für mich.

Code Auswählen Erweitern


Examples:
attr <dev> mqttPublish temperature:topic={"$base/$name"} temperature:qos=1 temperature:retain=0 *:topic={"$base/$name"} humidity:topic=/TEST/Feuchte
attr <dev> mqttPublish temperature|humidity:topic={"$base/$name"} temperature|humidity:qos=1 temperature|humidity:retain=0
attr <dev> mqttPublish *:topic={"$base/$name"} *:qos=2 *:retain=0
attr <dev> mqttPublish *:topic={"$base/$name"} reading:expression={"message: $value"}
attr <dev> mqttPublish *:topic={"$base/$name"} reading:expression={$value="message: $value"}
attr <dev> mqttPublish *:topic={"$base/$name"} reading:expression={"/TEST/Topic1"=>"$message", "/TEST/Topic2"=>"message: $message"}
attr <dev> mqttPublish *:resendOnConnect=last
attr <dev> mqttPublish temperature:topic={"$base/temperature/01/value"} temperature!json:topic={"$base/temperature/01/json"} temperature!json:expression={toJSON({value=>$value,type=>"temperature",unit=>"°C",format=>"00.0"})}


Wie müssen denn die beiden Attribute aussehen, die:

1.) Den state des Rolladen, also "opened" oder "closed" an das topic "state/Rolladen_Wohnzimmer/" senden?
2.) Den set Befehl definieren der "on" oder "off" an das Topic "set/Rolladen_Wohnzimmer" entgegen nimmt?

[Beta-User]

Vorab: Das list des mqttGenericRolladen enthält kein gültiges IODev (steht auf 1). Dem list des  mqtt_Rolladen_Wohnzimmer entnehme ich, dass du das IODev "mosquitto" genannt hast (für dieses IODev gilt: TYPE=MQTT).
Also:

Code Auswählen Erweitern

Attr  mqttGenericRolladen IODev mosquitto
Dann:
Den Thread https://forum.fhem.de/index.php/topic,91642.msg841367.html#msg841367 hast du gefunden und die ersten Beiträge mal gelesen?
Da findet sich z.B. sowas (für einen on/off Aktor):

Code Auswählen Erweitern

attr <actor-device-name> mqttPublish state:topic=haus/wohnzimmer/licht/top/state
attr <actor-device-name> mqttSubscribe state:stopic=haus/wohnzimmer/licht/top/setDas sollte doch nicht sooo schwer zu übertragen sein, selbst wenn einem die ganze FHEM-Welt recht neu ist. Aber gut, versuchs mal mit dem hier:

Code Auswählen Erweitern

attr Rolladen_Wohnzimmer mqttPublish state:topic=state/Rolladen_Wohnzimmer
attr Rolladen_Wohnzimmer mqttSubscribe state:stopic=set/Rolladen_WohnzimmerDu mußt dabei den Namen nicht unbedingt "hart" reinvercoden, sondern das müßte sich auch durch "$device" ersetzen lassen (das scheint hier die Schreibweise zu sein, üblich wäre eigentlich "$name"). Das ergäbe:

Code Auswählen Erweitern

attr Rolladen_Wohnzimmer mqttSubscribe state:stopic=set/$device

[hexenmeister]

$name geht anstatt $device auch. Hat eine Besonderheit, die hier jedoch nicht relevant ist.

[Atomius]

Klasse, vielen Dank für die schnelle und kompetente Hilfe. Die alten Bridges sind gelöscht, das Prinzip die Abstraktion der MQTT-Bridge eine Ebene nach oben zu verlagern hab ich jetzt auch gerafft und die Attribute sind nun in den einzelnen Geräten. Die Steuerung funktioniert nach wie vor perfekt, jetzt ist der Command auch tatsächlich die Message selbst und nicht das Topic so wie es sein soll. Leider sehe ich aber auf dem MQTT-Broker mit dem MQTT-Explorer kein state topic, auch bei einer Änderung des States nicht, haben wir noch was übersehen?

Hier nochmal mein Rolladen Device:

Code Auswählen Erweitern


Internals:
   CHANNEL    1
   DEF        xxxxx
   FUUID      5c4f4afe-f33f-d224-017f-d1aa4e9925b035c2
   ID         xxxxx
   IODev      sduino433
   NAME       Rolladen_Wohnzimmer
   NR         24
   STATE      open
   TYPE       Dooya
   exact      open
   move       off
   position   0
   CODE:
     1          xxxxxxxx
   READINGS:
     2019-07-13 16:21:37   exact           open
     2019-07-02 23:45:24   parsestate      on
     2019-07-13 16:21:37   position        0
     2019-07-13 16:21:37   state           open
Attributes:
   IODev      sduino433
   event-min-interval .*:300
   event-on-change-reading .*
   mqttPublish state:topic=state/Rolladen_Wohnzimmer
   mqttSubscribe state:stopic=set/Rolladen_Wohnzimmer
   room       Dooya
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long


Und die Bridge:

Code Auswählen Erweitern


Internals:
   DEF        mqtt Rolladen_Wohnzimmer,Rolladen_Arbeitszimmer,Rolladen_Schlafzimmer
   FUUID      5d275533-f33f-d224-52e2-d15d6950e377074f
   IODev      mosquitto
   NAME       mqttGenericRolladen
   NR         104
   NTFY_ORDER 50-mqttGenericRolladen
   STATE      ???
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    Rolladen_Wohnzimmer,Rolladen_Arbeitszimmer,Rolladen_Schlafzimmer
   prefix     mqtt
   READINGS:
     2019-07-13 16:15:49   device-count    3
     2019-07-13 16:15:41   incoming-count  0
     2019-07-13 16:15:41   outgoing-count  0
     2019-07-13 16:15:49   transmission-state subscription acknowledged
     2019-07-13 16:15:41   updated-reading-count 0
     2019-07-13 16:15:41   updated-set-count 0
   devices:
     Rolladen_Arbeitszimmer:
       :publish:
         state:
           mode       R
           topic      state/Rolladen_Arbeitszimmer
       :subscribe:
         HASH(0x31dac98)
     Rolladen_Schlafzimmer:
       :publish:
         state:
           mode       R
           topic      state/Rolladen_Schlafzimmer
       :subscribe:
         HASH(0x31dae78)
     Rolladen_Wohnzimmer:
       :publish:
         state:
           mode       R
           topic      state/Rolladen_Wohnzimmer
       :subscribe:
         HASH(0x31d8008)
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
   message_ids:
   subscribe:
     set/Rolladen_Wohnzimmer
     set/Rolladen_Arbeitszimmer
     set/Rolladen_Schlafzimmer
   subscribeExpr:
     ^set\/Rolladen_Wohnzimmer$
     ^set\/Rolladen_Arbeitszimmer$
     ^set\/Rolladen_Schlafzimmer$
   subscribeQos:
     set/Rolladen_Arbeitszimmer 0
     set/Rolladen_Schlafzimmer 0
     set/Rolladen_Wohnzimmer 0
Attributes:
   IODev      mosquitto


[Beta-User]

  Danke für das Feedback und die Rückmeldung, dass fast alles klappt, wie es soll.

Vielleicht zwei Anmerkungen:
"state" ist in FHEM ein ziemlich besonderes "Reading", es könnte sein, dass hier - wie sonst auch recht häufig - schlicht kein "Event" ausgelöst wird, das dann zu einer Reaktion führt.
Hier kommt hinzu, dass bei einem direkten Publish immer das Risiko besteht, dass man sich unbeabsichtigt eine Dauerschleife baut, was durch die Module in der Regel versucht wird zu verhindern.

(Bei der "normalen" Bridge ist der erste Punkt vermutlich der Grund, warum es ein gesondertes "state"-Publish gibt, über das du ja schon gestolpert warst, wenn ich das richtig zuordne).

Behalte das im Hinterkopf, dann kannst du evtl. mal in der cref suchen, ob da was ähnliches für die Generic-Bridge gibt; ansonsten könnte auch eine Lösung sein, das "exact"-Reading (als "state"?) zu publishen.

EDIT: wenn du "fertig" bist, wäre es evtl. sinnvoll, bei der Anleitung im openhab-Forum darauf hinzuweisen, dass die dortige Anleitung zwar funktioniert, jetzt aber auch der Weg über die Generic-Bridge offen steht (was m.E. an sich einfacher ist, wenn man das Konzept mal verstanden hat).