VCCU: Notify auf virtuelle Buttons sinnvoll?

[FHEMAN]

Hallo zusammen,

ich habe ein Notify für ein Fernbedienunsbutton HM-RC-4-2:

Code Auswählen Erweitern

define Alarmanlage.UnScharfschalten notify Schluesselfernbedienung.01.Btn01.* set Alarmanlage off


Durch die neue VCCU und den angelegten virtuellen Buttons kann ich ja nun ein grünes LED Feedback verursachen. Dazu habe ich den virtuellen mit dem physischen Button gepeert:

Code Auswählen Erweitern

set Schluesselfernbedienung.01.Btn01 peerChan 0 VCCU_Btn2 single

Jetzt die Frage:
Ist es sicherer, das Notify nun auf den virtuellen Button zu legen - damit ich beim grünen LED Feedback auch davon ausgehen kann, dass die Funktion dahinter (hier Alarmanlage off) auch ausgeführt wird?

Und was ist eigentlich hierunter zu verstehen:

Code Auswählen Erweitern

2015-01-04 19:50:48 CUL_HM VCCU_Btn2 trig_Schluesselfernbedienung.01.Btn01: short
2015-01-04 19:50:48 CUL_HM VCCU_Btn2 trigLast: Schluesselfernbedienung.01.Btn01 :short
Muss ich da dann noch Trigger auswerten (die auch noch wild mit Freizeichen hantieren...) ?

[chris1284]

Die grüne lampe heist nur das die vccu/ eines der iodev den tastendruck empfangen hat einfach gesagt. Ich habe zb vom wandtaster einige buttons mit der vccu peered und reagiere darauf mit notify. Das der befehl im notify auch erfolgreich war ist damit nicht gesichert

Ein notify auf einen kurzen druck sieht bei mir zb so aus

Code Auswählen Erweitern

whg_switch01_Btn_03:trigger:.Short.* set ....... on

[fiedel]

Jetzt die Frage:
Ist es sicherer, das Notify nun auf den virtuellen Button zu legen - damit ich beim grünen LED Feedback auch davon ausgehen kann, dass die Funktion dahinter (hier Alarmanlage off) auch ausgeführt wird?

Nein, die "Sicherheit" hast du indem du die LED grün leuchten siehst. Der v.- Button wird außerdem getoggelt und könnte theoretisch auch mal "falsch" stehen. In einem Notify auf short/long fragst du idealerweise den Status des zu schaltenden Aktors ab und schaltest so immer richtig.

Und was ist eigentlich hierunter zu verstehen:

Code Auswählen Erweitern

2015-01-04 19:50:48 CUL_HM VCCU_Btn2 trig_Schluesselfernbedienung.01.Btn01: short
2015-01-04 19:50:48 CUL_HM VCCU_Btn2 trigLast: Schluesselfernbedienung.01.Btn01 :short
Muss ich da dann noch Trigger auswerten (die auch noch wild mit Freizeichen hantieren...) ?

Ja, wenn du zwischen short/long unterscheiden willst. Die beste Ausgangsbasis dafür ist der Event Monitor (ganz unten im FHEM- Menü). Hier mal ein Beispiel von mir:

Code Auswählen Erweitern


define Test_1 notify FB_HM_1_Btn_04.LongRelease.* { ...

define Test_2 notify FB_HM_1_Btn_04.Short.* { ...

[chris1284]

Der v.- Button wird außerdem getoggelt und könnte theoretisch auch mal "falsch" stehen. In einem Notify auf short/long fragst du idealerweise den Status des zu schaltenden Aktors ab und schaltest so immer richtig.

mmm default ist als command des vbuttons press short:press long nicht toggle...

Code Auswählen Erweitern

attr webCmd press short:press long

er will auch garnicht den vbutton betätigen sondern, wie ich , einen realen button mit dem vbutton perren um die positive rm am aktor zu bekommen das der befehl einwandfrei angekommen ist.

was du dann darauf hin mit dem angekommen short/long im notify machst ist ja dann deine sache und nicht vordefinierte (in form von toogle). ein prüfen auf dne aktuellen status ist bei zb dem schalten von it-dosen über hm-remote sinnlos da diese keine rückmeldung an fhem geben welchen status sie haben. der status in fhem kann somit theoretisch "falsch" sein

selbst wenn du einen aktor mit dem v-button peerst ist default nicht toggle sondern der sendet short /long an den aktor und der macht was im entsprechenden remotechannel des aktors definiert ist (beim hm-cc-rt wäre das zb 17 /21 grad für short /long)

[fiedel]

Ich nehme alles zurück und behaupte das Gegenteil.  Stimmt, das mit dem toggle war vor vCCU so. Und das mit dem Zustand des Aktors geht natürlich auch nur bei "Bidi"- Aktoren.