Hallo zusammen,
vor 3 Tagen habe ich den Umzug meiner FHEM-Installation von einem Rasp-Pi 1 mit einem Busware_CCD auf einen Raspi-Pi 2 mit einem HM-MOD-RPI-PCB_Modul durchgeführt. Dank Wiki und Otto's Blog hat dies auch recht gut funktioniert.
Jetzt habe ich dazu ein paar generelle Fragen sowie Probleme. Es wäre nett, wenn mir jemand auf die Sprünge hilft.
a) Die D-serialNr die in FHEM angezeigt wird, stimmt nicht mit dem Etikett der ELV-Originalverpackung überein. Leider habe ich vor dem Flashen auf 1.4.1 nicht darauf geachtet was mit dem Auslieferungsstand der FW 1.2.1 angezeigt wurde. Die D-serialNr wird doch aber beim Flashen nicht geändert. Korrekt?
b) Ist es korrekt, dass der hmKey auch bei der Definition des HM-MOD-RPI-PCB- Moduls hinterlegt werden muss, obwohl dieser bereits bei der VCCU hinterlegt ist und in die IOList (z.Zt. sogar als einziger Wert) eingetragen ist? Setze ich dieses Attribut nicht, dann funktionieren meine Remote-Keys zumindest nicht. Es kommt zu AES-Fehlern.
c) Beim Neustart von FHEM erscheint seit dem Einsatz des benannten Moduls folgende Warnung.
016.12.21 11:20:33 1 : PERL WARNING: Argument "1E" isn't numeric in sprintf at ./FHEM/00_HMUARTLGW.pm line 675.
Habe leider keinen Schimmer woher die "1E" ist. Kann jemand was dazu sagen?
Es ist ja auch nicht problematisch, da es nur eine Warnung ist.
Line 675 sieht so aus:
Log3($hash, 4, "HMUARTLGW ${name} AESchannels: " . sprintf("%08x", $peer->{aesChannels}));
d) Wohl mein z.Zt. größestes Problem, da u.a. das Schalten der Alarmanlage damit zusammenhängt.
Mit dem neuen HM-MOD-RPI-PCB_Modul gibt bei mir Schwierigkeiten in Zusammenhang mit AES, welches mit dem "alten Busware_CCD" nicht aufgetreten sind.
Beim Schalten mit meinen Remote-Keys (HM-RC-Sec4-2 und HM-RC-Key4-2) kommt es zu AES-Fehlern. Jedoch nur dann, wenn ich die Tastern "Long" betätige. Mittels "Short" funktioniert es ohne AES Fehler.
Hier (Short) schalte z.B. die Eingangslampe:
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo aesCommToDev: ok
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo battery: ok
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo CMDs_done
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo RemoteHM_Leeloo_disarm Short
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo_disarm Short (to Zentrale_VCCU)
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo_disarm trig_aes_Zentrale_VCCU: ok:4
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo_disarm trigger: Short_4
2016-12-22 13:38:32 CUL_HM RemoteHM_Leeloo_disarm trigger_cnt: 4
Hier (Long) schalte diese nicht:
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo aesCommToDev: fail
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: fail:4
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo aesCommToDev: fail
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: fail:4
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo aesCommToDev: fail
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: fail:4
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo aesCommToDev: fail
2016-12-22 13:38:53 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: fail:4
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo aesCommToDev: fail
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: fail:4
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo aesCommToDev: fail
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: fail:4
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo aesCommToDev: fail
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: fail:4
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo aesCommToDev: fail
2016-12-22 13:38:54 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: fail:4
2016-12-22 13:38:55 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2016-12-22 13:38:55 CUL_HM RemoteHM_Leeloo aesCommToDev: ok
2016-12-22 13:38:55 CUL_HM RemoteHM_Leeloo battery: ok
2016-12-22 13:38:55 CUL_HM RemoteHM_Leeloo CMDs_done
2016-12-22 13:38:55 CUL_HM RemoteHM_Leeloo RemoteHM_Leeloo_light LongRelease
2016-12-22 13:38:55 CUL_HM RemoteHM_Leeloo_light LongRelease 1_4 (to Zentrale_VCCU)
2016-12-22 13:38:55 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: ok:4
Schon mal vielen Dank für eure Unterstützung.
Gruß
Leeloo
Hallo,
Zitat von: Leeloo_Dallas am 22 Dezember 2016, 13:45:55
a) Die D-serialNr die in FHEM angezeigt wird, stimmt nicht mit dem Etikett der ELV-Originalverpackung überein. Leider habe ich vor dem Flashen auf 1.4.1 nicht darauf geachtet was mit dem Auslieferungsstand der FW 1.2.1 angezeigt wurde. Die D-serialNr wird doch aber beim Flashen nicht geändert. Korrekt?
Ja, die Seriennummer wird beim flashen nicht verändert. Die wird direkt so vom Modul gemeldet, evtl. wurde bei eQ-3 der Aufkleber vertauscht. Hatte ich auch schonmal bei einem Aktor.
Zitat
b) Ist es korrekt, dass der hmKey auch bei der Definition des HM-MOD-RPI-PCB- Moduls hinterlegt werden muss, obwohl dieser bereits bei der VCCU hinterlegt ist und in die IOList (z.Zt. sogar als einziger Wert) eingetragen ist? Setze ich dieses Attribut nicht, dann funktionieren meine Remote-Keys zumindest nicht. Es kommt zu AES-Fehlern.
Nein, der AES-Key sollte eigentlich von der VCCU verteilt werden. Passt das IOList-Attribut?
Zitat
c) Beim Neustart von FHEM erscheint seit dem Einsatz des benannten Moduls folgende Warnung.
016.12.21 11:20:33 1 : PERL WARNING: Argument "1E" isn't numeric in sprintf at ./FHEM/00_HMUARTLGW.pm line 675.
Danke, da wurde versucht einen Wert nach Hex zu konvertieren, der schon Hex ist. War ein überbleibsel als der Wert an der Stelle nicht Hex war. Ist behoben. Hat nur die Log-Message betroffen.
Zitat
d) Wohl mein z.Zt. größestes Problem, da u.a. das Schalten der Alarmanlage damit zusammenhängt.
Mit dem neuen HM-MOD-RPI-PCB_Modul gibt bei mir Schwierigkeiten in Zusammenhang mit AES, welches mit dem "alten Busware_CCD" nicht aufgetreten sind.
Beim Schalten mit meinen Remote-Keys (HM-RC-Sec4-2 und HM-RC-Key4-2) kommt es zu AES-Fehlern. Jedoch nur dann, wenn ich die Tastern "Long" betätige. Mittels "Short" funktioniert es ohne AES Fehler.
Damit Long mit einem IO funktioniert, welches sich an die HM Timingvorgaben hält, muss die Fernebdienung wissen, dass da noch ein AES-Request kommt. Ist im entsprechende Peer-Register der Taste das expectAES gesetzt?
Viele Grüße
Michael
ZitatDie D-serialNr die in FHEM angezeigt wird, stimmt nicht mit dem Etikett der ELV-Originalverpackung überein.
Du kannst alle Nummern auf dem Modul prüfen, Du brauchst einen QR Code Reader (z.B.: QR Extreme)
Das Funkmodul hat zwei Codes einen Großen -> D-Serial einen Kleinen -> HMID
Das Adaptermodul (Steckleiste) hat auch eine Seriennummer, die unterscheidet sich von der vom Funkmodul.
Allerdings könnten auch die Aufkleber falsch sein.
Gruß Otto
Super, schon mal Danke für die Antworten :D
a) ich denke auch, dass der Aufkleber falsch war. Werde beim nächstem mal, wenn ich an den Verteilerkasten komme, mal den QR-Code lesen. Danke für den Tipp.
b) die Attribute müssten korrekt gesetzt sein, anbei mal Auszüge der Lists
=> reale Hardware: HM-MOD-RPI-PCB
Internals:
AssignedPeerCnt 28
CFGFN /opt/fhem/mycfg/10_Zentrale_CCD.cfg
CNT 11
DEF /dev/ttyAMA0
DEVCNT 11
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 8
LastOpen 1482411776.51849
NAME Zentrale_CCD
NR 212
PARTIAL
RAWMSG 04020E
RSSI -34
STATE opened
TYPE HMUARTLGW
XmitOpen 1
msgLoadCurrent 7
msgLoadHistory 0/0/0/-1/1/-1/0/1/-1/1/0/0
msgLoadHistoryAbs 7/7/7/7/8/7/8/8/7/8/7/7/7
owner <MEINE hmID>
owner_CCU Zentrale_VCCU
Helper:
CreditTimer 6257
FW 66561
Initialized 1
SendCnt 1025
Ackpending:
....
....
LastSendLen:
3
3
Log:
IDs:
PeerQueue:
PendingCMD:
Roundtrip:
Delay 0.00338983535766602
Loadlvl:
lastHistory 1482505393.13466
Peers:
...
...
Readings:
2016-12-22 14:03:13 D-HMIdAssigned <MEINE hmID>
2016-12-22 14:03:13 D-HMIdOriginal <die org. ID>
2016-12-22 14:03:13 D-firmware 1.4.1
2016-12-22 14:03:13 D-serialNr <hoffentlich die Seriennummer die auch auf dem QR-Code steht ;)>
2016-12-22 14:02:56 D-type HM-MOD-UART
2016-12-19 13:14:02 cmds m b C F i A Z G M R T V W X e f l t u x
2016-12-22 14:03:13 cond ok
2016-12-23 16:03:22 load 7
2016-12-22 14:03:13 loadLvl low
2016-12-22 14:02:56 state opened
Helper:
Attributes:
group System
hmId <MEINE hmID>
hmKey <MEIN hmKey>
icon scc_868
qLen 74
room SYSTEM
=> VCCU
Internals:
CFGFN /opt/fhem/mycfg/10_Zentrale_CCD.cfg
DEF <MEINE hmID>
IODev Zentrale_CCD
NAME Zentrale_VCCU
NOTIFYDEV global
NR 294
STATE Zentrale_CCD:ok,
TYPE CUL_HM
assignedIOs Zentrale_CCD
channel_01 Zentrale_VCCU_Btn1
channel_02 Zentrale_VCCU_Btn2
channel_03 Zentrale_VCCU_Btn3
channel_04 Zentrale_VCCU_Btn4
channel_05 Zentrale_VCCU_Btn5
channel_06 Zentrale_VCCU_Btn6
channel_07 Zentrale_VCCU_Btn7
channel_08 Zentrale_VCCU_Btn8
Readings:
2016-10-27 13:30:29 CommandAccepted yes
2016-10-27 13:47:06 aesKeyNbr 02
2016-12-22 14:03:13 state Zentrale_CCD:ok,
...
...
Helper:
HM_CMDNR 1
mId FFF0
rxType 1
Ack:
Expert:
def 1
det 0
raw 0
tpl 0
Io:
vccu Zentrale_VCCU
ioList:
Zentrale_CCD
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
vrt 1
Tmpl:
Attributes:
IODev Zentrale_CCD
IOList Zentrale_CCD
IOgrp Zentrale_VCCU
group System,System_vDevices
hmKey <MEIN hmKey | diesen musste ich eintragen, damit es funktioniert>
icon system_fhem
model CCU-FHEM
room SYSTEM
subType virtual
webCmd update
c) nichts zu Danken. Ich danke !!!
d) auch hier schicke ich mal die List. Auch hier müsste es ist korrekt sein, da es zuvor mit dem Busware_CCD keine Probleme an dieser Stelle gab.
=> Remote_Leeloo
Internals:
CFGFN /opt/fhem/mycfg/30_remotes.cfg
DEF <Remote ID>
IODev Zentrale_CCD
LASTInputDev Zentrale_CCD
MSGCNT 13
NAME RemoteHM_Leeloo
NOTIFYDEV global
NR 1451
STATE RemoteHM_Leeloo_disarm Short
TYPE CUL_HM
Zentrale_CCD_MSGCNT 13
Zentrale_CCD_RAWMSG 050201431FA240<Remote ID><MEINE hmID>040A
Zentrale_CCD_RSSI -67
Zentrale_CCD_TIME 2016-12-23 14:24:54
channel_01 RemoteHM_Leeloo_armInt
channel_02 RemoteHM_Leeloo_armExt
channel_03 RemoteHM_Leeloo_light
channel_04 RemoteHM_Leeloo_disarm
lastMsg No:1F - t:40 s:<Remote ID> d:<MEINE hmID> 040A
protEvt_AESCom-ok 3 last_at:2016-12-23 14:24:54
protLastRcv 2016-12-23 14:24:54
protSnd 3 last_at:2016-12-23 14:24:54
protState CMDs_done
rssi_at_Zentrale_CCD max:-49 lst:-67 cnt:3 min:-67 avg:-59
Readings:
2016-06-29 13:19:08 CommandAccepted yes
2016-06-29 13:20:43 D-firmware 1.2
2016-06-29 13:20:43 D-serialNr <org. Seriennummer>
2016-05-10 14:49:10 PairedTo 0x<MEINE hmID>
2016-05-10 14:49:10 R-pairCentral 0x<MEINE hmID>
2016-05-10 14:49:10 RegL_00. 02:01 0A:F1 0B:12 0C:34 18:00 00:00
2016-12-23 14:24:54 aesCommToDev ok
2016-06-29 13:18:43 aesKeyNbr 02
2016-12-21 12:59:10 alive yes
2016-12-23 14:24:54 battery ok
2016-12-21 12:59:10 powerOn 2016-12-21 12:59:10
2016-12-21 12:59:10 recentStateType info
2016-12-23 14:24:54 state RemoteHM_Leeloo_disarm Short
Helper:
HM_CMDNR 31
mId 00A6
rxType 20
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +<Remote ID>,00,01,1E
nextSend 1482499494.88591
rxt 2
vccu Zentrale_VCCU
p:
<Remote ID>
00
01
1E
prefIO:
Zentrale_CCD
Mrssi:
mNo 1F
Io:
Zentrale_CCD -65
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rpt:
IO Zentrale_CCD
flg A
ts 1482499494.62723
ack:
HASH(0x3558dd8)
1F8002<MEINE hmID><Remote ID>00
Rssi:
At_zentrale_ccd:
avg -59
cnt 3
lst -67
max -49
min -67
Tmpl:
Attributes:
IODev Zentrale_CCD
IOgrp Zentrale_VCCU:Zentrale_CCD
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.2
group Handsender,System_realDevices
icon scene_keyboard
model HM-RC-Key4-2
room SYSTEM
serialNr <org. Seriennummer>
subType remote
webCmd getConfig:clear msgEvents
Internals:
CFGFN /opt/fhem/mycfg/30_remotes.cfg
DEF <Remote ID>02
NAME RemoteHM_Leeloo_armExt
NOTIFYDEV global
NR 1455
STATE Short (to Zentrale_VCCU)
TYPE CUL_HM
chanNo 02
device RemoteHM_Leeloo
Readings:
2016-06-29 12:52:14 R-sign on
2016-06-29 12:52:14 RegL_01. 04:10 08:01 09:00 00:00
2016-12-20 15:48:28 state Short (to Zentrale_VCCU)
2016-08-24 13:10:08 trigDst_Zentrale_VCCU noConfig
2016-12-20 15:48:28 trig_aes_Zentrale_VCCU ok:18
2016-12-20 15:48:28 trigger Short_18
2016-12-20 15:48:28 trigger_cnt 18
Helper:
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
Tmpl:
Role:
Attributes:
aesCommReq 1
group Handsender
icon control_building_empty
model HM-RC-Key4-2
peerIDs 00000000,
room SYSTEM
Ich wünsche euch schon mal ein frohes Weihnachtsfest.
Gruß
Leeloo
Erst mal ein glückliches, frohes und gesundes Jahr 2017 für euch !!!
Bzgl. Deiner Frage:
ZitatDamit Long mit einem IO funktioniert, welches sich an die HM Timingvorgaben hält, muss die Fernebdienung wissen, dass da noch ein AES-Request kommt. Ist im entsprechende Peer-Register der Taste das expectAES gesetzt?
Viele Grüße
Michael
Nein, einen entsprechenden Eintrag habe ich nicht gesetzt. Dieser war mit dem Busware_CCD bisher nicht nötig.
Mir ist auch nicht klar, was ich dazu als PeerChannel angeben soll, da die Remotes nur Statuswechsel eines Dummy's (z.B. unscharf) auslösen und kein Device direkt schalten. U.a. wird die Steuerung der Alarmanlage nur mit Hilfe verschiedener Dummys gemacht.
Ein
set RemoteHM_Leeloo_disarm regSet expectAES on liefert => Peer not specified
ein
set RemoteHM_Leeloo_disarm regSet expectAES on 0 liefert => Peer not valid
Was muss ich den angeben, wenn keine direkte Kopplung zu einem "Device" sonder zur "Zentrale" gemacht werden kann.
Danke für die Hilfe.
Gruß
Leeloo
Einfach den peer eingeben, zu dem das Register gehört.
Get regList probieren
Hallo LeeLoo,
mach mal get RemoteHM_Leeloo_disarm regTable
Da siehst Du wie es aussehen muss.
Gruß Otto
Hallo zusammen,
Danke für die Rückmeldungen :)
get RemoteHM_Leeloo_disarm regList => liefert
list: register | range | peer | description
1: dblPress | 0 to 1.5s | | time to detect double press
1: longPress | 0.3 to 1.8s | | time to detect key long press
1: sign | literal | | signature (AES) options:on,off
4: expectAES | literal | required | expect AES options:off,on
4: peerNeedsBurst | literal | required | peer expects burst options:on,off
get RemoteHM_Leeloo_disarm regTable => liefert
No regs found for:
RemoteHM_Leeloo_disarm type:remote -
list:peer register :value
1: dblPress :0 s
1: longPress :0.4 s
1: sign :on
Ich stehe immer noch auf dem Schlauch und habe keine Ahnung was ich den nun eingeben kann/soll.
Leider benötige ich nochmals eure Hilfe. Schon mal Danke !!!
LG
Leeloo
hi,
wenn ich das richtig verstehe hast Du keinen Peer, damit braucht auch keiner expectAES
Meine regTable bei einer Kombi wo das gebraucht wird sieht so aus:
No regs found for:
RC41_1 type:remote -
list:peer register :value
1: dblPress :0 s
1: longPress :0.4 s
1: sign :off
4:SW81_3_TorZu expectAES :off
4:SW81_3_TorZu peerNeedsBurst :on
SW81_3_TorZu ist ein Switch(Aktor)
RC41_1 ist die Taste die ihn bedient.
Vielleicht hilft das beim nachdenken. Dir fehlt hier der Aktor(Peer)
set RemoteHM_Leeloo_disarm regSet <Aktor> expectAES on
Gruß Otto
Hallo,
Zitat von: Otto123 am 05 Januar 2017, 13:06:35
wenn ich das richtig verstehe hast Du keinen Peer, damit braucht auch keiner expectAES
Jein. Wenn Fhem AES anfordert und ein IO benutzt wird, das sich an die Homematic Timingvorgaben hält, kann der AES-Request nicht abgesendet werden, da die Fernbedienung bei Long zu schnell den nächsten Request sendet. Der CUL/... hält sich nicht an die Ruheperiode, weswegen es funktioniert.
Der richtige Weg wäre ein virtuelles VCCU-Device zu definieren, die Tasten damit zu peeren und und dann expectAES zu setzen.
https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Virtuelle_Kan.C3.A4le_der_VCCU
Es reicht ein virtueller Aktor, den kann man einfach mit allen Fernbedienungen peeren. Unterscheiden kann man dann anhand des Absenders.
Viele Grüße
Michael
Hi,
Danke für die Erklärungen, das hat mir weiter geholfen. :D
Insbesondere der Hinweis
ZitatDer CUL/... hält sich nicht an die Ruheperiode, weswegen es funktioniert.
erklärt für mich das ungewöhnliche/geänderte Programmverhalten.
Hier, für die Nachwelt, eine Zusammenfassung der Schritte und Codezeilen, welche zur Lösung gehören:
1) virtuelles VCCU-Device definieren (Zentrale_VCCU_Btn4)
2) die Tasten damit peeren
set RemoteHM_Leeloo_disarm peerChan 0 Zentrale_VCCU_Btn4 single set3) expectAES setzen.
set RemoteHM_Leeloo_disarm regSet expectAES on Zentrale_VCCU_Btn4Jetzt werden die "HM Timingvorgaben" eingehalten und AES läuft. ;)
4) Zusätzlich musste ich noch Änderungen in verschiedenen Notify's vornehmen. z.B. von
define n_RemoteHM_Leeloo_light_long notify RemoteHM_Leeloo_light:Long.1[^0-9].* set Licht__EG_Eingang on in
define n_RemoteHM_Leeloo_light_long notify RemoteHM_Leeloo_light:LongRelease.1[^0-9].* set Licht__EG_Eingang off.
Super, vielen Dank für eure Unterstützung. :) :) :)Eine weitere Frage hätte ich jedoch noch in diesem Zusammenhang.
Wie kann ich nun das "virtuelles VCCU-Device" im Notify auswerten?
Ein
define n_RemoteHM_Leeloo_light_short notify RemoteHM_Leeloo_light:Short.* set Licht__EG_Eingang toggle funktioniert, wie bereits erwähnt.
Das Gegenstück mit dem virtuellen Device bekomme ich nicht hin. Hier mein letzter Versuch von vielen.
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:trig_RemoteHM_Leeloo_light:.Short* set Licht__EG_Eingang toggleIch kriege es nicht ausgewertet und stolpere wohl mal wieder "nur" über die Syntax.
LG
Leeloo
So?
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:trig_RemoteHM_Leeloo_light:Short.* set Licht__EG_Eingang toggle
Aber schau Dir den Event genau im Eventmonitor an!
Am Ende kannst Du ein notify machen:
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:trig_RemoteHM_Leeloo_light:Short.*|RemoteHM_Leeloo_light:Short.* set Licht__EG_Eingang toggle
Gruß Otto
Ich hab schon x-Varianten ausprobiert und denke es liegt an den Leerzeichen bzw. am zusätzlichen Doppelpunkt.
Hier mal der Auszug aus dem Eventmonitor.
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo aesCommToDev: pending
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo aesCommToDev: ok
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo battery: ok
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo CMDs_done
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo RemoteHM_Leeloo_light Short
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo_light Short (to Zentrale_VCCU)
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo_light trig_aes_Zentrale_VCCU: ok:43
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo_light trigger: Short_43
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo_light trigger_cnt: 43
2017-01-06 18:41:47 CUL_HM Zentrale_VCCU_Btn3 trigLast: RemoteHM_Leeloo_light:short
2017-01-06 18:41:47 CUL_HM Zentrale_VCCU_Btn3 trig_RemoteHM_Leeloo_light: Short_43
2017-01-06 18:41:47 CUL_HM Zentrale_VCCU_Btn3 trig_aes_RemoteHM_Leeloo_light: ok:43
Folgende Versuche funktionieren nicht:
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:trig_RemoteHM_Leeloo_light:Short.* set Licht__EG_Eingang toggle
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:trig_RemoteHM_Leeloo_light: Short.* set Licht__EG_Eingang toggle
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:trig_RemoteHM_Leeloo_light: Short* set Licht__EG_Eingang toggle
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:trigLast: RemoteHM_Leeloo_light:short.* set Licht__EG_Eingang toggle
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:RemoteHM_Leeloo_light:short.* set Licht__EG_Eingang toggle
:-\ Ich sehe den Wald vor lauter Bäumen nicht,....
ganz einfach: Event -> Zentrale_VCCU_Btn3 trig_RemoteHM_Leeloo_light: Short_43
So muss demnach Dein notify aussehen:
define n_RemoteHM_Leeloo_light_short notify Zentrale_VCCU_Btn3:trig_RemoteHM_Leeloo_light:.Short.* set Licht__EG_Eingang toggle
Dieser hier geht -> RemoteHM_Leeloo_light:Short.* Weil Du einfach auf jeden Short.* im Device RemoteHM_Leeloo_light triggerst. Der wird also zweimal gefeuert ->
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo_light Short (to Zentrale_VCCU)
2017-01-06 18:41:47 CUL_HM RemoteHM_Leeloo_light trigger: Short_43
Alles klar?
Gruß Otto
Ja, jetzt passt es. :)
Danke für die Hilfe !!!
Gruß
Leeloo (Lehrling: Forstwirtschaft ;D)