HM-LC-Bl1PBU-FM via MQTT steuern

[cmonty14]

Hallo,

ich möchte das Device HM-LC-Bl1PBU-FM über MQTT steuern.
Nachdem MQTT2_CLIENT und MQTT_GENERIC_BRIDGE definiert sind kommen diverse Meldungen am MQTT Broker an.

Von dem Device HM-LC-Bl1PBU-FM diese Readings im Broker abrufbar:
fhem_KU.rollladen_commState   CMDs_done   
fhem_KU.rollladen_deviceMsg   100% (to HMUART)   
fhem_KU.rollladen_level   100   
fhem_KU.rollladen_motor   stop:100%   
fhem_KU.rollladen_pct   100   
fhem_KU.rollladen_state  1

Meine Frage ist zunächst:
Wie wird festgelegt, welche Reading dieses Devices in MQTT gesendet wird?

Hier die RAW Definition des Devices:

Code Auswählen Erweitern

defmod KU.rollladen CUL_HM 678E87
attr KU.rollladen .mId 006A
attr KU.rollladen IODev HMUART
attr KU.rollladen autoReadReg 4_reqStatus
attr KU.rollladen devStateIcon 0%:fts_shutter_10@green 100%:fts_shutter_100@red 1\d.*:fts_shutter_10 2\d.*:fts_shutter_20 3\d.*:fts_shutter_30 4\d.*:fts_shutter_40 5\d.*:fts_shutter_50 6\d.*:fts_shutter_60 7\d.*:fts_shutter_70 8\d.*:fts_shutter_80 9\d.*:fts_shutter_90 \d.*:fts_shutter_90
attr KU.rollladen event-on-change-reading .*
attr KU.rollladen eventMap on:100% off:0%
attr KU.rollladen expert defReg,rawReg
attr KU.rollladen firmware 2.11
attr KU.rollladen group Rollladen
attr KU.rollladen icon fts_shutter_1w
attr KU.rollladen model HM-LC-BL1PBU-FM
attr KU.rollladen param levelInverse
attr KU.rollladen peerIDs 00000000
attr KU.rollladen room 80-HomeMatic,10-Kueche,98-Devices
attr KU.rollladen serialNr OEQ2336909
attr KU.rollladen subType blindActuator
attr KU.rollladen webCmd stop:up:0:10:20:30:40:50:60:70:80:90:100:down

setstate KU.rollladen 100%
setstate KU.rollladen 2021-01-21 08:43:36 .R-confBtnTime permanent
setstate KU.rollladen 2021-01-21 08:43:36 .R-intKeyVisib invisib
setstate KU.rollladen 2021-01-21 08:43:36 .R-localResDis off
setstate KU.rollladen 2021-01-21 08:43:37 .R-refRunCounter 0
setstate KU.rollladen 2021-01-21 08:43:37 .R-statusInfoMinDly 2 s
setstate KU.rollladen 2021-01-21 08:43:37 .R-statusInfoRandom 1 s
setstate KU.rollladen 2021-01-21 08:43:37 .R-transmitTryMax 6
setstate KU.rollladen 2021-01-21 19:16:43 .associatedWith KU.rollladen,KU.rollladen
setstate KU.rollladen 2021-01-21 08:43:38 .peerListRDate 2021-01-21 08:43:38
setstate KU.rollladen 2021-01-21 19:16:57 .protLastRcv 20210121191657
setstate KU.rollladen 2021-01-21 18:00:00 CommandAccepted yes
setstate KU.rollladen 2021-01-21 08:43:18 D-firmware 2.11
setstate KU.rollladen 2021-01-21 08:43:18 D-serialNr OEQ2336909
setstate KU.rollladen 2021-01-21 08:43:36 PairedTo 0x4F64E2
setstate KU.rollladen 2021-01-21 08:43:37 R-driveDown 17.5 s
setstate KU.rollladen 2021-01-21 08:43:37 R-driveTurn 1 s
setstate KU.rollladen 2021-01-21 08:43:37 R-driveUp 17.5 s
setstate KU.rollladen 2021-01-21 08:43:36 R-pairCentral 0x4F64E2
setstate KU.rollladen 2021-01-21 08:43:37 R-sign off
setstate KU.rollladen 2021-01-21 08:43:36 RegL_00. 00:00 02:01 0A:4F 0B:64 0C:E2 15:FF 18:00
setstate KU.rollladen 2021-01-21 08:43:37 RegL_01. 00:00 08:00 09:00 0A:00 0B:00 0C:AF 0D:00 0E:AF 0F:0A 10:00 30:06 56:00 57:24
setstate KU.rollladen 2021-01-21 08:44:07 cfgState ok
setstate KU.rollladen 2021-01-21 19:16:57 commState CMDs_done
setstate KU.rollladen 2021-01-21 19:16:57 deviceMsg on (to HMUART)
setstate KU.rollladen 2021-01-21 19:16:57 level 100
setstate KU.rollladen 2021-01-21 19:16:57 motor stop:on
setstate KU.rollladen 2021-01-21 19:16:57 pct 100
setstate KU.rollladen 2021-01-21 19:16:57 recentStateType info
setstate KU.rollladen 2021-01-21 19:16:57 state on
setstate KU.rollladen 2021-01-21 19:16:57 timedOn off

[Beta-User]

Wie in dem anderen Thread bereits erwähnt, braucht es für das Funktionieren bestimmte Einstellungen an der MQTT_GENERIC_BRIDGE:

Code Auswählen Erweitern

defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev lb_mqtt
attr mqttGenericBridge globalDefaults sub:base={"mqttGenericBridge/set"} pub:base={"mqttGenericBridge"}
(falls das Attribut "globalPublish" gesetzt ist: Bitte Löschen..)

Und dazu einige wenige Attribute an dem Rollladen:

Code Auswählen Erweitern

attr KU.rollladen mqttPublish state:topic={"$base"} pct:stopic={"$base/$device/$name"}
attr KU.rollladen mqttSubscribe state:stopic={"$base"} pct:stopic={"$base/$device/$name"}


Auf der Loxberry-Seite wäre dann statt des "FHEM-Klartext-Befehls" dann sowas in der Art zu schreiben:

Code Auswählen Erweitern

"Befehl bei EIN" "mqttGenericBridge/set/KU.rollladen on"
"Befehl für 10%" "mqttGenericBridge/set/KU.rollladen/pct 10"
(leider sind in der Anleitung nur Bilder zu finden, ich hoffe, es ist klar, wo das hingehört; die 2. Zeile ist eine freie Erfindung von mir, leider ist da nirgends dokumentiert, wie man z.B. einen Slider oder sowas in Loxone baut.)

EDIT: Device-Name der MGB geändert; heißt jetzt wie im Nachbarthread

[cmonty14]

Ich habe diese Modifikationen der Attributen der Devices
mqttGenericBridge
und
KU.rollladen
durchgeführt.

Weil es zeitlich gerade passt (Loxone sendet ein http-Befehl zum Schließen von KU.rollladen) habe ich nachgeschaut, ob der MQTT-Broker relevante Topics zu KU.rollladen vorhanden sind.
Der Monitor zeigt allerdings nichts relevantes (Zeitstempel) an, obgleich sich der Status geändert hat (Rollladen ist jetzt geschlossen).

[cmonty14]

Und dazu einige wenige Attribute an dem Rollladen:

Code Auswählen Erweitern

attr KU.rollladen mqttPublish state:topic={"$base"} pct:stopic={"$base/$device/$name"}
attr KU.rollladen mqttSubscribe state:stopic={"$base"} pct:stopic={"$base/$device/$name"}


Ist hier ein Typo?
topic vs. stopic?

[Beta-User]

Ja, aber nur in publish.
Du musst auf jeden Fall aber auch auf der Loxone-Seite was anpassen.
Am besten wäre es, du schaust dir auch den mqtt-Verker direkt mal an (mosquitto_sub, z.B.).

[cmonty14]

Wie in dem anderen Thread bereits erwähnt, braucht es für das Funktionieren bestimmte Einstellungen an der MQTT_GENERIC_BRIDGE:

Code Auswählen Erweitern

defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev lb_mqtt
attr mqttGenericBridge globalDefaults sub:base={"mqttGenericBridge/set"} pub:base={"mqttGenericBridge"}
(falls das Attribut "globalPublish" gesetzt ist: Bitte Löschen..)

Ich habe festgestellt, dass FHEM jetzt nichts mehr an den MQTT-Broker sendet.

Hier die RAW Ausgabe des Device mqttGenericBridge:

Code Auswählen Erweitern

defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev lb_mqtt_broker
attr mqttGenericBridge alias MQTT Generic Bridge
attr mqttGenericBridge globalDefaults sub:base={"mqttGenericBridge/set"} pub:base={"mqttGenericBridge"}
attr mqttGenericBridge group MQTT
attr mqttGenericBridge room 98-Devices
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count

setstate mqttGenericBridge dev: 1 in: 0 out: 3
setstate mqttGenericBridge 2021-01-22 19:06:11 device-count 1
setstate mqttGenericBridge 2021-01-22 17:55:42 incoming-count 0
setstate mqttGenericBridge 2021-01-22 18:00:00 outgoing-count 3
setstate mqttGenericBridge 2021-01-22 18:00:00 transmission-state outgoing publish sent
setstate mqttGenericBridge 2021-01-22 17:55:42 updated-reading-count 0
setstate mqttGenericBridge 2021-01-22 17:55:42 updated-set-count 0

Nach meinem Verständnis ist hier dokumentiert, dass (fast) nichts mehr rausgeht.
setstate mqttGenericBridge 2021-01-22 18:00:00 outgoing-count 3

Und ich denke es besteht ein Zusammenhang mit der Entfernung des Attributs globalPublish.

Der Screenshot, den ich hier bereitgestellt habe, zeigt +200 outgoing-count.

[Beta-User]

Vorab mal sorry wg. des Problems mit dem attrTemplate-file, das sollte jetzt behoben sein (update nach 08:00 Uhr oder der Svn-Befehl). Da hatten sich ein paar aus Linux-Sicht kaputte Zeichen eingeschlichen...

Ich habe festgestellt, dass FHEM jetzt nichts mehr an den MQTT-Broker sendet.

[...]
Nach meinem Verständnis ist hier dokumentiert, dass (fast) nichts mehr rausgeht.
setstate mqttGenericBridge 2021-01-22 18:00:00 outgoing-count 3

Und ich denke es besteht ein Zusammenhang mit der Entfernung des Attributs globalPublish.

Es ist völlig logisch, dass sich die Zahl der ausgehenden Nachrichten drastisch verringert hat! Genau das ist ja beabsichtigt: Wir senden an den MQTT-Server nur das, was diesen etwas angeht und belasten den Rest der Welt nicht mit "unnützem"!

Du solltest dir wirklich mal anschauen, was mit den unterschiedlichen Einstellungen da an MQTT-Traffic "abgeht". Geht wirklich sehr einfach mit mosquitto_sub aus dem mosquitto-clients-Paket auf der Linux-Kommandozeile, ich hatte mir das grade angesehen, was _nur ein einziger CUL_HM-Thermostat_ da verursacht , wenn man an dem "sende alles" aktiviert. Unfassbar (und für deine externe Anwendung völlig überflüssig)... (Zur Klarstellung: event-on-change-reading ist an dem _nicht_ gesetzt)

Deine Attribute sollten jetzt dann so aussehen:

Code Auswählen Erweitern

attr KU.rollladen mqttPublish state:topic={"$base"} pct:topic={"$base/$device/$name"}
attr KU.rollladen mqttSubscribe state:stopic={"$base"} pct:stopic={"$base/$device/$name"}
Dann würde ich empfehlen, mit mosquitto_pub (ebenfalls zum Paket mosquitto-clients gehörend) zu testen, ob das Ding fährt, wenn du von der Kommandozeile aus den passenden Befehl sendest. (Erst), wenn das klappt, solltest du dich dann wieder der Loxone-Integration zuwenden.

Müßte mit diesem (IP ersetzen) Befehl von der Linux-Konsole gehen:

Code Auswählen Erweitern

mosquitto_pub -h <loxberry IP> -t mqttGenericBridge/set/KU.rollladen -m on -i testing



autocreate am M2-Client ist weiterhin nicht aktiviert? Sonst bitte auch die Hinweise hier beachten: https://forum.fhem.de/index.php/topic,118038.0.html

[cmonty14]

Vorab mal sorry wg. des Problems mit dem attrTemplate-file, das sollte jetzt behoben sein (update nach 08:00 Uhr oder der Svn-Befehl). Da hatten sich ein paar aus Linux-Sicht kaputte Zeichen eingeschlichen...
Es ist völlig logisch, dass sich die Zahl der ausgehenden Nachrichten drastisch verringert hat! Genau das ist ja beabsichtigt: Wir senden an den MQTT-Server nur das, was diesen etwas angeht und belasten den Rest der Welt nicht mit "unnützem"!

Kein Ding... ich bin sehr dankbar, dass ich Unterstützung erhalte von jemand mit sehr viel Erfahrung und Expertise; Fehler passieren immer mal, das ist nicht schlimm; schlimm ist nur, wie manche mit Fehlern umgehen... aber das ist ein anderes Thema.
Und ich bin da voll auf deiner Linie: so wenig Nachrichten wie möglich, so viel Nachrichten wie nötig.

Das Dropdown-Menü in der WebUI des Devices mqttGenericBridge ist jetzt verfügbar.
Der Befehl set mqttGenericBridge attrTemplate base_settings_to_MQTT_GENERIC_BRIDGE geht folglich jetzt auch.
Im Log wird dies nach der Ausführung des Befehls angezeigt:

Code Auswählen Erweitern

2021.01.23 09:52:08 1: 172.16.20.5:1883 disconnected, waiting to reappear (lb_mqtt_broker)
2021.01.23 09:52:08 1: 172.16.20.5:1883 reappeared (lb_mqtt_broker)

Ist mein Verständnis richtig, dass ich nicht prüfen kann, ob der Befehl erfolgreich ausgeführt wurde? Oder ist das, was im Log angzeigt wird, die Validierung?
Oder weiß ich durch eine angezeigte Fehlermeldung im WebUI, dass er nicht korrekt ausgeführt wurde?

Du solltest dir wirklich mal anschauen, was mit den unterschiedlichen Einstellungen da an MQTT-Traffic "abgeht". Geht wirklich sehr einfach mit mosquitto_sub aus dem mosquitto-clients-Paket auf der Linux-Kommandozeile, ich hatte mir das grade angesehen, was _nur ein einziger CUL_HM-Thermostat_ da verursacht , wenn man an dem "sende alles" aktiviert. Unfassbar (und für deine externe Anwendung völlig überflüssig)... (Zur Klarstellung: event-on-change-reading ist an dem _nicht_ gesetzt)

Muss das Attribut event-on-change-reading des Device KU.rollladen (HM-LC-Bl1PBU-FM) auf ".*" (= sende alles) gesetzt sein?
Oder muss dieses Attribut gelöscht werden?

Deine Attribute sollten jetzt dann so aussehen:

Code Auswählen Erweitern

attr KU.rollladen mqttPublish state:topic={"$base"} pct:topic={"$base/$device/$name"}
attr KU.rollladen mqttSubscribe state:stopic={"$base"} pct:stopic={"$base/$device/$name"}

Ich habe die Attribute entsprechend modifiziert.

Dann würde ich empfehlen, mit mosquitto_pub (ebenfalls zum Paket mosquitto-clients gehörend) zu testen, ob das Ding fährt, wenn du von der Kommandozeile aus den passenden Befehl sendest. (Erst), wenn das klappt, solltest du dich dann wieder der Loxone-Integration zuwenden.

Müßte mit diesem (IP ersetzen) Befehl von der Linux-Konsole gehen:

Code Auswählen Erweitern

mosquitto_pub -h <loxberry IP> -t mqttGenericBridge/set/KU.rollladen -m on -i testing


Auch mit dieser Strategie gehe ich völlig konform.

autocreate am M2-Client ist weiterhin nicht aktiviert? Sonst bitte auch die Hinweise hier beachten: https://forum.fhem.de/index.php/topic,118038.0.html

Aktuell ist das Attribut autocreate (von M2-Client) nicht gesetzt.
Wenn ich es richtig verstanden habe gibt es noch Probleme und es ist deshalb empfohlen, das Attribut autocreate auf "no" zu setzen.

Die Steuerung des Aktors, also in diesem Fall Device HM-LC-Bl1PBU-FM, funktioniert nur mit dem Topic
-t mqttGenericBridge/set/KU.rollladen/pct -m <n>
wobei n eine Zahl ist, die dem Status des Rollladens entspricht mit 0=offen und 100=geschlossen.

[rudolfkoenig]

Wenn ich es richtig verstanden habe gibt es noch Probleme und es ist deshalb empfohlen, das Attribut autocreate auf "no" zu setzen.

Die Voreinstellung ist bei MQTT2_CLIENT autocreate deswegen no, weil um das sinnvoll zu betreiben, sich mit dem Thema beschaeftigen muss.
MQTT2_SERVER kann die einzelnen Geraete anhand der ClientID zuordnen, und damit eine FHEM-Instanz anlegen. Ausnahme sind protocol-Bridges wie zigbee2qtt, etc.
MQTT2_CLIENT hat keinen Zugriff auf ClientID, deswegen muss die Zuordnung anhand gesetzten bridgeRegexp Attribut erfolgen, was fuer die bekannten Geraete eine passende ClientID "erfindet". Im AttrTemplate ist eine Sammlung solcher Geraete vorhanden.

@Beta-User: ich wuerde die MQTT2_CLIENT autocreate Voreinstellung auf simple aendern, und in MQTT2_DEVICE beim Anlegen der ersten MQTT2_DEVICE mit MQTT2_CLIENT als IODev automatisch "set attrTemplate MQTT2_CLIENT_general_bridge" ausfuehren. Bedenken?

[Beta-User]

Na ja, wenn die Attribute vorher ("richtig")  gesetzt waren, siehst du keine Veränderung, ansonsten verpasst das Ding eben der MGB ein paar Attribute...

Zu dem Teil hier jetzt:

Ich habe auch einen, und versuche mich grade in den expressions. Klappt zwischenzeitlich:

Code Auswählen Erweitern

defmod Rollladen_WZ_SSW CUL_HM 123456
attr Rollladen_WZ_SSW model HM-LC-BL1PBU-FM
attr Rollladen_WZ_SSW mqttGB1Publish state|pct|motor:topic={"$base/$device/$name"} motor:expression={$value=~m,([^:]+)?,?$1:undef}
attr Rollladen_WZ_SSW mqttGB1Subscribe state:stopic={"$base/$device"} pct:stopic={"$base/$device/$name"}

mqttGB1Publish führt dazu, dass nur state, pct und motor übertragen werden, wobei aus motor dann nur der Zustand, nicht aber der nummerische Wert übertragen wird. Soweit finde ich das gut.

mqttGB1Subscribe mit pct funktioniert, und auch on/off/stop werden verstanden.

Code Auswählen Erweitern

mosquitto_pub -h <server> -t MGB1/set/Rollladen_WZ_SSW -m stop -i testing

Dein Problem war noch, dass in der state-Subscription noch nicht (wieder) $device enthalten ist, das ist mir gestern dann scheinbar auch entgegangen, sorry...

@Beta-User: ich wuerde die MQTT2_CLIENT autocreate Voreinstellung auf simple aendern, und in MQTT2_DEVICE beim Anlegen der ersten MQTT2_DEVICE mit MQTT2_CLIENT als IODev automatisch "set attrTemplate MQTT2_CLIENT_general_bridge" ausfuehren. Bedenken?

(Leider und noch) ja:
- "eigentlich" sollte man dem Ding dann auch gleich eine ignoreRegexp verpassen;
- wir müßten ggf. überlegen, wie man die bridgeRegex für MGB ebenfalls automatisch erweitert
- das M2_DEVICE sollte dann auch direkt mit angelegt werden, warten finde ich schwierig;
- wer eine große Installation hat, wird sich wundern, weil er ein "Großdevice" verpaßt bekommt (es kommen alle Topics vom Broker...!)
(kurz: je länger ich drüber nachdenke, desto größer werden die Bauchschmerzen...)

Einen Mechanismus, mit dem man (bewußt!) alles auf einmal erledigen kann, fände ich aber schon gut. Evtl. einen Parameter in der DEF mitgeben können?
(EDIT: oder regelt sich das über die subscription?)

[rudolfkoenig]

Womoeglich kann man sich auf dem Standpunkt stellen: wer alles einfach und automatisch haben will, der verwendet MQTT2_SERVER.
Wer MQTT2_CLIENT verwendet, der weiss es offensichtlich besser, und will kein autocreate.

[Beta-User]

....ganz so einfach ist es vermutlich nicht...

Aber man könnte sich auf den Standpunkt stellen, wer dann autocreate (=Komfort) aktiv anschaltet, wird auch das Sortierdevice (und ignoreRegexp?) haben wollen?
(Also $init_done + vorher nicht gesetzt?)

[LuckyDay]

Die Voreinstellung ist bei MQTT2_CLIENT autocreate deswegen no, weil um das sinnvoll zu betreiben, sich mit dem Thema beschaeftigen muss.


@Beta-User: ich wuerde die MQTT2_CLIENT autocreate Voreinstellung auf simple aendern, und in MQTT2_DEVICE beim Anlegen der ersten MQTT2_DEVICE mit MQTT2_CLIENT als IODev automatisch "set attrTemplate MQTT2_CLIENT_general_bridge" ausfuehren. Bedenken?

Rudi würdest du bitte die Voreinstellung
-->MQTT2_CLIENT autocreate Voreinstellungauf no so lassen wie es seither war.

ich wäre nach einem Update sehr missgelaunt, wenn meine Fhem Instanzen ein Eigenleben , also dort sinnlose neue Device angelegt werden würden.

[LuckyDay]

@ Beta-User

du hast gesehen, dass @cmonty14

ummpassen tut!?

attr KU.rollladen eventMap on:100% off:0%

[rudolfkoenig]

ich wäre nach einem Update sehr missgelaunt, wenn meine Fhem Instanzen ein Eigenleben , also dort sinnlose neue Device angelegt werden würden.

Wenn jemandem solche Verhalten wichtig sind, dann bitte die Attribute explizit setzen, ich garantiere nicht, dass Voreinstellungen sich nie aendern werden. Womoeglich ist in solchen Faellen besser, kein update durchzufuehren, oder vor dem Update das Verhalten auf einem Testsystem zu pruefen.