HM Schalter -> Z-Wave Jalousie

[Gizemo]

Hallo zusammen...

ich stehe momentan vor einem kleinen Problem. Bisher hatte ich nur HM Hardware und habe die auch immer über die CCU2 miteinander verknüpft. Jetzt ist Z-Wave mit ins Spiel gekommen (Fibaro Rollershutter 2 direkt an FHEM angelernt)


Mein Problem lautet nun wie folgt.

ich habe meine CCU in FHEM eingebunden. Auch vom PB-2-WM55 empfange ich die Daten, wenn ich eine Taste drücke, in FHEM..
press_long ; press_longs_release... usw....

wie bekomme ich nun folgendes szenario am besten hin:

langes drücken -> rollo fährt solange ich gedrückt halte
kurzes drücken -> rollo fährt komplett in die endposition -> nochmaliges kurzes drücken während der fahrt = stop

danke!

[Gizemo]

Hallo zusammen...

ich stehe momentan vor einem kleinen Problem. Bisher hatte ich nur HM Hardware und habe die auch immer über die CCU2 miteinander verknüpft. Jetzt ist Z-Wave mit ins Spiel gekommen (Fibaro Rollershutter 2 direkt an FHEM angelernt)


Mein Problem lautet nun wie folgt.

ich habe meine CCU in FHEM eingebunden. Auch vom PB-2-WM55 empfange ich die Daten, wenn ich eine Taste drücke, in FHEM..
press_long ; press_longs_release... usw....

wie bekomme ich nun folgendes szenario am besten hin:

langes drücken -> rollo fährt solange ich gedrückt halte
kurzes drücken -> rollo fährt komplett in die endposition -> nochmaliges kurzes drücken während der fahrt = stop

danke!

ok den ersten teil hab ich soweit selbst mit notifys herausgefunden... learning by doing
aber wie zum verrecken kann ich fhem beibringen das bei 2 mal den gleichen Taster oder von mir aus bei drücken der entgegengesetzten Richtung während der fahrt der Jalousie, die Jalousie stoppen soll.
Bis jetzt ist es so, dass bei 2tem mal drücken in die gleiche Richtung nichts passiert und bei drücken in die entgegengesetzte Richtung sofort in die andere Richtung gefahren wird.

[darkness]

Das musst du auch in deinem Notify/DOIF berücksichtigen.
Evtl. dazu auch noch ein DUMMY.

Grobe Idee:

Beim Tastendruck abfragen, ob Rollo sich bewegt, wenn nein dann starten; ja dann stoppen...

Oder kurzer Tastendruck starten; Langer Tastendruck stoppen.

[Gizemo]

Das musst du auch in deinem Notify/DOIF berücksichtigen.
Evtl. dazu auch noch ein DUMMY.

Grobe Idee:

Beim Tastendruck abfragen, ob Rollo sich bewegt, wenn nein dann starten; ja dann stoppen...

Oder kurzer Tastendruck starten; Langer Tastendruck stoppen.

das problem ist, dass der HM pb2 wm55 den "langen Tastendruck" erst beim loslassen gleichzeitig mit release überträgt...
was sofort übertragen wird (egal ob short oder long) ist install_test... müsste da evtl. über eine bestimmte zeit diese install_test hochzählen lassen und dann erst reagieren... unschön...

was ich mir überlegt hatte.
Eine Systemvariable in der CCU2 anzulegen -> diese bei langen tastendruck auf true setzen lassen -> per fhem auslesen -> dementsprechend reagieren -> bei loslassen der taste (press_longs_release) die variable in der CCU2 von FHEM aus wieder auf false setzen lassen...

[darkness]

Hm, ich dachte der macht die Long und Short sofort. Muss ich aber heute Abend mal testen. Und "install_test" habe ich auch nicht.

[darkness]

Habe gerade mal getestet. Bei mir werden die Long entsprechend gesendet, so lange ich drücke:

2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 Long 2_20 (to vccu)
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 Long 3_20 (to vccu)
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 Long 4_20 (to vccu)
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 Long 5_20 (to vccu)
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 Long 6_20 (to vccu)
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 Long 7_20 (to vccu)
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:28 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 Long 8_20 (to vccu)
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 Long 9_20 (to vccu)
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 Long 10_20 (to vccu)
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 Long 11_20 (to vccu)
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 Long 12_20 (to vccu)
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:29 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 LongRelease 12_20 (to vccu)
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 Long 13_20 (to vccu)
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 trigger_cnt: 20
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 LongRelease 13_20 (to vccu)
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 trigger: Long_20
2018-03-12 20:01:30 CUL_HM buero_bm_Btn_01 trigger_cnt: 20

[Gizemo]

Habe gerade mal getestet. Bei mir werden die Long entsprechend gesendet, so lange ich drücke:

kann es sein, dass du deine HM Geräte direkt in FHEM angelernt hast? Ich habe neben FHEM auf dem Pi noch eine Virtuelle Maschine mit der CCU2 Software laufen.
hmmm....
vielleicht ist es einfacher die Schalter dann direkt in FHEM anzulernen um das zu realisieren...

[darkness]

Ja, habe eine VCCU mit den IOs und darüber das Pairing gemacht.
Ob es Vorteile hat mit der CCU2 zu arbeiten kann ich dir nicht sagen. Ich glaube spätestens bei HMIP wird das notwendig.
Das sind aber Fragen für das Homematic Unterforum

Gruß

[Beta-User]

Bei solchen Sachen spielt häufig auch der Zeitversatz zwischen Tastendruck und sichtbarer Reaktion eine Rolle (selbst, wenn man die HM-Devices direkt@VCCU eingebunden hat wie ich selbst auch und daher nicht noch netzwerkbedingte weitere Verzögerungen eine Rolle spielen).

langes drücken -> rollo fährt solange ich gedrückt halte
kurzes drücken -> rollo fährt komplett in die endposition -> nochmaliges kurzes drücken während der fahrt = stop

Sowas würde ich aus dem genannten Grund also nicht machen, sondern das wie folgt lösen:

- Auf longrelease warten und dann nach oben oder unten fahren (abh. v. Taste) (würde ein notify machen, das auf beide Tasten mit longrelease reagiert und dann nach den $DEVICE in einem perl-if entscheiden, ob nach oben oder unten gefahren werden soll)

- für kurze Tastendrücke kommt es dann darauf an, ob die den aktuellen Status des Rollo-Aktors kennst (fährt oder fährt nicht; bei einem HM-Device ist bei nicht-Fahrt z.B. das motor-reading auf "stop", soweit ich mich erinnere; müßte man für diesen Aktor checken).
Wenn ja: in dem notify bei Fahrt ein "Stop", sonst ein Fahrbefehl, der z.B. 10% nach oben bzw. unten fährt. Zeig' uns doch einfach, was für Events im Event-Monitor kommen.

- Noch komplexere Dinge wären mit "sequence" möglich, aber das ist m.E. nicht so benutzerfreundlich und verzögert ggf. die Reaktion zwischen Tastendruck und Reaktion noch weiter (wäre aber uU. eine zusätzliche Option, wenn du den Fahrzustand des Rollos nicht kennst).

Gruß, Beta-User