Wie kann "toggle" Verhalten trotz Dual Peering HM-RC-8 geändert werden

[pschlaeppi]

Hallo zusammen,

Das peeren der Fernbedienung mit einem virtuellen Device führt leider nicht zum erwarteten Ergebniss und ich weiss gerade nicht wo mit der Problembehebung zu beginnen. Ich habe eine HM-RC-8 Fernbedienung mit einem virtuellen Fernbedienungsaktor gepeered mittels:

Code Auswählen Erweitern

set og.sz.FB.Schlafen1_Btn_01 peerChan 0 vFB.01_Btn1 dual set
peerCheck mit hmiinfo zeigt keine Fehler mit dem Peering

Wenn ich Button 1 drücke, geht der virtuelle Button 1 auf ON.
Drücke ich den Button 2, geht der virtuelle Button 1 auf OFF. Dieses entspricht soweit dem erwarteten Verhalten.

Code Auswählen Erweitern

2017-06-30 00:15:30 CUL_HM og.sz.FB.Schlafen1_Btn_01 Short (to vFB.01)
2017-06-30 00:15:30 CUL_HM og.sz.FB.Schlafen1_Btn_01 triggerTo_vFB.01: Short_88
2017-06-30 00:15:30 CUL_HM vFB.01_Btn1 ON
2017-06-30 00:15:30 CUL_HM vFB.01_Btn1 trigLast: og.sz.FB.Schlafen1_Btn_01:short
2017-06-30 00:15:30 CUL_HM vFB.01_Btn1 trig_og.sz.FB.Schlafen1_Btn_01: Short_88
2017-06-30 00:15:30 CUL_HM vFB.01_Btn1 virtActState: ON
2017-06-30 00:15:30 CUL_HM vFB.01_Btn1 virtActTrigNo: 88
2017-06-30 00:15:30 CUL_HM vFB.01_Btn1 virtActTrigRpt: 1
2017-06-30 00:15:30 CUL_HM vFB.01_Btn1 virtActTrigType: short_Release
2017-06-30 00:15:30 CUL_HM vFB.01_Btn1 virtActTrigger: og.sz.FB.Schlafen1_Btn_01
2017-06-30 00:15:30 CUL_HM og.sz.FB.Schlafen1_Btn_01 triggerTo_vFB.01: Short_88_ack
2017-06-30 00:15:33 CUL_HM og.sz.FB.Schlafen1_Btn_02 Short (to vFB.01)
2017-06-30 00:15:33 CUL_HM og.sz.FB.Schlafen1_Btn_02 triggerTo_vFB.01: Short_46
2017-06-30 00:15:33 CUL_HM vFB.01_Btn1 OFF
2017-06-30 00:15:33 CUL_HM vFB.01_Btn1 trigLast: og.sz.FB.Schlafen1_Btn_02:short
2017-06-30 00:15:33 CUL_HM vFB.01_Btn1 trig_og.sz.FB.Schlafen1_Btn_02: Short_46
2017-06-30 00:15:33 CUL_HM vFB.01_Btn1 virtActState: OFF
2017-06-30 00:15:33 CUL_HM vFB.01_Btn1 virtActTrigNo: 46
2017-06-30 00:15:33 CUL_HM vFB.01_Btn1 virtActTrigRpt: 1
2017-06-30 00:15:33 CUL_HM vFB.01_Btn1 virtActTrigType: short_Release
2017-06-30 00:15:33 CUL_HM vFB.01_Btn1 virtActTrigger: og.sz.FB.Schlafen1_Btn_02
2017-06-30 00:15:34 CUL_HM og.sz.FB.Schlafen1_Btn_02 triggerTo_vFB.01: Short_46_ack


Drücke ich zum Beispiel Button 1 und darauf folgend auch wieder die Taste 1, würde ich nun erwarten dass der virtuelle Button jedesmal auf ON geht. Leider tut er dieses aber nicht. Er "toggled" von ON auf OFF und beim dritten Mal wieder auf ON.

Code Auswählen Erweitern

2017-06-30 00:25:47 CUL_HM og.sz.FB.Schlafen1_Btn_01 Short (to vFB.01)
2017-06-30 00:25:47 CUL_HM og.sz.FB.Schlafen1_Btn_01 triggerTo_vFB.01: Short_89
2017-06-30 00:25:47 CUL_HM vFB.01_Btn1 ON
2017-06-30 00:25:47 CUL_HM vFB.01_Btn1 trigLast: og.sz.FB.Schlafen1_Btn_01:short
2017-06-30 00:25:47 CUL_HM vFB.01_Btn1 trig_og.sz.FB.Schlafen1_Btn_01: Short_89
2017-06-30 00:25:47 CUL_HM vFB.01_Btn1 virtActState: ON
2017-06-30 00:25:47 CUL_HM vFB.01_Btn1 virtActTrigNo: 89
2017-06-30 00:25:47 CUL_HM vFB.01_Btn1 virtActTrigRpt: 1
2017-06-30 00:25:47 CUL_HM vFB.01_Btn1 virtActTrigType: short_Release
2017-06-30 00:25:47 CUL_HM vFB.01_Btn1 virtActTrigger: og.sz.FB.Schlafen1_Btn_01
2017-06-30 00:25:47 CUL_HM og.sz.FB.Schlafen1_Btn_01 triggerTo_vFB.01: Short_89_ack
2017-06-30 00:25:50 CUL_HM og.sz.FB.Schlafen1_Btn_01 Short (to vFB.01)
2017-06-30 00:25:50 CUL_HM og.sz.FB.Schlafen1_Btn_01 triggerTo_vFB.01: Short_90
2017-06-30 00:25:50 CUL_HM vFB.01_Btn1 OFF
2017-06-30 00:25:50 CUL_HM vFB.01_Btn1 trigLast: og.sz.FB.Schlafen1_Btn_01:short
2017-06-30 00:25:50 CUL_HM vFB.01_Btn1 trig_og.sz.FB.Schlafen1_Btn_01: Short_90
2017-06-30 00:25:50 CUL_HM vFB.01_Btn1 virtActState: OFF
2017-06-30 00:25:50 CUL_HM vFB.01_Btn1 virtActTrigNo: 90
2017-06-30 00:25:50 CUL_HM vFB.01_Btn1 virtActTrigRpt: 1
2017-06-30 00:25:50 CUL_HM vFB.01_Btn1 virtActTrigType: short_Release
2017-06-30 00:25:50 CUL_HM vFB.01_Btn1 virtActTrigger: og.sz.FB.Schlafen1_Btn_01
2017-06-30 00:25:50 CUL_HM og.sz.FB.Schlafen1_Btn_01 triggerTo_vFB.01: Short_90_ack
2017-06-30 00:25:56 CUL_HM og.sz.FB.Schlafen1_Btn_01 Short (to vFB.01)
2017-06-30 00:25:56 CUL_HM og.sz.FB.Schlafen1_Btn_01 triggerTo_vFB.01: Short_91
2017-06-30 00:25:56 CUL_HM vFB.01_Btn1 ON
2017-06-30 00:25:56 CUL_HM vFB.01_Btn1 trigLast: og.sz.FB.Schlafen1_Btn_01:short
2017-06-30 00:25:56 CUL_HM vFB.01_Btn1 trig_og.sz.FB.Schlafen1_Btn_01: Short_91
2017-06-30 00:25:56 CUL_HM vFB.01_Btn1 virtActState: ON
2017-06-30 00:25:56 CUL_HM vFB.01_Btn1 virtActTrigNo: 91
2017-06-30 00:25:56 CUL_HM vFB.01_Btn1 virtActTrigRpt: 1
2017-06-30 00:25:56 CUL_HM vFB.01_Btn1 virtActTrigType: short_Release
2017-06-30 00:25:56 CUL_HM vFB.01_Btn1 virtActTrigger: og.sz.FB.Schlafen1_Btn_01
2017-06-30 00:25:56 CUL_HM og.sz.FB.Schlafen1_Btn_01 triggerTo_vFB.01: Short_91_ack

Gibt es eine Möglichkeit dieses Verhalten so zu ändern dass der Button 1 jeweils nur ein ON auslöst und der Button 2 nur ein OFF. Also die Toggle Funktion des vFB auszuschalten?

Mit freundlichem Gruss

Philipp

[rvideobaer]

Hallo,

das verhalten ist doch sicher auf den virtuellen Fernbedienungsaktor zurückzuführen. Da müsste man schauen ob sich hier das toggle verhindern lässt. Wobei ich das Konzept noch nicht verstehe, wozu der virtuellen Fernbedienungsaktor?

Gruß Rolf

[Pfriemler]

Ist es nicht sogar so, dass beide Tasten nur toggeln, der vFB also quasi mit zwei Einzeltasten gepeert ist?
Bei Homematic wird die Reaktion auf die andere Taste beim Peeren automatisch per Register unterbunden. Das bildet ein viirtueller Aktor offenbar nicht nach.
Ich würde die Zustansermittlung eher mit einem dummy und notifys oder gleich einem DOIF tun. Das peering mit dem vFB sorgt dann nur für die Betätigungsquittung (ACK) und ist daher auch sinnvoll.

[pschlaeppi]

Hallo zusammen,

Danke für eure Feedbacks.

@Rolf: Peering mit dem virtuellen Aktor sorgt für die Quittung so dass auf der Fernbedienung das LD grün oder allenfalls rot leuchtet um zu bestätigen ob der Befehl angekommen ist oder nicht. Und wenn ich es dann schon mal habe, hätte ich ja auch das notify auf den virtuellen Aktor legen können der einen kürzeren Namen hat zum weiter auswerten. Ich bin mit dir einige das es dasVerhalten des virtuellen Aktors zu sein scheint, von der Fernbedienung bekommt er ja nur Long oder Short Press.

@Pfriemler: Werde ich dann wohl müssen ausser es wüsste jemand ob das Verhalten des viruellen Aktors irgendwie doch anpassbar wäre das er sich gleich verhält wie ein Hardware Aktor.

Grüsse Philipp

[rvideobaer]

Hallo,

ich dachte das man das überwachen über die VCCU erreichen kann, oder verstehe ich da etwas falsch? Ich habe nur Homematic Geräte und die versucht immer direkt zu peeren. Aber man kann doch auch den Button der FB mit der VCCU peeren und erhält dann eine Rückmeldung (LED Grün).

Gruß Rolf

[pschlaeppi]

Hallo Rolf,

Ja kann man auch an die VCCU peeren. Dann musst du dort ein paar virtuelle Devices anlegen. Da war glaube ich mal ne Limite von 50. Da ich mehr als die 50 zusammenkriege, mach ich zum Beispiel pro FB einen virtuellen Aktor und weiss dann über den Namen auch gleich zu was es gehört.

Gruss Philipp

[rvideobaer]

Hallo,

allso Du musst bei der Vccu nicht für jedes eines anlegen. Und Du wirst doch nicht mehr als 50 virtuelle Devices haben? Ein paar echte die den Ack selbst senden können werden doch wohl auch dabei sein.

Gruß Rolf

[Pfriemler]

Ja, bis man das verstanden hat ... vor allem weil eine VCCU nur virtuelle Buttons bereitstellt, die man (für HomeMartic eigentlich gänzlich verkehrt) ebenfalls mit Buttons peeren kann. Virtuelle Aktoren wären in der Tat wünschenswert, aber dann doch sehr speziell und das Meiste lässt sich mit wenig Aufwand auch FHEM-typisch übergreifend lösen.
Für das reine Senden der Bestätigung (LED grün) reicht sogar einer mit notfalls 20 oder mehr Peers (gibt es eine Obergrenze *kopfkratz* ?)

[betateilchen]

Für das reine Senden der Bestätigung (LED grün) reicht sogar einer mit notfalls 20 oder mehr Peers (gibt es eine Obergrenze *kopfkratz* ?)

Für das reine Senden "grün" braucht man gar nichts. Man kann immer direkt mit der zentralen Stelle peeren, ohne dass es dafür irgendeines vorher definierten Buttons bedarf.

[martinp876]

Eine vccu unterstützt Kanäle. Button oder aktor ist egal.
Virtuelle aktoren beantworten einem sensor/button die measages. Mehr macht auch ein realer aktorkanal nicht.
Was ein aktor dann so macht ist seine Sache. Das ist auch bei virtuellen so. Das liegt also beim Anwender und ist frei programmierbar.
Peeren sollte man immer mit einem kanal( nicht mit ios!!!) . das ist sauber und somit zukinftsicher. Man beugt Problemen bei Updates vor

[Pfriemler]

Was ein aktor dann so macht ist seine Sache. Das ist auch bei virtuellen so. Das liegt also beim Anwender und ist frei programmierbar.

Oh, ist es das? Das habe ich noch nicht gefunden, denn eigentlich ging es genau darum.

Peeren sollte man immer mit einem kanal( nicht mit ios!!!)...

[martinp876]

Ein realer aktor macht was man programmiert. Toggeln, einscalten, ausschalten oder nur manchmal einschalten odee noch kompliziertwre dinge. Allerdings nur wenn man ihn programmieet. Nun - hm macht eine default provrammierung. Die haengt davon an wie man peert. Single oder dual. Mir ist das egal weil ich danach alles mit templates ueberschreibe. Wer das nicht macht muss wissen, WIE er einst das peering machte.
Evtl. Ist schon aufgefallen, dass man einen virtuellen aktor nicht programmieren kann. Er toggelt nur ( user sicht).
Seine eigentliche aufgabe ist, die messages des sensors zu quitieren um ihn gluecklich zu machen. Weiter wird an den user die info gegeben: habe trigger erhalten. Mehr ist nicht. Also muss der user die fehlende programmierung erstellen. Ueber nptify, user readings, myutil oder was ihn einfaellt. Wie sonst sollte es gehen?

Die gefundene implementierung, dass 2 taster ein toggel ausloesn ist ein gueltiger fall fuer bspw eine flurbeleuchtung. Aber eben nur einer von tausenden.

[Pfriemler]

Evtl. Ist schon aufgefallen, dass man einen virtuellen aktor nicht programmieren kann. Er toggelt nur ( user sicht).

Was dem Themenersteller auffiel und ich in Antwort #2 bereits vermutete.

Also muss der user die fehlende programmierung erstellen. Ueber nptify, user readings, myutil oder was ihn einfaellt.

Aber eben so, dass er nicht im virtuellen Kanal der VCCU oder eines Dummys, sondern in einer weiteren Definition dies realisiert. Das alleinige Peering mit einem virtuellen Kanal sorgt nur für die Quittung.

Wie sonst sollte es gehen?

Nun, indem der virtuelle Kanal einen Mindestsatz an virtuellen Registern erhält und diese sich programmieren ließen, bzw. auch automatisch gesetzt werden - bei einem dual peer passiert das ja ohne Zutun des Benutzers automatisch.
Üblicherweise gibt es zu jeder gepeerten Taste bei realen HM-Geräten ja je einen Registersatz (stark vereinfacht) fürs Ein- und Ausschalten - shOnTime bei einem Taster, mit dem der (dual) gepeerte Aktor ausgeschaltet wird, ist völlig sinnfrei, aber theoretisch vorhanden - wird halt nur nie zur Anwendung kommen, weil die Sprungbedingungen so "verbogen" sind, dass die Ausschalttaste niemals zum Einschalten führen kann und umgekehrt. Sowas ließe sich nachbilden, aber wozu der unnötige Aufwand, wenn es, wie Martin richtig sagt, auch mit userReading, myUtil, notify, DOIF oder wasauchimmer viel einfacher und dazu universeller geht?

Und um auf die Eingangsfrage zu kommen:

Gibt es eine Möglichkeit dieses Verhalten so zu ändern dass der Button 1 jeweils nur ein ON auslöst und der Button 2 nur ein OFF. Also die Toggle Funktion des vFB auszuschalten?

Nein. Workarounds sind aber genügend kommuniziert.

[pschlaeppi]

Hallo zusammen,

Herzlichen Dank an alle. Das klare "Nein" oder halt fast lieber das"wie" habe ich gesucht.

Habe natürlich nicht nur virtuelle. Inzwischen etwa 100 Homematic, 20 EnOcean, 12 Elero, 50 TRX_LIGHT und TRX_WEATHER,etwa 10 Squeezeboxen und Enigma dran.


Vielleicht noch schnell zum Hintergrund warum ich danach gefragt hatte. Ich habe mir bereits mit Intertechno FBs eine
Fernbedienung zusammen gezimmert für meine Squeezeboxen mit Sprachausgabe (Sehbehinderung) welche jeweils ausgibt welcher Sender gespielt wird oder welche Playlist oder Random Mode gestartet etc. Mit HM FBs hätte ich nun zusätzlich Long/Short was mir doppelt soviele Möglichkeiten gibt. Hier möchte ich nun noch Licht oder Rollos mit Ansage des Zustandes rauf packen. So habe ich ne taktile FB :
- Im Namen der Fernbedienung ist drin wo sie ist.
- im virtuellen Device vFB Namen habe ich dann mit _ getrennt noch den Befehl dran hängen.
   Zum Beispiel "vFB.01_playlist" oder "vFB.01_mode".
- Aus dem Event beim Aufruf kriege ich dann On oder Off.

In der Fernbedienungsroutine trenne ich es dann. Aus dem vFB wiess ich welche FB und damit welchen Radio/Raum ich steuern will, mit dem UpDown weiss ich den Befehl, wenn im PlaylistMode mit dem On gehts jeweils alphabetisch rauf zur nächsten Playliste und mit dem Off runter. Im Favorites Mode sind es die Radio Sender und im Track Mode den nächsten Song oder den letzten. Daher benötige ich bei mehrmaligem Druck ein On damit es immer aufwärts geht. Toggle wäre da ein bisschen wie treten an Ort.

Da ein paar HM FBs dazu kommen, wollte ich jetzt natürlich nicht meine ganzen Routinen umschreiben und weitest möglich wieder recyclen. Werde dann wohl jetzt jeweils den Type abfragen müssen und so entsprechend spezifisch
CUL_HM oder TRX_LIGHT anders auswerten oder nochmal ne ebene dummys dazwischen schieben, aber das hilft nicht bei der Übersichtlichkeit. Werd mir was überlegen, kommen ja schon bald Ferien.

Nochmals danke,

Grüsse Philipp