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ß
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 ;) .
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:
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:
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
Zitat von: Atomius am 11 Juli 2019, 16:46:32
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...)
ZitatHier 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.
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:
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?
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!
Ich würd des nicht nach so einer veralteten Methode machen.
Warum nutzt du nicht MQTT2_SERVER?
Für das hier ist das doch völlig egal... (Kurz da mobil)
Zitat von: DasQ am 11 Juli 2019, 18:08:16
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?
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...
Okay ich muss sagen die Syntax Beschreibung des Attributes ist eher verwirrend für mich.
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?
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: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):attr <actor-device-name> mqttPublish state:topic=haus/wohnzimmer/licht/top/state
attr <actor-device-name> mqttSubscribe state:stopic=haus/wohnzimmer/licht/top/set
Das 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:
attr Rolladen_Wohnzimmer mqttPublish state:topic=state/Rolladen_Wohnzimmer
attr Rolladen_Wohnzimmer mqttSubscribe state:stopic=set/Rolladen_Wohnzimmer
Du 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:attr Rolladen_Wohnzimmer mqttSubscribe state:stopic=set/$device
$name geht anstatt $device auch. Hat eine Besonderheit, die hier jedoch nicht relevant ist.
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:
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:
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
:) 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).
Ja sicher, wenn alles so läuft wie es soll, werd ich beide Freds updaten und auch untereinander verlinken, wenn das hier erwünscht ist.
Also mit dem Attribut:
exact:topic=state/Rolladen_Wohnzimmer
Wird der state tatsächlich bei Änderung gepublished. Allerdings nur, wenn ich die manuellen Fernbedienungen der Rolladen nutze. Wird der State des Rolladen via MQTT geändert, so wird nichts gepublished. Irgendwie scheint das kein Event auszulösen.
Weiß nicht, ob das hilft, aber du kannst ja state auch zusätzlich publishen:
exact|state:topic=state/Rolladen_Wohnzimmer
So wie ich die Einstellmöglichkeit im Attribut "
ja, ob einzeln eingetragen oder mit | verknüpft macht leider keinen Unterschied, er published den state nach wie vor nur wenn er über die Fernbedienung geändert wurde, nicht über MQTT.
Hm, sonst bleiben mir nicht mehr viele Möglichkeiten oder?
Hmm, irgendwie hatte es einen Teil meiner Antwort nicht ins Forum geschafft...
setze mal mqttForward am Rolladen_Wohnzimmer auf all. (Sollte eigentlich für Doyaa-TYPE der default sein, aber sicher ist sicher).
Ansonsten müssen wir warten, was hexenmeister dazu ggf. noch einfällt...
auch mit mqttForward leider kein Glück bei einer Statusänderung des Rolladen via MQTT. Sobald ich auf der Fernbedienung schalte, erscheint das state topic sofort auf dem Broker. Ich hoffe auch das der Hexenmeister noch eine Idee hat..