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.
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
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:
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.
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
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 ...
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
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.
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
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:
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:
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,
define Garten_Licht_EIN_30 notify SCHALTER_SCHLAF_Btn_02:Short.* set GARTEN_LICHT on-for-timer 30
und zusätzlich Einschalten überhaupt:
define Garten_Licht_EIN notify SCHALTER_SCHLAF_Btn_03:Short.* set GARTEN_LICHT on
und zusätzlich Ausschalten komplett: (über langen Tastendruck).
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.
(
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.
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
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 activeEventMonitor:
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
Weil Du nur einen Teil deiner Events zeigst? Oder nur einen Teil Deiner Konfig.
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 ::)
Hat aber auch den Vorteil bei nicht bidirektionale Kommunikation, das in der Regel wirklich geschaltet wird und das grüne Licht dann richtig ist.
Ok FS20 - wenn Du es so siehst ;D
ist zwar jetzt OT aber wie machst du dann das notify ?
mit einer if-Abfrage im notify?
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: 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?)
webCmd statusRequest:toggle:on:offIm eventmonitor sehe ich bei kurzem Drücken (vorher war aus):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: 67nochmaliges Drücken "kurz" schaltet aus2019-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: 68Also identisch, der Aktor toggled aber? webCMD?
Langes Drücken schaltet auch ein: Warum? Ist der Grund , dass beide Channels der Taste gepeert sind?
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: 69und 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"?
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:
webCmd statusRequest:toggle:on:offhier noch die List von Schalter und Aktor
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:offHier das List des SCHALTER_SCHLAF_Btn_01
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 GARTENHAUSVielen Dank , leider ist die Antwort es länger geworden.
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).
@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 (https://wiki.fhem.de/wiki/HomeMatic_Register_programmieren#Gezieltes_Schalten_eines_.28unsichtbaren.29_Aktors_mit_nur_einer_Taste)...
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.
Ich habe das notify für langen Tastendruck seit Jahren auf "LongRelease.*" definiert.
Macht jetzt nicht so einen großen Unterschied, dass erst auf das Loslassen nach langem Druck getriggert wird, funktioniert aber reibungslos.
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?
Ich hatte erst noch was Anderes im Kopf als Pfriemlers Variante, die funktioniert aber nicht. Seine Variante ist schon die Beste, glaube ich.
LongRelease ist halt das Problem, das kommt a) nur bei gepeerten Tasten? und b) es gibt Leute (vor allem Frauen?), die Drücken den Schalter bis was passiert. Die kommen mit LongRelease nur per Zufall zum Erfolg. Aber short und long unterschiedlich ist für die auch nichts. ;D
Ich will es nur zu Bedenken geben. Alles was über eine einfache Schalterwippe hinausgeht, ist für nicht Eingeweihte "anspruchsvoll" zu Bedienen.
Gruß Otto
Ich hätte ja auch nichts über short und long geschrieben, wenn ich gewusst hätte das es sich um einen HM-Aktor handelt.
Dann ist das peeren mit der VCCU in meinen Augen nicht sinnvoll.
Ich würde erst einmal alle Kanäle präventiv mit einem Kanal der vccu peeren. Grund:
1) ich will longRelease sehen
2) das device unterstützt lacyConfig. Beim trigger eines Kanals des lacyconfigdevice AN DIE VCCU kann fhem mut dem device kommunizieren, es prüfen und konfigurieren. Das will ich so oft wie möglich haben.
=> Alle Kanäle jedes lacyConfig device werden mit einem(identischen) kanal der vccu gepeert, den ich ccuBtnLzyCfg nenne.
Ansonsten peere ich direkt, was geht. Das freut die Frau, wenn wieder einmal der raspi und seine sdkarte stirbt. Dann geht wenigstens noch etwas.
Hallo,
vielen Dank für die Unterstützung bisher. Den 4 fach Aktor habe ich benutzt, da ich daran leicht eine Glühbirne anschliessen kann und damit meine Fortschritte sehe.
Ich hab die Anfänge der "homematic" verstanden, meine ich. Hab Aktoren so belegt, dass diese nur bei "kurz" einschalten und bei "lang" ausschalten, und, alternativ, nur auf einen Taster einschalten und einen anderen ausschalten.
Ich hab die Taster zuerst mit der VCCU zuerst gepeert und dann mit dem jeweiligen Aktor.
In den Reading der VCCU sehe ich jetzt aber:
state
CMDs_done 2019-01-06 14:29:42
unknown_36569B received 2019-01-06 09:12:24
unknown_365924 received 2019-01-05 08:37:04
etc
.
.
.
Das
"unknown" in den Readings der VCCU stört mich jetzt noch. Ist da noch versteckt, was mir nicht bewusst ist? HM zeigt alles ok an.
Ich will ja eigentlich mit 2 Taster die Alarmanlage einschalten und ausschalten. Dies ist die nächste Aufgabe. Ich lass den Thread erstmal offen, schliesse ihn dann, sobald ich den channel in der Alarmanlage habe.
KLeiner Hinweis: In der EinsteigerDoku auf Seite 78 oben sollte statt
Zitatset <devName> saveConfig <file>
get <devName> saveConfig <file>
Vielen Dank bis hierher
Hi,
unknown_36569B ...
Sind HM Geräte die Du nicht in deinem FHEM definiert hast/hattest. Der IO empfängt Telegramme von denen, die VCCU "drückt sie quasi in den Skat."
Es sind entweder Deine Geräte oder wenn Du keine weiter hast, die Geräte deiner Nachbarn.
Gruß Otto
36569B ist doch sein Taster, mit dem er seit Tagen arbeitet.
Bei mir stehen im unknown aber auch diverse Geräte, die ich längst definiert habe.
Vermutlich wird mit dem unknown weiteres Gemecker im Log unterdrückt? jedenfalls kein Grund zur Sorge.
Ok hab ich nicht geblickt, kann sein, dass es aus der Zeit vor der Definition ist. Ich bin der Meinung man kann die Readings löschen. Wenn es akut vorhanden ist wird die VCCU sie wieder erstellen.
deletereading VCCU unknown_.* oder gibt es da was besseres?
Gruß Otto
Hallo,
ihr seid Spitze 8) 8) und ich bin der, der seit Tagen an dem Taster rummacht, korrekt ::) ::).
die unknown_36569B ... Liste sind alle HM devices, die ich aktuell definiert habe, und zwischenzeitlich umbenannt (rename).
Ich mache mal "deletereading VCCU unknown_.*.
Schönen Sonntagabend.
oder
set vccu clear unknownDev
Hallo, ich weiss schon, der mit dem Schalter :-\ :-\
ganz bin ich noch nicht durch, leider.
Bei meiner Alarmanlage (Modul Alarm in FHEM) möchte ich ja einen Taster als "Widerruf" für einen Alarmlevel benutzen und muss dazu in die Konfigurationstabelle den entsprechenden Trigger des Schalters eintragen. Und da habe ich ein Problem mit der Syntax.
Bei dem Homematic Bewegungsmelder innen: (HM-SEC-MDIR3) ist die korrente Syntax des "Auslösung durch RegExp" (so die Beschreibung in der Alarmanlage) der Ausdruck "BEWEGUNG_WINTER:motion"
(mein Bewegungsmelder heisst BEWEGUNG_WINTER). Sobald Bewegung erkannt wird, löst der Alarm aus. Das tuts. Jetzt suche ich die RegExp für den Taster 5?
Mit dem Taste 5 der HM-PB-6-WM55 möchte ich den Widerruf des Alarmes auslösen. Dafür benötige ich die Syntax für das Feld "Auslösung durch RegExp", analog zu "BEWEGUNG_WINTER:motion" als Auslösung für RegExp für den eigentlichen Alarm.
Meine Idee war SCHALTER_SCHLAF_Btn_05:trigger zu nehmen (adäquat zu BEWEGUNG_WINTER:motion) Tuts aber leider nicht.
Der list des Tasters SCHALTER_SCHLAF_Btn_05sieht so aus:
Internals:
CFGFN
DEF 36569B05
NAME SCHALTER_SCHLAF_Btn_05
NOTIFYDEV global
NR 207
STATE Short 1_48 (to VCCU)
TYPE CUL_HM
chanNo 05
device SCHALTER_SCHLAF
peerList VCCU_Btn3,
READINGS:
2019-01-06 15:38:43 R-VCCU_Btn3-expectAES off
2019-01-06 15:38:43 R-VCCU_Btn3-peerNeedsBurst off
2019-01-06 10:21:17 R-sign off
2019-01-06 15:38:42 RegL_01. 00:00 04:10 08:00 09:00
2019-01-06 15:38:43 RegL_04.VCCU_Btn3 00:00 01:00
2019-01-06 15:38:42 peerList VCCU_Btn3,
2019-01-07 14:13:21 state Short 1_48 (to VCCU)
2019-01-07 14:13:21 trigger Short_48
2019-01-07 14:13:21 trigger_cnt 48
helper:
BNO 48
BNOCNT 1
peerIDsRaw ,07065703,00000000
expert:
def 1
det 0
raw 1
tpl 0
regCollect:
role:
chn 1
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
alarmDevice Sensor
alarmSettings alarm0,|SCHALTER_SCHLAF_Btn_05:trigger|Alarm gecancelt |off
model HM-PB-6-WM55
peerIDs 00000000,07065703,
Der Taster erzeugt folgendes Events:
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF CMDs_done
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF SCHALTER_SCHLAF_Btn_05 Short
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF_Btn_05 Short 1_49 (to VCCU)
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF_Btn_05 trigger: Short_49
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF_Btn_05 trigger_cnt: 49
2019-01-07 14:23:54 CUL_HM VCCU_Btn3 trigLast: SCHALTER_SCHLAF_Btn_05:short
2019-01-07 14:23:54 CUL_HM VCCU_Btn3 trig_SCHALTER_SCHLAF_Btn_05: Short_49
Vielen DanK nochmals .. vom Schaltermann .. 8) 8) 8)
wieso "trigger"? Ein Trigger stößt etwas an. Hier ist es ein Event. Bewegungsmelder senden das Event "motion", der Taster sendet Short oder Long ( und noch ein bisschen Text dahinter.
SCHALTER_SCHLAF_Btn_05:Short.*
müsste also wie beim Notify funktionieren...
Hi Pfriemler,
das wars, ..vielen Dank. Hast du mir noch ne Leseempfehlung, damit ich solche Fragen nur einmal stellen muss!
Vielen Dank
Uwe
Einsteiger-PDF mit Homematic-Anhang.
Hast Du schon gelesen?
Lies es nochmal. Man entdeckt und versteht immer wieder was neues.
ok, Danke mach ich..
Uwe
Zitat von: UweUwe am 04 Januar 2019, 23:02:05
ch 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). Da
Httest du doch alles schon
Hallo Paul,
sorry, dass ich nochmals gefragt habe.
Wenn man das Ergebnis kennt, so kann man sich das Ergebnis erklären: alles was mit ...Short.* ankommt.
Ich hatte mir die Ereignisse angeschaut:
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF SCHALTER_SCHLAF_Btn_05 Short
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF_Btn_05 Short 1_49 (to VCCU)
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF_Btn_05 trigger: Short_49
2019-01-07 14:23:54 CUL_HM SCHALTER_SCHLAF_Btn_05 trigger_cnt: 49
2019-01-07 14:23:54 CUL_HM VCCU_Btn3 trigLast: SCHALTER_SCHLAF_Btn_05:short
2019-01-07 14:23:54 CUL_HM VCCU_Btn3 trig_SCHALTER_SCHLAF_Btn_05: Short_49
Mein Tip war ....05:Short oder 05: trigger, logischer ist natürlich ...05:Short.* Meinen Tip habe ich erfolglos getestet.
Ich gelobe Besserung. Aber bleibt bitte im positiven Mode. Der Umgangston in und um das Modul ALARM ist ... :-\.
Uwe
ZitatDer Umgangston in und um das Modul ALARM ist ... :-\.
das musst du genauer erklären...
Zitat von: UweUwe am 07 Januar 2019, 20:39:39
Hallo Paul,
Ich gelobe Besserung. Aber bleibt bitte im positiven Mode. Der Umgangston in und um das Modul ALARM ist ... :-\.
Uwe
nt
Hallo Uwe,
sorry, wenn mein Beitrag negativ rübergekommen ist. Sollte eigelich positiv sein, da du das mit dem notify bereits hattest.
Ne, d´dein Beitrag ist nicht negativ rübergekommen. Im Gegenteil. Ich hab mich etwas geschämt, dass ich dasselbe wieder frage.
Ich bin begeistert von dem Support und hoffe ihn nicht durch dumme Fragen zu verlieren..
Ich bin etwas geschockt, da ich schon an dem Modul "Alarm" weiterlese und da solche Threats lese:
Da traut man sich ja nichts mehr zu fragen und ich erwarte schon, dass ich in dem Umfeld "ALARM" nicht ohne Fragen durchkomme.
In dem Umfeld:
Zitat
Antw:Neues Modul für Alarmanlage
« Antwort #1109 am: 20 Juni 2018, 09:40:24 »
Alles gut ...