HM-PB-6-WM55 für Rola und Licht verwenden

[locodriver]

Guten Morgen,

ich habe jetzt beide notifys umgestellt, der T5 arbeitet wie gewünscht, aber der T6 lässt den Aktor immer noch anziehen -> abfallen -> anziehen. Beide notifys sind aber völlig identisch...

Code Auswählen Erweitern

define BD_Rola_SoSchu notify BD_T6_Btn_06.Long.1-.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola SoSchu";;}else {fhem "set BD_Rola stop";;}}
attr BD_Rola_SoSchu room 004Bad

define BD_Rola_SiSchu notify BD_T6_Btn_05.Long.1-.* {Log 1, "Motor ist ".ReadingsVal("BD_Rola","motor","")}{if ((ReadingsVal("BD_Rola","motor","") =~ m /stop/)){fhem "set BD_Rola SiSchu";;}else {fhem "set BD_Rola stop";;}}
attr BD_Rola_SiSchu room 004Bad


Ich habe auch mal die Zeit für longPress in beiden Registern auf 0.3 s gestellt - das dürfte aber damit nichts zu tun haben, oder?

Uwe

[martinp876]

beim Sensor (remote) ist es die Rate mit der die Messages an den Aktor gesendet werden. Ist hier wurscht. Bei einem dimmer oder schlimmer Rollo ist das wichtig. Der Rollo soll bei einer ong message so lange fahren bis die nächste kommt. Wenn der also nur .3sec fährt und der Trigger alle 1 sec kommt wird es ruckeln. Wenn der trigger alle .3sec kommt und der Rollo 1 sec je triggerfährt, fahrt er nach dem loslassen noch 1 sec weiter. Die gewählen defaults von HM sind abgestimmt und sollten passen.

im Notify fällt mir jetzt nichts auf. Kannst du einmal aufzeichnen welchen events alle kommen und nachsehen, ob mehrfach getriggert wird?  Wieviele logs werden denbei Button6 geschrieben?

Gruss Martin

[locodriver]

Hier die Events:

Code Auswählen Erweitern

T5:



2013-07-30 11:19:52 CUL_HM BD_T6_Btn_05 Long 1-8440- (to HMLAN1)
2013-07-30 11:19:52 CUL_HM BD_T6_Btn_05 trigger: Long_212
2013-07-30 11:19:53 CUL_HM BD_T6 BD_T6_Btn_05 Long 1-8440- (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_Rola level: SoSchu %
2013-07-30 11:19:53 CUL_HM BD_Rola deviceMsg: SoSchu % (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_Rola SoSchu %
2013-07-30 11:19:53 CUL_HM BD_Rola motor: stop:SoSchu %
2013-07-30 11:19:53 CUL_HM BD_T6_Btn_05 Long 2-A240- (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_T6_Btn_05 trigger: Long_212
2013-07-30 11:19:53 CUL_HM BD_T6 BD_T6_Btn_05 Long 2-A240- (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_Rola level: SoSchu %
2013-07-30 11:19:53 CUL_HM BD_Rola deviceMsg: SoSchu % (to HMLAN1)
2013-07-30 11:19:53 CUL_HM BD_Rola SoSchu %
2013-07-30 11:19:53 CUL_HM BD_Rola motor: down:SoSchu %
2013-07-30 11:20:03 CUL_HM BD_Rola level: SiSchu %
2013-07-30 11:20:03 CUL_HM BD_Rola deviceMsg: SiSchu % (to broadcast)
2013-07-30 11:20:03 CUL_HM BD_Rola SiSchu %
2013-07-30 11:20:03 CUL_HM BD_Rola motor: stop:SiSchu %

T6:


2013-07-30 11:21:03 CUL_HM BD_T6_Btn_06 Long 1-8440- (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_T6_Btn_06 trigger: Long_8
2013-07-30 11:21:03 CUL_HM BD_T6 BD_T6_Btn_06 Long 1-8440- (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_Rola level: 9.5 %
2013-07-30 11:21:03 CUL_HM BD_Rola deviceMsg: 9.5 % (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_Rola 9.5 %
2013-07-30 11:21:03 CUL_HM BD_Rola motor: stop:9.5 %
2013-07-30 11:21:03 CUL_HM BD_T6_Btn_06 Long 2-A240- (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_T6_Btn_06 trigger: Long_8
2013-07-30 11:21:03 CUL_HM BD_T6 BD_T6_Btn_06 Long 2-A240- (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_Rola level: 9.5 %
2013-07-30 11:21:03 CUL_HM BD_Rola deviceMsg: 9.5 % (to HMLAN1)
2013-07-30 11:21:03 CUL_HM BD_Rola 9.5 %
2013-07-30 11:21:03 CUL_HM BD_Rola motor: up:9.5 %
2013-07-30 11:21:13 CUL_HM BD_Rola level: SoSchu %
2013-07-30 11:21:13 CUL_HM BD_Rola deviceMsg: SoSchu % (to broadcast)
2013-07-30 11:21:13 CUL_HM BD_Rola SoSchu %
2013-07-30 11:21:13 CUL_HM BD_Rola motor: stop:SoSchu %

Ich kann keinen Unterschied erkennen.

[martinp876]

da fällt mir nur ein, dass der Trigger zum Device und zum Button kommt. du kannst also

BD_Rola_SoSchu notify ^BD_T6_Btn_06.Long.1-.*

nutzen. Dann sollte er des Device nicht mehr kommen (falls es dies war)

Gruss Martin

[locodriver]

Ich glaube, es klappt jetzt. Die Änderung mit "^" vor dem T6 hatte auch nichts am Verhalten geändert.

Dann habe ich mich nochmal mit den einzelnen Komponenten befasst und festgestellt, dass T6 und der BD_Rola "halb" gepeert waren, d.h. beim Rola war das Peering zur T6 eigetragen und bei T6 nichts  - k.A. wie das kam, möglicherweise schon beim Anlernen irgendwie? Ich habe das Peering gelöscht und jetzt funzt auch T6 sowohl mit der Methode von jetzt als auch mit

Code Auswählen Erweitern

define BD_Rola_SoSchu notify BD_T6_Btn_06.Long.1-.*

Habe jetzt wieder diesen Code für die beiden Taste drin. Dass das halbe Peering die Verständigung stört, obwohl ich ja keine direkte Funktion zwischen T6 und Rola programmiert habe ist aber komisch. Ich habe höchstens eine Erklärung in der Bedienungsanleitung S.20 gefunden: die Tasten sind für direktes Peering vorbelegt - T6 mit "Rola Hoch". Möglicherweise haben sich die Befehle über fhem mit der Werkseinstellung überlagert. Wenn ja, dann haben wir wieder was gelernt.-)

Danke für Deine Geduld und Hilfe, Martin, was würden wir ohne Dich machen.

Uwe

[martinp876]

Hallo Uwe,

kleine Erklärung zum halben peering:
peeren kann man im Prinzip immer "einzeln", also Aktor und Sensor getrennt. In FHEM ist es ein Kommandos, aber intern2 getrennte Abläufe. FHEM erlaubt auch, dass man nur eine Seite ausführt (remote|actor|both).

Dem Aktor ist es egal ob der Sensor gepeert ist - wenn er gepeert ist und ein trigger vom Sensor kommt wird die Aktion gestartet.

Der sensor schickt immer seine Trigger, egal ob er gepeert ist oder nicht. Wenn er gepeert ist will er von JEDEM peer dieses Kanals ein ACK. Wenn er es nicht bekommt wird der trigger wiederholt - für jeden Aktor. Wenn er immer noch keinen bekommt leuchtet er rot, sonst Grün. Wenn er keinen Peer hat wird nichts wiederholt und er leuchtet orange.

Falls du beide gepeert hattest wird der peer bei reset gelöscht - aber nur in dem Device, das du resetest.

Die Peerliste rehältst du durch getConfig (oder autoReadReg) und eine Übersicht sowie ein crosscheck der Peers kannst du mit HMinfo machen

Gruss Martin

[locodriver]

Hallo Martin, danke für die "aufklärenden" Worte. Da hat also der Taster auf ein ACK des Aktors gewartet und dann das Kommando wiederholt. Ich kann es jetzt nicht mehr nachvollziehen, da ich gestern das unerwünschte Peering gelöscht habe. Aber jetzt ist alles gut und es fehlen nur noch die Geräte an den Aktoren - dann ist es perfekt!

Also nochmals Danke!!

Uwe

[martinp876]

Da hat also der Taster auf ein ACK des Aktors gewartet und dann das Kommando wiederholt

denke ich nicht.
Der Aktor war gepeert,der Taster evtl nicht (oder doch, kann sogar noch sein, musst du prüfen).
Der Taster sendet (egal, ob gepeert),der Aktor (gepeert!!) verarbeitet den Trigger.

Sollte der Taster wiederholen wird der Aktor NICHT noch einmal triggern,da dieser erkennt, dass es eine Wiederholung ist. Er würde nur das ACK wiederholen, nicht den Schaltvorgang.

Wichtiges Detail, wenn man den Mechanismus verstehen will

Gruss Martin

[locodriver]

Nun mal was für's Auge:
Der in diesem Thread beschriebene 6-fach-Taster in Echt. Die Bilder habe ich aus den fhem-icons kopiert und skaliert.
Leider ist die Druckvorlage von eq3 zum Bedrucken nicht geeignet, sie hat das selbe Layout wie die beigelegten Vorlagen.
Ich habe die Felder vermessen und in der Tabellenkalkulation die Felder entsprechend eingestellt, dann die Bilder skaliert, angeordnet und dann in den Hintergrund verschoben und dann die Beschriftung in fett und 12-Punkt-Schrift.
Mir gefällt's.

Uwe