HM-LC-Bl1PBU-FM via MQTT steuern

[cmonty14]

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.

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:

Code Auswählen Erweitern

$ 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

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

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.

[Beta-User]

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

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

[LuckyDay]

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.

[cmonty14]

@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>%

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

Code Auswählen Erweitern

$ mosquitto_sub -v -h 172.16.20.5 -p 1883 -u loxberry -P <passwort> -t fhem/# | grep KU


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:

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

Code Auswählen Erweitern

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?

[cmonty14]

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?

[Beta-User]

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

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.



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?

[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

[cmonty14]

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.

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.

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?

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

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

[Beta-User]

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

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

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

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.