FHEM Forum

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:
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

Wie in dem anderen Thread bereits erwähnt, braucht es für das Funktionieren bestimmte Einstellungen an der MQTT_GENERIC_BRIDGE:
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:
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:
"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

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).

Zitat von: Beta-User am 22 Januar 2021, 16:46:18
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?

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.).

Zitat von: Beta-User am 22 Januar 2021, 16:46:18
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:
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 (https://forum.fhem.de/index.php?action=dlattach;topic=117960.0;attach=146043) bereitgestellt habe, zeigt +200 outgoing-count.

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...

Zitat von: cmonty14 am 22 Januar 2021, 19:12:35
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:
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:
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

Zitat von: Beta-User am 23 Januar 2021, 06:48:47
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:
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?

Zitat
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?

Zitat
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.

Zitat
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.

Zitat
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.

ZitatWenn 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?

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:
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.
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...

Zitat von: rudolfkoenig am 23 Januar 2021, 12:16:06
@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?)

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.

....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?)

Zitat von: rudolfkoenig am 23 Januar 2021, 12:16:06
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.

@ Beta-User

du hast gesehen, dass @cmonty14

ummpassen tut!?

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

Zitatich 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.

Zitat von: Beta-User am 23 Januar 2021, 12:24:59
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"}

Habe ich so übernommen.

Zitat
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.

In meinem Fall werden diese Topics übertragen:
$ mosquitto_sub -v -h 172.16.20.5 -p 1883 -u loxberry -P <passwort -t fhem/# | grep KU.
fhem/KU.rollladen/commState CMDs_done
fhem/KU.rollladen/level 0
fhem/KU.rollladen/state off
fhem/KU.rollladen/motor stop:0%
fhem/KU.rollladen/deviceMsg 0% (to HMUART)
fhem/KU.rollladen/pct 0
fhem/KU.rollladen_oeffnen/state inactive

Zitat
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

Ich kann den Rollladen-Aktor nur mit diesem Befehl steuern:
mosquitto_pub -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t mqttGenericBridge/set/KU.rollladen/pct -m 0 -i testing
Wenn ich diesen Befehl verwende passiert nichts.
mosquitto_pub -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t mqttGenericBridge/set/KU.rollladen -m start -i testing

Welchen Befehl verwendest du für "Fahrt ganz auf/ab"?

Zitat
Dein Problem war noch, dass in der state-Subscription noch nicht (wieder) $device enthalten ist, das ist mir gestern dann scheinbar auch entgegangen, sorry...
(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?)

Habe ich (leider) nicht verstanden was du damit meinst.

Zitat von: rudolfkoenig am 23 Januar 2021, 14:42:45
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.

Kann die Haltung zwar nachvollziehen, aber meine Vorbehalte gegen automatisches autocreate an M2_CLIENT haben sich weiter nicht in Luft aufgelöst.

Hat auch damit zu tun, dass ich manches irritierend fand, als ich (vor sehr langer Zeit) mal einen M2C an M2S gehangen hatte (auf einem anderen System); da waren manche Ping-Pong-Effekte zu beobachten mit immer weiter verschachtelten readingList-Einträgen. _Könnte_ mit diesem seltsamen autocreate-Effekt zu tun haben, der bei abbrechenden Verbindungen zu beobachten ist (gibt einen Thread von mir dazu).

Aber was ich mir vorstellen könnte, wäre ein "automatisches Mitanlegen des M2D mit bridgeRegexp" (und eigentlich auch mit vorbelegter ignoreRegex). Ggf. könnten wir das comment-Attribut noch entsprechend vorbelegen, dass der User wenigstens die Chance hat zu erfahren, warum das Device da ist (klar, die Mechanismen sind nicht linear, daher: sowas wie "SeMiCoLoN-readingList" als Kenner verwenden?)

Zitat von: fhem-hm-knecht am 23 Januar 2021, 14:23:41
@ Beta-User

du hast gesehen, [...]

Nope, Danke für den Hinweis:

@cmonty14: Das fängt vermutlich auch on/off-Kommandos von MQTT-Seite her ab und ist insgesamt (vermutlich) eher ungeschickt. Wenn du das nicht mit voller Absicht gemacht hast und dann auch ggf. entsprechend an anderer Stelle auswertest, würde ich empfehlen, da einfach 0 bzw. 100 zu mappen und dann das % via stateFormat beizumischen. Das sollte dann auch einheitlich aussehen, wenn der Rollladen  irgendwo dazwischen steht ;) .
(Sonst kannst du dich ja mal mit der erweiterten eventMap-Option ({dev=>...}) rumschlagen, wenn sowas unbedingt sein muss...)

Steuern kann ich mit Zahlenwerten auf (state oder pct) oder on/off/up/down/stop auf state (state soll hier "$base/$device" bedeuten).

Was die auf dem mosquitto vorhandenen Infos angeht, wäre ggf. noch interessant zu wissen, von wann die sind. Wenn das "retained" messages sind aus der Zeit von globalPublish oder einem irgendwann mal gesetzten *:topic=... im publish-Attribut des Devices, bleiben die für immer unverändert da, afaik. Müßte man ggf. aktiv löschen.

Kannst du bitte ggf. (nach Änderung der %-Sache) ein komplettes RAW liefern, wenn es dann immer noch nicht klappt?

(Und ansonsten sorry für die Zwischenbemerkungen, die eher für Rudi gedacht sind; das nach $device kannst du als "normaler User" ignorieren, und auch das, was vor dem Zitat von fhem-hm-knecht steht)

Zitat von: rudolfkoenig am 23 Januar 2021, 14:42:45
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.

Deswegen war der Hinweis von mir!
dass du auch an die Produkivsysteme denkst.

Zitat von: Beta-User am 23 Januar 2021, 15:14:35
@cmonty14: Das fängt vermutlich auch on/off-Kommandos von MQTT-Seite her ab und ist insgesamt (vermutlich) eher ungeschickt. Wenn du das nicht mit voller Absicht gemacht hast und dann auch ggf. entsprechend an anderer Stelle auswertest, würde ich empfehlen, da einfach 0 bzw. 100 zu mappen und dann das % via stateFormat beizumischen. Das sollte dann auch einheitlich aussehen, wenn der Rollladen  irgendwo dazwischen steht ;) .
(Sonst kannst du dich ja mal mit der erweiterten eventMap-Option ({dev=>...}) rumschlagen, wenn sowas unbedingt sein muss...)

Steuern kann ich mit Zahlenwerten auf (state oder pct) oder on/off/up/down/stop auf state (state soll hier "$base/$device" bedeuten).

Ich kann (jetzt) den Rollladen mit folgenden Befehlen steuern:
mosquitto_pub -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t mqttGenericBridge/set/KU.rollladen -m down -i testing
= Rollladen fährt 1 Schritt = 10% ab
mosquitto_pub -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t mqttGenericBridge/set/KU.rollladen -m up -i testing
= Rollladen fährt 1 Schritt = 10% auf
mosquitto_pub -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t mqttGenericBridge/set/KU.rollladen -m on -i testing
= Rollladen fährt vollständig ab
mosquitto_pub -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t mqttGenericBridge/set/KU.rollladen -m off -i testing
= Rollladen fährt vollständig auf
mosquitto_pub -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t mqttGenericBridge/set/KU.rollladen -m <n> -i testing
= Rollladen fährt zu Position <n>%
mosquitto_pub -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t mqttGenericBridge/set/KU.rollladen/pct -m <n> -i testing
= Rollladen fährt zu Position <n>%

Zitat
Was die auf dem mosquitto vorhandenen Infos angeht, wäre ggf. noch interessant zu wissen, von wann die sind. Wenn das "retained" messages sind aus der Zeit von globalPublish oder einem irgendwann mal gesetzten *:topic=... im publish-Attribut des Devices, bleiben die für immer unverändert da, afaik. Müßte man ggf. aktiv löschen.

Ich habe es dann doch noch geschafft, alle Topics von KU.rollladen zu löschen mit Hilfe der App "MQTT Explorer".
Die Ausgabe von mosquitto_sub ist jetzt leer (empty):
$ mosquitto_sub -v -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t fhem/# | grep KU


Zitat
Kannst du bitte ggf. (nach Änderung der %-Sache) ein komplettes RAW liefern, wenn es dann immer noch nicht klappt?

Ich weiß jetzt ehrlich gesagt nicht, was du meinst.
Jedenfalls ist hier das komplette RAW:
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 mqttPublish state|pct|motor:topic={"$base/$device/$name"} motor:expression={$value=~m,([^:]+)?,?$1:undef}
attr KU.rollladen mqttSubscribe state:stopic={"$base/$device"} pct:stopic={"$base/$device/$name"}
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


Ich habe jetzt alle Befehle, die aus meiner Sicht benötigt werden, um den Rollladen zu steuern:
ganz auf/ab, Position <n>% anfahren

Du hast die folgenden Attribute definiert:
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"}

Frage hierzu:
Warum das stopic von state auf {"$base/$device"}?
Das stopic pct ist ja auf {"$base/$device/$name"}.

Eine andere Frage bezieht sich auf die "Umsetzung in der Praxis".
Die Steuerung sendet täglich bei Sonnenaufgang den Befehl an alle Rollos: ganz auf (und entsprechend bei Sonnenuntergang den Befehl an alle Rollos: ganz ab).
Frage:
Ist es sinnvoll/notwendig, ein bestimmtes Reading des KU.rollladen abzufragen, bevor/während/nachdem dieser Befehl ausgeführt wird?

Ich habe bereits damit begonnen, das Device KU.rollladen mit Loxone zu steuern.
Hierbei habe ich mich an einem Device (Tasmota Steckdose) orientiert, das bereits funktioniert; dieses wird mit diesem Befehl an/-ausgeschaltet:
tasmota/BW-SHP2/cmnd/Power on

Den Befehl für KU.rollladen habe ich dann so definiert:
fhem/KU.rollladen/state on
Dies funktioniert aber nicht.
Dann habe ich den Befehl modifiziert; mit diesem Syntax
mqttGenericBridge/set/KU.rollladen/state on
funktioniert es dann.

Und dann noch diese Frage:
Muss das Attribut
event-on-change-reading .*
gelöscht werden?
Oder soll dieses Attribut beibehalten werden?

Dann gibt es (aus meiner Sicht) ein weiteres, grundlegendes Problem mit der Steuerung:
Es gibt keine Rückmeldung vom Rollladen-Motor, was die aktuelle Position des Rollladen ist.

Der Rollladen-Motor kennt nur 2 Zustände:
Auf- bzw. Abfahrt so lange, wie Spannung (230V) anliegt.
Wird die Endposition erreicht, dann wird der Motor automatisch abschalten; somit wird verhindert, dass der Motor bei Erreichen der Endposition heiß läuft.

Der Aktor HM-LC-Bl1PBU-FM funktioniert auf Basis der Zeit, d.h. man muss die Dauer für einen vollständigen Auf- und Abfahrt angeben, damit jede Position x angefahren werden kann.
Dann wird der Aktor das Signal so lange anlegen, wie x in Relation zur Dauer für Auf-/Abfahrt ist.

Die Loxone-Steuerung dagegen verwendet einen Baustein, der am Ausgang Auf/Ab ein Signal so lange anlegt, wie der Rollladen-Motor für die Auf-/Abfahrt zur Position x benötigt.
Das bedeutet, auch dieser Baustein basiert auf der Angabe der Dauer für eine vollständigen Auf- und Abfahrt.
An einem weiteren Ausgang wird die Position des Rollladens (0 = ganz oben, 1,0 = ganz unten) ausgegeben; jede Zwischenposition ist eine Dezimalzahl 0<y<1.
Dies ist somit äquivalent zu HM-LC-Bl1PBU-FM; ich bezeichne dies folglich als "Analoge Steuerung".

Wenn man jetzt den Rollladen über ein Protokoll wie MQTT steuern möchte, dann steht dort ein "Trigger"-Befehl, z.B. "Rollladen: Abfahrt zu Position x".
Dieser Befehl wird nur 1x abgesendet.
Ich bezeichne dies mal als "Digitale Steuerung".

Die Herausforderung besteht jetzt darin, die "Analoge Steuerung" in die "Digitale Steuerung" zu transferieren.

Welche Lösung würden die Experten hierfür entwickeln?

Zitat von: cmonty14 am 24 Januar 2021, 10:47:01
Dann gibt es (aus meiner Sicht) ein weiteres, grundlegendes Problem mit der Steuerung:
Es gibt keine Rückmeldung vom Rollladen-Motor, was die aktuelle Position des Rollladen ist.
[...]
Welche Lösung würden die Experten hierfür entwickeln?

Die Funktionsweise des Aktors an sich ist doch bekannt, und intern macht er m.E. auch nichts anderes als dein "Loxone-Baustein". Von daher verstehe ich das Problem nicht.
Besser wird das nur, wenn du einen anderen Aktor-Typ nimmst, der erkennen kann, ob Leistung abgefordert wird. Sowas gibt's afaik nicht von Homematic, (auch) von daher sind z.B. die ZWave-Aktoren von Fibaro "besser".
M.E. ist da auch der Loxone-"Baustein" nicht besser...

---

Was das list angeht, würde ich vorschlagen, eventMap zu ändern (und ggf. stateFormat zu ergänzen):
attr KU.rollladen eventMap on:100 off:0
attr KU.rollladen stateFormat state%

event-on-change-reading kann hier m.E. auf .* bleiben, das ist insbes. bei CUL_HM eine Philosophie-Frage. Ich habe es nicht gesetzt, und für regelmäßige Messwerte ist es m.E. nicht sinnvoll.

---

Zur "Praxisfrage" würde ich sagen: Hier brauchst du nichts voher/währenddessen abfragen, aber eine allgemeingültige Aussage dazu ist extrem schwierig. Vielleicht schaust du dir in dem Zusammenhang mal "structure" an und dort insbesondere "sendDelay", dann wird es _vielleicht_ etwas klarer, wo die Probleme liegen _können_.
Als FHEM'ler kann ich sowieso nicht nachvollziehen, warum man das nicht mir FHEM-Mitteln macht, aber das ist eine andere Geschichte...

---

"Deinen" Rollladen gibt es zwischenzeitlich auch als attrTemplate ;) .

---

Schön, dass du jetzt auch mit der Integration in Loxone soweit fertig bist. Da würde mich zum Abschluss jetzt (auch, nachdem die Auswirkungen von "globalPublish" klarer geworden sein dürfte) interessieren, ob du meine Kritik an der im Loxone-Wiki dargestellten Lösung jetzt nachvollziehen kannst?

Falls ja: Vielleicht magst du meiner Bitte aus dem nachfolgend zitierten Beitrag nachkommen und den Kanal in Richtung von Loxone für uns aufmachen?

Zitat von: Beta-User am 22 Januar 2021, 13:46:11
[OT] Ich habe mir jetzt mal die hier genannte Quelle reingezogen und auch die Doku bei loxberry, die dann da am Ende auch verlinkt ist.Meine Befürchtung: Solange von Einsteigern versucht wird, diese Art Anleitung nachzubauen, werden wir hier das zweifelhafte Vergnügen haben, immer wieder zu erklären, dass andere Wege eigentlich besser wären...

Meine Bitte (v.a. an eventuell mitlesende Loxone-User): Es wäre nett, wenn ihr dafür sorgen würdet, dass der Autor dieses Blog-Beitrags (bzw. auch der Wiki-Artikel@Loxone) ggf. mal hier vorbeischaut (oder ggf. auf andere Weise Kontakt aufnimmt), damit wir das gemeinsam auf einen sichereren, aber weiterhin einsteigerfreundlichen Weg bringen können?
Erst danach kann man ihm ernsthaft den Vorwurf machen, dass es unverantwortlich ist, in 2021 noch Lösungen zu bewerben, die er mal mit Stand 2017 hier aus dem Forum geholt hat...

Danke schonmal,
[/OT]

Beta-User

Zitat von: Beta-User am 24 Januar 2021, 11:29:55
Die Funktionsweise des Aktors an sich ist doch bekannt, und intern macht er m.E. auch nichts anderes als dein "Loxone-Baustein". Von daher verstehe ich das Problem nicht.
Besser wird das nur, wenn du einen anderen Aktor-Typ nimmst, der erkennen kann, ob Leistung abgefordert wird. Sowas gibt's afaik nicht von Homematic, (auch) von daher sind z.B. die ZWave-Aktoren von Fibaro "besser".
M.E. ist da auch der Loxone-"Baustein" nicht besser...

Ich wollte mit meiner Aussage keinen Vergleich FHEM vs. Loxone anstellen.
Es geht mir einzig darum darzulegen, dass die Steuerung des Rollladens über MQTT nicht so trivial realisiert werden kann mit einem Baustein (in Loxone), der für die Auf-/Abfahrt ein Signal mit der Dauer x anlegt (wobei x gleich die Zeit ist, die benötigt wird, um die Position anzufahren).
Denn ich muss ja über MQTT einmalig den Befehl senden:
mqttGenericBridge/set/KU.rollladen/state -m <x>

Beispiel:
Im Loxone Baustein gibt es die Funktion "Beschatten".
Über einen Parameter kann festgelegt werden, welcher Wert 0<x<1 (0 = ganz oben, 1,0 = ganz unten) dann "Beschatten" entspricht.
Nehmen wir hierfür den Wert 0.5 an.
Und nehmen wir weiter an, dass die Zeit t für die vollständige Abfahrt 20s ist.
Ist der Rollladen ganz oben und ich gebe den Steuer-Befehl "Beschatten", dann wird der Baustein 10s lang den Ausgang "Jalousie Ab" ansteuern.
Welcher Befehl soll dann an MQTT gesendet werden?
Wann wird dieser Befehl an MQTT gesendet?
Und wie wird dieser Befehl mit der Variable x gebaut?

HIerfür ist eine zusätzliche Logik nötig.

Ich habe das beispielsweise so gelöst (siehe Anhang).
Der Nachteil dieser Lösung ist, dass der Rollladen asynchron auf-/abfährt
Aber vielleicht hat jemand eine bessere weil einfache Lösung.

Zitat

---

Was das list angeht, würde ich vorschlagen, eventMap zu ändern (und ggf. stateFormat zu ergänzen):

Code Auswählen Erweitern

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

event-on-change-reading kann hier m.E. auf .* bleiben, das ist insbes. bei CUL_HM eine Philosophie-Frage. Ich habe es nicht gesetzt, und für regelmäßige Messwerte ist es m.E. nicht sinnvoll.

---

Ich habe diese Empfehlung übernommen.

Zitat
Zur "Praxisfrage" würde ich sagen: Hier brauchst du nichts voher/währenddessen abfragen, aber eine allgemeingültige Aussage dazu ist extrem schwierig. Vielleicht schaust du dir in dem Zusammenhang mal "structure" an und dort insbesondere "sendDelay", dann wird es _vielleicht_ etwas klarer, wo die Probleme liegen _können_.
Als FHEM'ler kann ich sowieso nicht nachvollziehen, warum man das nicht mir FHEM-Mitteln macht, aber das ist eine andere Geschichte...

Was genau meinst du hiermit?

Zitat

---

"Deinen" Rollladen gibt es zwischenzeitlich auch als attrTemplate ;) .

Wie komme ich an das attrTemplate für den HM-LC-Bl1PBU-FM?
Welchen Vorteil hat es, wenn ich dieses Template verwende (im Vergleich zu meiner aktuellen Konfiguration ohne das Template)?
Wie muss ich vorgehen, um das Template zu nutzen?

Zitat

---

Schön, dass du jetzt auch mit der Integration in Loxone soweit fertig bist. Da würde mich zum Abschluss jetzt (auch, nachdem die Auswirkungen von "globalPublish" klarer geworden sein dürfte) interessieren, ob du meine Kritik an der im Loxone-Wiki dargestellten Lösung jetzt nachvollziehen kannst?

Falls ja: Vielleicht magst du meiner Bitte aus dem nachfolgend zitierten Beitrag nachkommen und den Kanal in Richtung von Loxone für uns aufmachen?

Ich habe den Autor des Blogs kontaktiert.
Oder beziehtst du dich auf eine andere Dokumentation (Wiki)?

Zitat von: cmonty14 am 24 Januar 2021, 16:02:47
Ich wollte mit meiner Aussage keinen Vergleich FHEM vs. Loxone anstellen.

Ich auch nicht, aber letztlich geht es einfach ja darum, dass du irgendeinen Öffnungsgrad in einer bestimmten Situation haben willst. Ob es nun 0-1 ist oder 0%-100%, ist letztlich egal...

Zitat
Was genau meinst du hiermit?

Ich habe AutoShuttersControl im Einsatz, und das auf/zu früher mit WeekdayTimer gelöst. Es gibt aber noch ein paar mehr Varianten, die FHEM zu bieten hat...

Zitat
Wie komme ich an das attrTemplate für den HM-LC-Bl1PBU-FM?

Der get_from-svn Befehlt oder ab morgen 8:00 Uhr per update.

Ich habe nochmal was zu "state" geändert, und der Vorteil ist der, dass du dann gleich nacheinander alle x Rollläden damit konfigurieren kannst...

Zitat
Ich habe den Autor des Blogs kontaktiert.
Oder beziehtst du dich auf eine andere Dokumentation (Wiki)?

Danke. So wie ich das verstanden habe, ist es derselbe Autor. (Loxone-) Wiki wäre mir wichtiger, aber mal sehen.