[Gelöst)] Taster (WM-PB-6-WM55) als Sensor Widerruf in Alarmanlage

UweUwe · 04 Januar 2019, 15:20:51

Hallo,
ich habe da noch ne Verständisfrage zu peering.
Mein Ziel ist es, eine Taste (kurz) oben links,(1) als "Widerruf" für alle Alarmlevel der "FHEM Alarmanlage" zu verwenden.
Die restlichen 5 Taster für zukünftige Aufgaben vorzubereiten,

HM config-Check sagt "ok" nach pairen des Tasters.

Ich möchte erstmals alle 6 Channels des Tasters über FHEM ziehen und dann mit "Aktor" devices später peeren, die aufgrund des Tasters was machen sollen.
Ich stelle mit jetzt vor, dass ich alle 6 Channels des Tasters mit den VCCU peeren muss. Oder sind die Kanäle des Schalters schon mit der VCCU-Zentrale aktuell gepeert?
Channel_1 ist mit Rauchmeldern gepeert. Ich mir jetzt noch mehr Channels in der VCCU angelegt. Jetzt sind es erstmals 10. Habe ich erweitert.

Code Auswählen

set VCCU virtual 10

Ich möchte ein "grünes" ok Licht auf den Tastern zurückbekommen. Falls ganz hinten dann ein FHEM Aktor etc steckt, der kein feedback schickt, ist das grüne Licht eben nicht so aussagekräftig. Aber zumindest an FHEM ist es korrekt überttragen worden, der Tastendruck.

Frage 1:
Muss ich einfach den channel_01 "SCHALTER_SCHLAF_Btn_01" umbennen, mit dem Attribut "Sensor" versehen (damit die Alarmanlage dies als Aktor erkennt) und das wars?
Oder muss ich den Channel noch peeren mit der VCCU (ich würde jetzt Kannal 2 der VCCU bevorzugen:

set SCHALTER_SCHLAF_Btn_01 peerchan

VCCU-Btn2 ?
Gerne lese ich es nach, aber wo?

Frage 2:
Angenommen ich möchte mit dem zweiten Schalter (Kanal SCHALTER_SCHLAF_btn_02)ein Licht(GARTEN_LICHT) einschalten für 30 sec . GARTEN_LICHT kann "on-for-timer"
Garten_Licht ist eine FritzboxSteckdose und kein HM Gerät.
Ich verstehe schon, dass ich auch driekt HM-Geräte (Schalter mit Aktoren) peeren kann. Das muss ich mir auch noch anschauen, spielt aber ja hier keine Rolle und will ich auch nicht.

der Befehl hiesse dann vielleicht

Code Auswählen

define Garten_Licht_EIN notify channel_02_Schalter_BTN_02:on GARTEN_LICHT on-for-timer 30

Hier die Daten

Dazu habe ich mir noch mehr Channels in der VCCU angelegt. Jetzt sind es erstmals 10. Habe ich erweitert.

WM-PB-6 WM55 ist gepairt:

Code Auswählen

Internals:
   CFGFN      
   DEF        36569B
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     109
   NAME       SCHALTER_SCHLAF
   NOTIFYDEV  global
   NR         362
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 SCHALTER_SCHLAF_Btn_01
   channel_02 SCHALTER_SCHLAF_Btn_02
   channel_03 SCHALTER_SCHLAF_Btn_03
   channel_04 SCHALTER_SCHLAF_Btn_04
   channel_05 SCHALTER_SCHLAF_Btn_05
   channel_06 SCHALTER_SCHLAF_Btn_06
   lastMsg    No:1D - t:10 s:36569B d:070657 0100000000
   myHmUART_MSGCNT 109
   myHmUART_RAWMSG 050100331DA01036569B0706570100000000
   myHmUART_RSSI -51
   myHmUART_TIME 2019-01-04 13:41:29
   protLastRcv 2019-01-04 13:41:29
   protRcv    109 last_at:2019-01-04 13:41:29
   protSnd    85 last_at:2019-01-04 13:41:29
   protState  CMDs_done
   rssi_at_myHmUART cnt:109 min:-63 max:-46 avg:-51.78 lst:-51 
   READINGS:
     2019-01-04 13:06:53   CommandAccepted yes
     2019-01-04 13:07:46   D-firmware      1.2
     2019-01-04 13:07:46   D-serialNr      MEQ0385878
     2019-01-04 13:41:24   PairedTo        0x070657
     2019-01-04 13:07:46   R-pairCentral   0x070657
     2019-01-04 13:41:24   RegL_00.         00:00 02:01 0A:07 0B:06 0C:57 18:00
     2019-01-04 12:20:17   alive           yes
     2019-01-04 13:41:17   battery         ok
     2019-01-04 12:20:17   powerOn         2019-01-04 12:20:17
     2019-01-04 12:20:17   recentStateType info
     2019-01-04 13:41:29   state           CMDs_done
   helper:
     HM_CMDNR   29
     PONtest    1
     cSnd       0107065736569B06040000000001,0107065736569B0603
     mId        00A9
     regLst     ,0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +36569B,00,00,00
       nextSend   1546605690.04669
       prefIO     
       rxt        2
       vccu       
       p:
         36569B
         00
         00
         00
     mRssi:
       mNo        1D
       io:
         myHmUART:
           -45
           -45
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       dev        1
     rpt:
       IO         myHmUART
       flg        A
       ts         1546605689.75031
       ack:
         HASH(0x35db268)
         1D800207065736569B00
     rssi:
       at_myHmUART:
         avg        -51.7889908256881
         cnt        109
         lst        -51
         max        -46
         min        -63
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      myHmUART
   IOgrp      VCCU:myHmUART
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   model      HM-PB-6-WM55
   room       CUL_HM,SCHLAFZIMMER
   serialNr   MEQ0385878
   subType    remote
   webCmd     getConfig:clear msgEvents

Die VCCU ist funktionefähig und funktioniert auch mit anderen HM Geräten. Der Channel 1 ist durch die Rauchmelder belegt. Mit welchem Channel die übrigen devices belegt sind, kann ich nicht beurteilen, würde mich aber interessiert.

Code Auswählen

Internals:
   DEF        070657
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     14
   NAME       VCCU
   NOTIFYDEV  global
   NR         117
   NTFY_ORDER 50-VCCU
   STATE      myHmUART:ok,
   TYPE       CUL_HM
   assignedIOs myHmUART
   channel_01 RAUCHMELDER_Team
   channel_02 VCCU_Btn2
   channel_03 VCCU_Btn3
   channel_04 VCCU_Btn4
   channel_05 VCCU_Btn5
   channel_06 VCCU_Btn6
   channel_07 VCCU_Btn7
   channel_08 VCCU_Btn8
   channel_09 VCCU_Btn9
   channel_0A VCCU_Btn10
   myHmUART_MSGCNT 14
   myHmUART_RAWMSG 0500003100841036569B00000006000000
   myHmUART_RSSI -49
   myHmUART_TIME 2019-01-04 12:16:24
   protSnd    31 last_at:2019-01-04 14:04:26
   protSndB   30 last_at:2019-01-04 14:04:26
   protState  CMDs_done
   READINGS:
     2019-01-04 14:18:44   state           myHmUART:ok,
     2019-01-04 12:16:24   unknown_36569B  received
     2019-01-01 21:38:39   unknown_44EAD2  received
     2019-01-01 21:02:55   unknown_44EAE2  received
     2019-01-01 21:27:55   unknown_44EAE8  received
     2019-01-01 21:35:17   unknown_44EAEF  received
     2019-01-02 15:55:48   unknown_54A584  received
     2018-12-29 19:59:13   unknown_5FEB7D  received
     2019-01-02 12:49:06   unknown_5FEB91  received
     2019-01-03 16:41:49   unknown_69696D  received
   helper:
     HM_CMDNR   220
     alarmNo    0C
     mId        FFF0
     regLst     ,0
     rxType     1
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         myHmUART
     mRssi:
       mNo        
       io:
         myHmUART:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      myHmUART
   IOList     myHmUART
   IOgrp      VCCU
   expert     2_raw
   model      CCU-FHEM
   room       HomeMatic
   subType    virtual
   webCmd     virtual:update

Pfriemler · 04 Januar 2019, 15:58:40

Dann mal. Der Reihe. Nach.
Mehr virtuelle Kanäle in der VCCU sind immer gut. Ich habe derzeit 20.
Was ich nicht kenne, ist die Alarmanlage. Aber ich denke, sie erwartet Events (Ereignisse, Trigger) eines beliebigen FHEM-Gerätes.

Davon ab als Grundlagengedanken:
1. Das peeren einer HM-Taste mit einem virtuellen Button/channel dient in der Regel einzig dem Erzeugen einer Rückmeldung. Man kann zwar dann auch auf die Statusänderung des virtuellen Buttons reagieren, es ist aber in der Regel sinnvoll, das Event der HM-Taste direkt auszuwerten. So wie Du das mit dem Gartenlicht-Notify machen willst.
2. Für diese Rückmeldung reicht es auch, alle Tasten mit nur einem virtuellen Kanal zu peeren. Bei mir bedient einer ca 30 FB-Tasten.
3. Voraussetzung für eine optische Quittung einer Tastenbetätigung (grüne LED) ist das Peering. Wird kein HM-Gerät verwendet, kann man das eben ersatzweise mit einem virtuellen Button machen. Peert man diese Taste später zusätzlich mit einem HM-Aktor, so wird von ALLEN eine Antwort erwartet, ansonsten wird die Quittung rot. Ein virtueller Button kann also nicht als Ersatzbestätigung dienen für den Fall dass ein gepeerter HM-Aktor nicht reagiert.

Um eine Quittung vom virtuellen Button der VCCU zu bekommen, musst Du peeren.
"set SCHALTER_SCHLAF_Btn_01 peerChan 0 VCCU_Btn2 single set". 0 sowie single set sind unentbehrlich.
Das ist garantiert in mindestens einem Wiki-Artikel beschrieben.

Zum Gartenlicht: Der Trigger ist falsch. Der HM-Button sendet kein "on", sondern "short" oder "long".
Besser wäre also "define Garten_Licht_EIN notify SCHALTER_SCHLAF_Btn_02:Short.* set GARTEN_LICHT on-for-timer 30"
also die richtige Kanalbezeichnung des Buttons ... "Short" ist das Ereignis, aber nicht genau, es kommen noch mehr Zeichen danach, also .*, und dann natürlich set als Befehl ...

Soweit als erste Anregung ...

Otto123 · 04 Januar 2019, 16:54:10

Hi,

@pfriemler Du widersprichst mir auch manchmal

, das set am Schluss ist entbehrlich da "default". Wenn man wenig tippen will würde das so reichen:
set SCHALTER_SCHLAF_Btn_01 peerChan 0 VCCU_Btn2 single

Zum notify: Als Ausgangspunkt Eventmonitor nehmen
https://wiki.fhem.de/wiki/Event_monitor
https://wiki.fhem.de/wiki/Notify

Auch wenn das beim Taster nicht ganz so easy ist. Aber auf Short geht eigentlich eindeutig. Je nach dem welchen Event man nimmt.

Versuch Dich und dann frage weiter

Gruß Otto

Pfriemler · 04 Januar 2019, 19:11:20

Zitat von: Otto123 am 04 Januar 2019, 16:54:10
@pfriemler Du widersprichst mir auch manchmal , das set am Schluss ist entbehrlich da "default"... Wenn man wenig tippen will würde das so reichen:

Wo Du recht hast, hast Du recht. War mir beim Schreiben sogar bewusst. Aber wir hatten ja hier schon Diskussionen zur Vereinfachung vom Peeren durch neue Befehle ... und da war Unterschied zwischen Setzen und Löschen schon deutlicher zu sehen. "set" ist eben das Gegenteil von "unset", und peerChan ist eh ein sensibler Befehl. Je mehr mann/frau da bewusst setzt, umso besser ist es...
Absichtssache.
Wichtig ist aber immer wieder das "single". Dass das nicht default ist, ärgert mich jedes Mal.

Paul · 04 Januar 2019, 20:09:33

Tipp: wenn du mit single peerst, kannst du mit den 5 Tasten noch 5 Geräte an- und ausschalten.

Einmal auf btn_02 Short triggern => an und auf btn_02 Long triggern => aus

UweUwe · 04 Januar 2019, 23:02:05

Hallo, vielen Dank für die Erklärungen.
ich hoffe, dass ich es jetzt richtig verstanden habe:

Ich möchte es aber nochmals ausführlich darstellen:

(1) Mein Taster 1 für das "Entschärfen" der Alarmanlage (modul ALARM in fhem, es werden Events erwartet) hat als Kanal den "SCHALTER_SCHLAF_Btn_01" und die Ereignisse "SCHALTER_SCHLAF_Btn_01:short" (wenn ich kurz taste) und "SCHALTER_SCHLAF_Btn:01:long" (bei langem tasten). Das Event "SCHALTER_SCHLAF_Btn_01:short" möchte ich in dem Modul ALARM verwenden, als Cancel aller Alarme. Damit muss ich dieses als Aktor definieren. Da das Modul "Alarm" kein HM device ist, wird keine Rückmeldung kommen. Die LED leuchtet Orange.

(2) Zusätzlich führe ich ein Peering des "SCHALTER_SCHLAF_Btn_01" mit der VCCU durch mit dem einizigen Hintergrund , dass ich eine "grüne" Rückmeldung möchte.
Dazu muss der Channel SCHALTER_SCHLAF_Btn_01 mit dem (von mir gewählten) Kanal 2 der VCCU gepeert werden:

Code Auswählen

set SCHALTER_SCHLAF_Btn_01 peerChan 0 VCCU_Btn2 single set 0

Damit sind sowohl der "Short" , als auch der "Long" gepeert, ich verwende aktuell nur "Short"

Alle übrigen Channels des Schalters kann ich ebenfalls mit dem VCCU_Btn2 peeren. Warum: Darüber läuft ja eben keine Funktion, sondern diese wird direkt mit den Aktoren verknüft.
Dann aber noch mit dem Zusatz "Short" und "Long". Damit habe ich 12 Schalter in meiner 6 fach Schalter HM_PB_6_WM55.

Die Kommados zum peeren der 6 Channels heissen dann:

Code Auswählen

set SCHALTER_SCHLAF_Btn_01 peerChan 0 VCCU_Btn2 single set 0 
set SCHALTER_SCHLAF_Btn_02 peerChan 0 VCCU_Btn2 single set 0 
set SCHALTER_SCHLAF_Btn_03 peerChan 0 VCCU_Btn2 single set 0 
set SCHALTER_SCHLAF_Btn_04 peerChan 0 VCCU_Btn2 single set 0 
set SCHALTER_SCHLAF_Btn_05 peerChan 0 VCCU_Btn2 single set 0 
set SCHALTER_SCHLAF_Btn_06 peerChan 0 VCCU_Btn2 single set 0

Und auch einen weiteren 6 fach Schalter kann ich identisch mit VCCU_Btn2 "peerChan" machen.

Will ich nun mit den einzelen Kanälen und Optionen des Tasters (short/long) arbeiten, so greife ich direkt auf die Kanäle des Tasters zurück (siehe GARTEN_LICHT):

Beispiele:
Einschalten für 30 Sekunden,

Code Auswählen

define Garten_Licht_EIN_30 notify SCHALTER_SCHLAF_Btn_02:Short.* set GARTEN_LICHT on-for-timer 30

und zusätzlich Einschalten überhaupt:

Code Auswählen

define Garten_Licht_EIN notify SCHALTER_SCHLAF_Btn_03:Short.* set GARTEN_LICHT on

und zusätzlich Ausschalten komplett: (über langen Tastendruck).

Code Auswählen

define Garten_Licht_AUS notify SCHALTER_SCHLAF_Btn_03:Long.* set GARTEN_LICHT off.

etc.

Ich bekomme dann immer grüne LEDs, aber es kann nicht sichergestellt sein, dass das Kommando bei Gartenlicht angekommen ist. Da die Kette nicht durchgehend HM ist.

(

Otto123 · 04 Januar 2019, 23:12:17

Auf die Schnelle: Woher nimmst Du diese Null? Pfriemler meinte mit seiner Erklärung (Satz danach) die 0 hinter peerChan.

ZitatpeerChan 0 VCCU_Btn2 single set 0

Das mit dem Long funktioniert nicht so, da der Event wiederholt wird.

Schau Dir zum Verständnis bitte alles im Eventmonitor an.

Paul · 04 Januar 2019, 23:25:30

Zitat von: Otto123 am 04 Januar 2019, 23:12:17

Das mit dem Long funktioniert nicht so, da der Event wiederholt wird.

Weshalb sollte das nicht gehen?

ich schalte seit Jahren so

Code Auswählen

Internals:
   DEF        .*_Schalter_Btn_03:Long.* set TerrassenPfeiler off
   NAME       Pfeiler_off
   NR         281
   NTFY_ORDER 50-Pfeiler_off
   REGEXP     .*_Schalter_Btn_03:Long.*
   STATE      active
   TYPE       notify
   READINGS:
     2019-01-04 16:40:56   state           active

EventMonitor:

Code Auswählen

019-01-04 23:29:27 FS20 TerrassenPfeiler off
2019-01-04 23:29:27 CUL_HM Keller_Schalter_Btn_03 LongRelease 1_149 (to 999998)
2019-01-04 23:29:27 CUL_HM Keller_Schalter_Btn_03 trigger: Long_149

Otto123 · 05 Januar 2019, 00:15:51

Weil Du nur einen Teil deiner Events zeigst? Oder nur einen Teil Deiner Konfig.

Code Auswählen

2019-01-05 00:11:15 CUL_HM FB12_Btn_01 Long 1_132 (to broadcast)
2019-01-05 00:11:15 CUL_HM FB12_Btn_01 trigger: Long_132
2019-01-05 00:11:15 CUL_HM FB12_Btn_01 trigger_cnt: 132
2019-01-05 00:11:15 CUL_HM FB12 battery: ok
2019-01-05 00:11:15 CUL_HM FB12 FB12_Btn_01 Long
2019-01-05 00:11:15 CUL_HM FB12_Btn_01 Long 2_132 (to broadcast)
2019-01-05 00:11:15 CUL_HM FB12_Btn_01 trigger: Long_132
2019-01-05 00:11:15 CUL_HM FB12_Btn_01 trigger_cnt: 132
2019-01-05 00:11:15 CUL_HM FB12 battery: ok
2019-01-05 00:11:15 CUL_HM FB12 FB12_Btn_01 Long
2019-01-05 00:11:15 CUL_HM FB12_Btn_01 Long 3_132 (to broadcast)
2019-01-05 00:11:15 CUL_HM FB12_Btn_01 trigger: Long_132
2019-01-05 00:11:15 CUL_HM FB12_Btn_01 trigger_cnt: 132
2019-01-05 00:11:16 CUL_HM FB12 battery: ok
2019-01-05 00:11:16 CUL_HM FB12 FB12_Btn_01 Long
2019-01-05 00:11:16 CUL_HM FB12_Btn_01 Long 4_132 (to broadcast)
2019-01-05 00:11:16 CUL_HM FB12_Btn_01 trigger: Long_132
2019-01-05 00:11:16 CUL_HM FB12_Btn_01 trigger_cnt: 132
2019-01-05 00:11:16 CUL_HM FB12 battery: ok
2019-01-05 00:11:16 CUL_HM FB12 FB12_Btn_01 Long
2019-01-05 00:11:16 CUL_HM FB12_Btn_01 Long 5_132 (to broadcast)
2019-01-05 00:11:16 CUL_HM FB12_Btn_01 trigger: Long_132
2019-01-05 00:11:16 CUL_HM FB12_Btn_01 trigger_cnt: 132

Es ist nicht sinnvoll mit Dauerfeuer auszuschalten

Paul · 05 Januar 2019, 00:23:03

Hat aber auch den Vorteil bei nicht bidirektionale Kommunikation, das in der Regel wirklich geschaltet wird und das grüne Licht dann richtig ist.

Otto123 · 05 Januar 2019, 00:28:10

Ok FS20 - wenn Du es so siehst

Paul · 05 Januar 2019, 00:43:22

ist zwar jetzt OT aber wie machst du dann das notify ?

mit einer if-Abfrage im notify?

UweUwe · 05 Januar 2019, 15:26:13

Hallo ,

danke für die guten Antworten und Hinweise:
Event-Monitor habe ich jetzt erstmals richtig verwendet. Danke Otto.
Weiter habe ich einen 4 fach Hutschienen Schaltaktor (AKTOR01_GARTEN) HM-LC-Sw4-DR in FHEM eingebracht und gepairt, erfolgreich. Jetzt will ich den Schaltaktor (1) als Test für den 6 fach Schalter (SCHALTER_SCHLAF) verwenden und zwar die Taste oben links (1) "kurz" für Einschalten und dieselbe Taste "lang" für ausschalten.

ZitatMeine Fragen sind (Erläuterungen weiter unten?)

1. Kann ich von dem 6 fach Taster auch nur den "short" Channel peeren und separat den "long" Channel?
2. Ist das Ein/Ausschalten des Aktors dem webCMD in der Standardeinstellung des Aktors geschuldet.
3. Wie sehe ich aus dem eventmonitor, welche Kommando der Schalter abgibt, wenn ich kurz buw lang drücke. Dies vermute ich dann in das Modul "Alarm" eintragen zu müssen.

Wie gesagt, gepairt sind beide Geräte mit der VCCU:

Jetzt peere ich:

Code Auswählen

set SCHALTER_SCHLAF_Btn_01 peerChan 0 VCCU_Btn2 single set                                         ### ich peere den gesamten Schalter (oder nur :short?) mit der VCCU, ist dies überhaupt notwendig?
set SCHALTER_SCHLAF_Btn_01 peerChan 0 AKTOR01_GARTEN_Sw_01 single set                            ### ich peere den gesamten Schalter (oder nur : short?) mit den 1. Aktor des Schaltaktors.

Logisch wäre für mich, dass ich nur den "SCHALTER_SCHLAF_Btn_01:short" peeren müsste, den Kanal "gibt" es aber nicht. Dass jetzt kurz und lang auf den Aktor wirken ist irgendwie logisch

Ergebnis ist , dass der Schaltaktor (1) bei einmaligem kurzen Drücken einschaltetund bei nochmaligem kurzen Drücken wieder ausschaltet. (ist dies dem webCMD im Aktor geschuldet?)

Code Auswählen

webCmd statusRequest:toggle:on:off

Im eventmonitor sehe ich bei kurzem Drücken (vorher war aus):

Code Auswählen

2019-01-05 14:54:23 CUL_HM SCHALTER_SCHLAF_Btn_01 Short 1_67 (to AKTOR01_GARTEN)
2019-01-05 14:54:23 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Short_67
2019-01-05 14:54:23 CUL_HM SCHALTER_SCHLAF_Btn_01 triggerTo_AKTOR01_GARTEN: Short_67
2019-01-05 14:54:23 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 67
2019-01-05 14:54:23 CUL_HM SCHALTER_SCHLAF_Btn_01 triggerTo_AKTOR01_GARTEN: Short_67_ack
2019-01-05 14:54:24 CUL_HM SCHALTER_SCHLAF_Btn_01 Short 2_67 (to VCCU)
2019-01-05 14:54:24 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Short_67
2019-01-05 14:54:24 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 67

nochmaliges Drücken "kurz" schaltet aus

Code Auswählen

2019-01-05 14:56:16 CUL_HM SCHALTER_SCHLAF_Btn_01 Short 1_68 (to AKTOR01_GARTEN)
2019-01-05 14:56:16 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Short_68
2019-01-05 14:56:16 CUL_HM SCHALTER_SCHLAF_Btn_01 triggerTo_AKTOR01_GARTEN: Short_68
2019-01-05 14:56:16 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 68
2019-01-05 14:56:16 CUL_HM SCHALTER_SCHLAF_Btn_01 triggerTo_AKTOR01_GARTEN: Short_68_ack
2019-01-05 14:56:16 CUL_HM SCHALTER_SCHLAF_Btn_01 Short 2_68 (to VCCU)
2019-01-05 14:56:16 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Short_68
2019-01-05 14:56:16 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 68

Also identisch, der Aktor toggled aber? webCMD?

Langes Drücken schaltet auch ein: Warum? Ist der Grund , dass beide Channels der Taste gepeert sind?

Code Auswählen

2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 Long 1_69 (to AKTOR01_GARTEN)
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Long_69
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 69
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 LongRelease 1_69 (to AKTOR01_GARTEN)
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Long_69
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 triggerTo_AKTOR01_GARTEN: Long_69
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 69
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 triggerTo_AKTOR01_GARTEN: Long_69_ack
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 LongRelease 1_69 (to VCCU)
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Long_69
2019-01-05 14:57:33 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 69

und nochmaliges langes Drücken schaltet aus!

Reagiert der Schaltaktor auf langes Drücken nur, da ich den gesamten 1. Kanal meines Schalters gepeert habe und nicht nur "short"?

Code Auswählen

2019-01-05 15:00:24 CUL_HM SCHALTER_SCHLAF_Btn_01 Long 1_80 (to AKTOR01_GARTEN)
2019-01-05 15:00:24 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Long_80
2019-01-05 15:00:24 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 80
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 Long 2_80 (to AKTOR01_GARTEN)
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Long_80
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 80
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 LongRelease 2_80 (to AKTOR01_GARTEN)
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Long_80
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 triggerTo_AKTOR01_GARTEN: Long_80
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 80
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 triggerTo_AKTOR01_GARTEN: Long_80_ack
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 LongRelease 2_80 (to VCCU)
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger: Long_80
2019-01-05 15:00:25 CUL_HM SCHALTER_SCHLAF_Btn_01 trigger_cnt: 80

Irgendwie habe ich noch ein Verständisproblem: das würde ich gerne lösen, bevor ich jetzt meine Konfiguration weiter zusammenbauen. Deshalb die Fragen oben.
Liegt eine Erklärung im webCMD vom Aktor:

Code Auswählen

webCmd statusRequest:toggle:on:off

hier noch die List von Schalter und Aktor

Code Auswählen


Internals:
   CFGFN      
   DEF        43D9AB01
   NAME       AKTOR01_GARTEN_Sw_01
   NOTIFYDEV  global
   NR         626
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     AKTOR01_GARTEN
   peerList   SCHALTER_SCHLAF_Btn_01,
   READINGS:
     2019-01-05 15:00:25   CommandAccepted yes
     2019-01-05 15:00:27   deviceMsg       off (to VCCU)
     2019-01-05 15:00:27   level           0
     2019-01-05 15:00:27   pct             0
     2019-01-05 15:00:27   recentStateType info
     2019-01-05 15:00:27   state           off
     2019-01-05 15:00:27   timedOn         off
     2019-01-05 15:00:25   trigLast        SCHALTER_SCHLAF_Btn_01:long
     2019-01-05 15:00:25   trig_SCHALTER_SCHLAF_Btn_01 Long_80
   helper:
     dlvlCmd    ++A01107065743D9AB0201000000
     peerIDsRaw ,36569B01,00000000
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   model      HM-LC-SW4-DR
   peerIDs    00000000,36569B01,
   room       GARTENHAUS
   webCmd     statusRequest:toggle:on:off

Hier das List des SCHALTER_SCHLAF_Btn_01

Code Auswählen

Internals:
   CFGFN      
   DEF        36569B01
   NAME       SCHALTER_SCHLAF_Btn_01
   NOTIFYDEV  global
   NR         364
   STATE      LongRelease 2_80 (to VCCU)
   TYPE       CUL_HM
   chanNo     01
   device     SCHALTER_SCHLAF
   peerList   VCCU_Btn2,AKTOR01_GARTEN_Sw_01,
   READINGS:
     2019-01-05 14:18:10   R-AKTOR01_GARTEN_Sw_01-expectAES off
     2019-01-05 14:18:10   R-AKTOR01_GARTEN_Sw_01-peerNeedsBurst off
     2019-01-05 13:35:48   R-VCCU_Btn2-expectAES off
     2019-01-05 13:35:48   R-VCCU_Btn2-peerNeedsBurst off
     2019-01-04 13:07:47   R-sign          off
     2019-01-05 14:18:08   RegL_01.         00:00 04:10 08:00 09:00
     2019-01-05 14:18:10   RegL_04.AKTOR01_GARTEN_Sw_01  00:00 01:00
     2019-01-05 14:18:09   RegL_04.VCCU_Btn2  00:00 01:00
     2019-01-05 14:18:09   peerList        VCCU_Btn2,AKTOR01_GARTEN_Sw_01,
     2019-01-05 15:00:25   state           LongRelease 2_80 (to VCCU)
     2019-01-05 15:00:25   trigger         Long_80
     2019-01-05 15:00:25   triggerTo_AKTOR01_GARTEN Long_80_ack
     2019-01-05 15:00:25   trigger_cnt     80
   helper:
     BNO        80
     BNOCNT     2
     peerIDsRaw ,07065702,43D9AB01,00000000
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     regCollect:
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   alarmDevice Sensor
   alarmSettings alarm0,alarm1,alarm2,alarm3,alarm4,alarm5,alarm6,alarm7,|||off
   model      HM-PB-6-WM55
   peerIDs    00000000,07065702,43D9AB01,
   room       GARTENHAUS

Vielen Dank , leider ist die Antwort es länger geworden.

Pfriemler · 05 Januar 2019, 15:55:45

Zitat von: Paul am 05 Januar 2019, 00:43:22
ist zwar jetzt OT aber wie machst du dann das notify ?
mit einer if-Abfrage im notify?

Nö. Man kann auf einen bestimmten Long triggern, also statt "... notify SCHALTER_SCHLAF_Btn_03:Long.* " auf "notify SCHALTER_SCHLAF_Btn_03:Long.1.*". Das ignoriert alle folgenden Longs ... und sendet ab Long 11, Long 12, ... dann doch wieder Dauerfeuer. Best of both worlds, sozusagen.
Möchte man die Unterscheidung etwas deutlicher zwischen short und long, dann kann man auch auf ...:Long.2.* oder ...:Long.3.* etc triggern.
Das nutze ich bspw. in einem DOIF. So kann ich sogar drei Funktionen unterbringen: kurz (Short), lang (Long.3), extralang (Long.7). Zwar springt das DOIF bei langem Tastendruck zuerst auf den Long.3-Zweig, wenn man aber die Ausführung der Kommandos mit wait verzögert, wird bei längerem Druck Long.7 erreicht, ohne dass der Long.3-Befehl ausgeführt wurde.
Zur Erinnerung für das Notify: Nicht irritieren lassen: Das Event heißt "Long 1_xx (to ....)", aber wegen der nicht erlaubten Leerzeichnen triggert man auf "Long.1.*" (beliebiges Zeichen zwischen Long und 1, beliebige und beliebig viele Zeichen nach der 1).

Pfriemler · 05 Januar 2019, 16:03:43

@UweUwe:

1. Peeren auf einen VCCU-Button und einen externen Aktor ist nicht nötig. Aktor reicht. Rückmeldung ist auch so perfekt: Leuchtet es nach dem Tastendruck rot, ist die Rückmeldung vom Aktor nicht angekommen. Der kann dann trotzdem geschaltet haben, aber seine Rückmeldung ist nicht angekommen. Das zusätzliche Peeren mit dem VCCU-Button sorgt nur für unnütze Funklast.
2. Was im Webfront steht (webCmd), hat nie einen Einfluss auf irgendwelches Verhalten von Peers
3. Default sorgt das Peeren eines Einzeltasters mit einem Schalt-Aktor immer zu einem identischen Verhalten beider Arten von Tastendruck (lang/kurz): Der Aktor ändert seinen Schaltzustand (er toggelt). Bei Dimmern führt ein langer Tastendruck automatisch zum Dimmen (abwechselnd helle/dunkler).
4. Wenn Du eine gezielte Reaktion auf einen langen und einen kurzen Tastendruck haben willst, muss Du weitere Register setzen.
Lies dazu mal im Wiki diesen Abschnitt zum gezielten Schalten eines gepeerten Aktors...

Geänderter Nachtrag: Es gibt für einen Tastendruck keine doppelten Kanäle. Es gilt nur ein Peering. Die Taste sendet entweder short oder (wiederholt) long. Die Reaktion, also was bei einem kurzen oder langen Tastendruck passieren soll, wird ausschließlich im Aktor festgelegt.
Was man machen kann: bei kurzem Tastendruck einen Aktor schalten (hin und her oder nur gezielt eine Richtung) und bei einem langen Tastendruck einen anderen. In solchem Spezialfall peert man die Taste mit beiden Aktoren und schaltet danach in den Aktoren die jeweils unerwünschte Reaktion komplett ab.