Meine Konfiguration ist wie folgt:
- fhem 5.7 (update vorhin erst gemacht)
HMLAN (HM-CFG-LAN) (Firmware 0.964)
3x HM-SD-SEC-2 (Firmware 1.0)
Bis dato habe ich kein AES benutzt, obwohl ich relativ viele Schalter, Rollo-Aktoren etc. von HM habe.
Ich bin langsam am Verzweifeln - ich kriege die Rauchmelder nicht eingebunden. :(
Im Großen und Ganzen habe ich drei Versuche hinter mir:
Versuch 1:Rauchmelder NICHT untereinander gepaired
Rauchmelder mit FHEM gepaired --> alles ok (getconfig geht)
Virtuelles Team aufgesetzt, mit den Rauchmeldern gepeert --> augenscheinlich alles ok, aber teamCall etc. funktioniert nicht
=>Alles zurückgesetzt und alle Geräte aus FHEM entfernt
Versuch 2:Rauchmelder untereinander erfolgreich gepaired --> alles ok ("Kommunikationstest" funktioniert)
Rauchmelder mit FHEM gepaired --> alles ok (getconfig geht)
Virtuelles Team aufgesetzt, versucht, mit den Rauchmeldern zu peeren --> Geht nicht, nach dem Absetzen des peerchan Kommandos liefern die Melder state=nack ... Nach diversen stateRequests bekomme ich "CMDs_done", aber peering hat nicht funktioniert (Melder haben nur sich selbst unter peerIDs eingetragen)
Dann habe ich irgendwann einen eigenen AES Key in der VCCU gesetzt (Platz 1, es wird 1:<mein key> angezeigt), in den Meldern assignHmKey gemacht --> wurde akzeptiert, aber Peering konnte ich immer noch nicht machen.
=>Alles zurückgesetzt und alle Geräte aus FHEM entfernt
Versuch 3: Rauchmelder NICHT untereinander gepaired
Rauchmelder mit FHEM gepaired --> alles ok (getconfig geht)
AssignHmKey auf den Meldern gemacht --> bekomme nun nur noch state = RESPONSE TIMEOUT:RegisterRead
list <sd2> liefert derzeit folgende Ausgabe
Save config ?
Übersicht
Allgemein
OG
EG
Garten
Garage
Technik
Rollos
CUL_HM
Info
Plots
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
restart
update
updatecheck
reloadMyUtils
Internals:
CFGFN
DEF 47319F
HMLAN1_MSGCNT 11
HMLAN1_RAWMSG R451C86F3,0001,A0FCEEE6,FF,FFBE,05A01047319F93AFB50100000000
HMLAN1_RSSI -66
HMLAN1_TIME 2016-11-08 19:04:07
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 11
NAME HM_47319F
NOTIFYDEV global
NR 357
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:05 - t:10 s:47319F d:93AFB5 0100000000
protCmdDel 23
protLastRcv 2016-11-08 19:04:07
protResnd 7 last_at:2016-11-08 20:12:35
protResndFail 7 last_at:2016-11-08 20:12:40
protSnd 13 last_at:2016-11-08 20:12:29
protState CMDs_done_Errors:1
rssi_HMLAN1 avg:-60 min:-60 max:-60 lst:-60 cnt:1
rssi_at_HMLAN1 avg:-67.45 min:-70 max:-66 lst:-66 cnt:11
Readings:
2016-11-08 19:04:01 Activity alive
2016-11-08 19:03:56 D-firmware 1.0
2016-11-08 19:03:56 D-serialNr NEQ0247991
2016-11-08 19:04:06 PairedTo 0x000000
2016-11-08 19:04:06 R-pairCentral 0x000000
2016-11-08 19:04:02 alarmTest ok
2016-11-08 19:04:02 battery ok
2016-11-08 19:04:02 level 0
2016-11-08 19:04:02 recentStateType info
2016-11-08 19:04:06 sdRepeat off
2016-11-08 19:04:02 smokeChamber ok
2016-11-08 20:12:40 state RESPONSE TIMEOUT:RegisterRead
Regl_00.:
VAL
Helper:
HM_CMDNR 12
cSnd 0193AFB547319F00040000000000,0193AFB547319F00040000000000
getCfgListNo
mId 00AA
peerIDsRaw ,00000000
rxType 6
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +47319F,00,01,00
nextSend 1478628247.42712
prefIO
rxt 0
vccu
p:
47319F
00
01
00
Mrssi:
mNo 05
Io:
HMLAN1 -64
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1478628247.34578
ack:
HASH(0x3172640)
05800293AFB547319F00
Rssi:
Hmlan1:
avg -60
cnt 1
lst -60
max -60
min -60
At_hmlan1:
avg -67.4545454545455
cnt 11
lst -66
max -66
min -70
Shadowreg:
Tmpl:
Attributes:
IODev HMLAN1
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,
room CUL_HM
serialNr NEQ0247991
subType smokeDetector
webCmd statusRequest
Was mache ich falsch? Kann mir jemand Tipps zur Diagnose geben?
Hi dama,
also sd2 ist aktuell nicht gepairt
Zitat2016-11-08 19:04:06 PairedTo 0x000000
2016-11-08 19:04:06 R-pairCentral 0x000000
Im Wiki steht eigentlich alles, genauso musst Du es machen. Vorher aber noch mal alle SD auf Werksreset machen.
Wenn Du bisher AES nicht benutzt hast warum setzt Du es dann, bzw versuchst es?
Alle xx-SEC-xx Geräte machen von sich aus AES.
BTW: Für HMLAN gibt es 0.965
Du musst aber auch mal schauen ob mit dem SD-2 schon alles geht (https://forum.fhem.de/index.php/topic,35298.0.html), sollte aber. Ich habe noch SD - die Alten.
Im Prinzip läuft es so:
- alle Geräte pairen mit FHEM
- Virtuellen Teamlead definieren
- alle Geräte mit dem Teamlead peeren
Nicht untereinander peeren!!!
Gruß Otto
Hallo Otto,
danke dir für die prompte Antwort.
Warum ich den AES Key gesetzt habe? Ich habe manche Beiträge in dem mega-langen Thread zum SD2 so verstanden, dass die Dinger nur mit gesetztem Key funktionieren... War wohl eine Fehlinterpretation...
Auf die neueste Version des HMLAN werde ich morgen mal updaten
Was ich überhaupt nicht verstehe: mein erster Versuch entsprach ja genau dem von Dir geschilderten Vorgehen. Alles schien gut, nur ging der teamCall nicht damit.
Naja, da gibt es so viele Fehlerursachen! zum Lesen: https://forum.fhem.de/index.php/topic,58599.0.html.
Also ich denke, nochmal von vorn! alle SD resetten, alle SD Geräte aus FHEM entfernen.
Dann einen SD pairen und kontrollieren! am Besten mit hmInfo prüfen!
Hast Du hmInfo schon definiert?
Gruß Otto
Ich habe drei von den neuen SD-2 und meine machen definitiv AES. Wenn du HM Geräte, welche ein "SEC" im Namen tragen mit irgendwas peeren willst, dann brauchst du AES. Pairen geht natürlich auch so, aber dann solltest du schon AES aktivieren, schon allein, damit nicht mal jemand aus der Ferne die Sirenen auslösen kann - die sind höllisch laut, da will man keinen Fehlalarm.
Wenn ich mich recht entsinne, dann habe ich meine genau nach dem Wiki konfiguriert...
Gruß,
Stephan
Hi Stephan,
aber er hat doch einen HMLAN, der macht AES selbst. Da muss man nichts aktivieren, das passiert doch von ganz alleine.
Natürlich nur mit dem systemeigenen AES Key.
Gruß Otto
Moin Otto,
ja, wieso? Ich hatte das bis vor einer Woche auch alles noch nur mit einem HMLAN gemacht. Aber das erste, was man da tut ist ja den AES-Key zu ersetzen, wie bei allen "SEC" Devices von HM. Selbst wenn man eine CCU von HM einsetzt, sollte man das ja machen.
Pairen lassen sich die Teile ja auch so, aber peeren geht dann doch nur, wenn AES korrekt eingerichtet ist. Wann immer ich ein SEC-Device in Betrieb nehme, paire ich das als erstes, dann benenne ich das meistens um und dann kommt gleich als nächstes AES dran.
Wie auch immer... ich bin mir sicher, dass ich erst sichergestellt hatte, das AES funktioniert und dann die SD-2 nach Wiki eingerichtet hatte. Es muss halt bei AES nur immer alles zusammen passen, dann läuft das ja auch.
Gruß,
Stephan
Hallo Stephan,
ja da hast Du sicher Recht. Aber AES an sich muss man nicht aktivieren, das machen die SEC Geräte von sich aus. Und beim HMLAN ist das auch schmerzfrei.
Ganz blöd ist es nämlich bei allen anderen IOs. Die brauchen libcrypt-rijndael-perl. Ansonsten ist es so wie Du sagst: pairen geht noch, so leidlich, offenbar produzieren die dann untereinander irgendeine AES freie Ersatzkommunikation. Aber spätestens beim getConfig (ist jetzt mein Eindruck, ich bin mir nicht sicher!) hat es gehupt.
Und das obwohl man AES ja gar nicht "gemacht" hat. Und wenn dann ein HM Neuling anfängt AES zu "machen" ohne wirklich zu wissen was er tut, dann kann das eigentlich auch nur schiefgehen.
Ich muss dahingehend mal noch die Wiki Einträge anschauen, libcrypt-rijndael-perl ist nicht optional sondern Basic!
Gruß Otto
https://forum.fhem.de/index.php/topic,35298.msg460380.html#msg460380
Da steht wies geht.
Und libcrypt-rijndael brauchen die SD2 auf jeden fall auch wenn man einen HMLAN als IO nutzt ansonsten geht der TeamCall nicht.
Falls es an dem fehlenden Perl Modul liegt, sollte allerdings auch eine Fehlermeldung im LOG stehen.
Gruß
Ingo
Zitat von: automatisierer am 09 November 2016, 09:33:38
https://forum.fhem.de/index.php/topic,35298.msg460380.html#msg460380
Da steht wies geht.
Und libcrypt-rijndael brauchen die SD2 auf jeden fall auch wenn man einen HMLAN als IO nutzt ansonsten geht der TeamCall nicht.
Falls es an dem fehlenden Perl Modul liegt, sollte allerdings auch eine Fehlermeldung im LOG stehen.
Gruß
Ingo
Anders steht es im Wiki aber auch nicht. Ich wusste irgendwie bloß noch nicht, ob die SD-2 mittlerweile in FHEM voll umfänglich angekommen sind. Sind sie aber offenbar 8)
Meine SD können den Teamcall mit HMLAN ohne libcrypt-rijndael-perl, ich wüßte nicht wozu der HMLAN diesen braucht. Und ich denke nicht, dass es beim SD2 anders sein sollte.
Und nein, das fehlende Modul wird nicht bemerkt oder geloggt. Also zumindest hab ich bei mir noch nichts festgestellt. Es gibt zwar im HMUARTLGW Modul einen Eintrag für Logging wenn rijndael fehlt, aber bei mir ist das aktuell noch nicht angesprungen.
Insofern meine Meinung: libcrypt-rijndael-perl ist Pflicht wenn man HMUART einsetzt (HMLGW oder RPI Modul) oder einen CUL. Denn spätestens beim ersten SEC Gerät hat man vergessen, dass man es hätte installieren müssen.
Gruß Otto
Die SD2 benötigen zwingend libcrypt-rijndael-perl. Wenn man diese betreibt und das Modul fehlt, dann gibts auch einen LOG Eintrag. Das ist allerdings - wenn ich mich recht erinnere - nur für den TeamCall wichtig. Der alte SD braucht das nicht.
Zitat von: automatisierer am 09 November 2016, 10:05:25
Die SD2 benötigen zwingend libcrypt-rijndael-perl. Wenn man diese betreibt und das Modul fehlt, dann gibts auch einen LOG Eintrag. Das ist allerdings - wenn ich mich recht erinnere - nur für den TeamCall wichtig. Der alte SD braucht das nicht.
Aha, habe es gelesen AES-CBC ist das Stichwort.
Geht also nicht um AES an sich, also lag ich mit meiner Behauptung für den HMLAN nicht verkehrt :D
Aber auch ein HMLAN kann eben nicht alles, zumal der Arme zu Lebzeiten nie eine Firmware mit einer 1 am Anfang gesehen hat.
Naja was soll es, ich wäre der Meinung. Am Thema HM sollte ganz oben stehen, dass dieses Modul Grundvoraussetzung ist.
Wieder was gelernt 8) CBC steht übrigens für Cipher-Block-Chaning Mode (https://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode) falls mal einer fragt.
Schönen sonnigen Tag
Otto
Servus!
Ich bin es wieder ;)
Den HMLAN habe ich auf die von Otto erwähnte neueste Firmware Version aktualisiert.
Diesmal Test mit nur einem RM: Habe diesen resetted (Taste drücken für 10s+) -> ok (RM startet dann irgendwann neu und schaltet die LED durch alle drei Farben)
Alle Geräte aus FHEM gelöscht, Save Config und restart gemacht. Davor noch global verbose 5 gesetzt
Nun paire ich den RM aus dem HMLAN mittels hmPairSerial
Der Melder quittiert den Vorgang nach ca. 5s mit einer grünen LED kurz -> so sollte es sein.
Die Pairing (und anschließendes getConfig) Sequenz aus dem Logfile (habe versucht etwas zu bereinigen, damit es leichter zu lesen ist) schaut so aus:
(Der RM heißt HM_47319F )
2016.11.09 20:06:02 5: HMLAN/RAW: /HHM-LAN-IF,03C5,JEQ0707093,1E9EB8,93AFB5,0007FD43,0011,0A
2016.11.09 20:06:02 5: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0707093 d:1E9EB8 O:93AFB5 t:0007FD43 IDcnt:0011 L:10 %
2016.11.09 20:06:02 5: Triggering HMLAN1 (1 changes)
2016.11.09 20:06:02 5: Starting notify loop for HMLAN1, first event loadLvl: low
2016.11.09 20:06:04 5: HMLAN/RAW: /E47319F,0000,000802F4,FF,FFB9,81840047319F0000001000AA4E455130323437393931CE000100
2016.11.09 20:06:04 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:000802F4 d:FF r:FFB9 m:81 8400 47319F 000000 1000AA4E455130323437393931CE000100
2016.11.09 20:06:04 5: HMLAN1 dispatch A1A81840047319F0000001000AA4E455130323437393931CE000100::-71:HMLAN1
2016.11.09 20:06:04 2: CUL_HM Unknown device HM_47319F is now defined
2016.11.09 20:06:04 5: Triggering global (1 changes)
2016.11.09 20:06:04 5: Starting notify loop for global, first event UNDEFINED HM_47319F CUL_HM 47319F
2016.11.09 20:06:04 2: autocreate: define HM_47319F CUL_HM 47319F
2016.11.09 20:06:04 5: Triggering global (2 changes)
2016.11.09 20:06:04 2: autocreate: define FileLog_HM_47319F FileLog ./log/HM_47319F-%Y.log HM_47319F
2016.11.09 20:06:04 5: Triggering global (3 changes)
2016.11.09 20:06:04 5: Triggering global (4 changes)
2016.11.09 20:06:04 3: Device HM_47319F added to ActionDetector with 099:00 time
2016.11.09 20:06:04 4: Device HM_47319F is alive
2016.11.09 20:06:04 5: Triggering ActionDetector (1 changes)
2016.11.09 20:06:04 5: Starting notify loop for ActionDetector, first event alive:5 dead:0 unkn:1 off:0
2016.11.09 20:06:04 5: Triggering HM_47319F (3 changes)
2016.11.09 20:06:04 5: Starting notify loop for HM_47319F, first event Activity: alive
2016.11.09 20:06:07 5: HMLAN/RAW: /E47319F,0000,00080EAC,FF,FFB5,81840047319F0000001000AA4E455130323437393931CE000100
2016.11.09 20:06:07 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:00080EAC d:FF r:FFB5 m:81 8400 47319F 000000 1000AA4E455130323437393931CE000100
2016.11.09 20:06:07 5: HMLAN1 dispatch A1A81840047319F0000001000AA4E455130323437393931CE000100::-75:HMLAN1
2016.11.09 20:06:07 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:06:08 4: WEB_192.168.1.148_18047 POST /fhem&detail=HMLAN1&dev.setHMLAN1=HMLAN1&cmd.setHMLAN1=set&arg.setHMLAN1=hmPairSerial&val.setHMLAN1=NEQ0247991; BUFLEN:0
2016.11.09 20:06:08 5: Cmd: >set HMLAN1 hmPairSerial NEQ0247991<
2016.11.09 20:06:08 5: HMLAN_Send: HMLAN1 S:+000000,00,00,00
2016.11.09 20:06:08 5: HMLAN_Send: HMLAN1 S:S4A7BAAA2 stat: 00 t:00000000 d:01 r:4A7BAAA2 m:01 8401 93AFB5 000000 010A4e455130323437393931
2016.11.09 20:06:08 4: WEB_192.168.1.148_18047 GET /fhem?detail=HMLAN1&fw_id=; BUFLEN:0
2016.11.09 20:06:08 4: Ignoring CUL_FHTTK_75cd2e
2016.11.09 20:06:08 4: Ignoring CUL_FHTTK_08c0c9
2016.11.09 20:06:08 4: Ignoring FHT_3b1c
2016.11.09 20:06:08 4: Ignoring FHT_0a10
2016.11.09 20:06:08 4: Ignoring FHT_4215
2016.11.09 20:06:08 4: name: /fhem?detail=HMLAN1&fw_id= / RL:4025 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:08 5: HMLAN/RAW: /R4A7BAAA2,0002,00000000,FF,7FFF,01840193AFB5000000010A4E455130323437393931
E47319F,0000,000812E7,FF,FFB6,01800047319F93AFB51000AA4E455130323437393931CE000100
2016.11.09 20:06:08 5: HMLAN_Parse: HMLAN1 R:R4A7BAAA2 stat:0002 t:00000000 d:FF r:7FFF m:01 8401 93AFB5 000000 010A4E455130323437393931
2016.11.09 20:06:08 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:000812E7 d:FF r:FFB6 m:01 8000 47319F 93AFB5 1000AA4E455130323437393931CE000100
2016.11.09 20:06:08 5: HMLAN1 dispatch A1A01800047319F93AFB51000AA4E455130323437393931CE000100::-74:HMLAN1
2016.11.09 20:06:08 4: Connection closed for WEB_192.168.1.148_18048: EOF
2016.11.09 20:06:08 4: WEB_192.168.1.148_18047 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
...
2016.11.09 20:06:08 4: WEB_192.168.1.148_18031 => 304 Not Modified
2016.11.09 20:06:08 5: HMLAN/RAW: /E47319F,0000,000813E1,FF,FFB6,01800047319F93AFB51000AA4E455130323437393931CE000100
2016.11.09 20:06:08 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:000813E1 d:FF r:FFB6 m:01 8000 47319F 93AFB5 1000AA4E455130323437393931CE000100
2016.11.09 20:06:08 5: HMLAN1 dispatch A1A01800047319F93AFB51000AA4E455130323437393931CE000100::-74:HMLAN1
2016.11.09 20:06:08 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:06:08 4: WEB_192.168.1.148_18031 GET /fhem/images/default/fhemicon_dark.png; BUFLEN:0
2016.11.09 20:06:08 4: WEB_192.168.1.148_18031 => 304 Not Modified
2016.11.09 20:06:08 4: WEB_192.168.1.148_18047 GET /fhem?cmd={AttrVal(%22HMLAN1%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:08 5: Cmd: >{AttrVal("HMLAN1","room","")}<
2016.11.09 20:06:08 4: name: /fhem?cmd={AttrVal(%22HMLAN1%22,%22room%22,%22%22)}&XHR=1 / RL:28 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:08 4: WEB_192.168.1.148_18026 GET /fhem?cmd={ReadingsVal(%22HMLAN1%22,%22close%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:08 5: Cmd: >{ReadingsVal("HMLAN1","close","")}<
2016.11.09 20:06:08 4: name: /fhem?cmd={ReadingsVal(%22HMLAN1%22,%22close%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:08 4: WEB_192.168.1.148_18026 GET /fhem?XHR=1&inform=type=status;filter=HMLAN1;since=1478718367;fmt=JSON&fw_id=334×tamp=1478718371262; BUFLEN:0
2016.11.09 20:06:08 5: HMLAN/RAW: /E47319F,0000,000814DB,FF,FFB6,01800047319F93AFB51000AA4E455130323437393931CE000100
2016.11.09 20:06:08 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:000814DB d:FF r:FFB6 m:01 8000 47319F 93AFB5 1000AA4E455130323437393931CE000100
2016.11.09 20:06:08 5: HMLAN1 dispatch A1A01800047319F93AFB51000AA4E455130323437393931CE000100::-74:HMLAN1
2016.11.09 20:06:08 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:06:09 3: Device HM_47319F added to ActionDetector with 099:00 time
2016.11.09 20:06:09 5: Triggering HM_47319F (1 changes)
2016.11.09 20:06:09 5: Starting notify loop for HM_47319F, first event Activity: alive
2016.11.09 20:06:09 4: Device HM_47319F is alive
2016.11.09 20:06:09 5: HMLAN_Send: HMLAN1 I:+47319F,00,01,00
2016.11.09 20:06:10 5: CUL_HM HM_47319F protEvent:CMDs_pending pending:1
2016.11.09 20:06:10 3: CUL_HM set HM_47319F statusRequest
2016.11.09 20:06:10 5: HMLAN_Send: HMLAN1 S:S4A7BB3B9 stat: 00 t:00000000 d:01 r:4A7BB3B9 m:02 B001 93AFB5 47319F 010E
2016.11.09 20:06:10 5: CUL_HM HM_47319F protEvent:CMDs_processing... pending:0
2016.11.09 20:06:10 5: HMLAN/RAW: /E47319F,0000,00081D54,FF,FFBE,02A61047319F93AFB5060100003B
2016.11.09 20:06:10 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:00081D54 d:FF r:FFBE m:02 A610 47319F 93AFB5 060100003B
2016.11.09 20:06:10 5: HMLAN1 dispatch A0E02A61047319F93AFB5060100003B::-66:HMLAN1
2016.11.09 20:06:11 5: HMLAN: Skip ACK
2016.11.09 20:06:11 5: CUL_HM HM_47319F protEvent:CMDs_done
2016.11.09 20:06:11 5: CUL_HM HM_47319F sent ACK:2
2016.11.09 20:06:11 5: Triggering HM_47319F (5 changes)
2016.11.09 20:06:11 5: Starting notify loop for HM_47319F, first event alarmTest: ok
2016.11.09 20:06:11 5: HMLAN/RAW: /R4A7BB3B9,0001,00081D59,FF,FFBE,02A61047319F93AFB5060100003B
2016.11.09 20:06:11 5: HMLAN_Parse: HMLAN1 R:R4A7BB3B9 stat:0001 t:00081D59 d:FF r:FFBE m:02 A610 47319F 93AFB5 060100003B
2016.11.09 20:06:11 5: HMLAN1 dispatch A0E02A61047319F93AFB5060100003B::-66:HMLAN1
2016.11.09 20:06:11 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:06:14 5: CUL_HM HM_47319F protEvent:CMDs_pending pending:1
2016.11.09 20:06:14 5: CUL_HM HM_47319F protEvent:CMDs_pending pending:2
2016.11.09 20:06:14 3: CUL_HM set HM_47319F getConfig
2016.11.09 20:06:14 5: HMLAN_Send: HMLAN1 S:S4A7BC374 stat: 00 t:00000000 d:01 r:4A7BC374 m:03 B001 93AFB5 47319F 00040000000000
2016.11.09 20:06:14 5: CUL_HM HM_47319F protEvent:CMDs_processing... pending:1
2016.11.09 20:06:14 5: HMLAN/RAW: /E47319F,0000,00082D18,FF,FFBC,03A01047319F93AFB50202000A000B000C0016001F000000
2016.11.09 20:06:14 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:00082D18 d:FF r:FFBC m:03 A010 47319F 93AFB5 0202000A000B000C0016001F000000
2016.11.09 20:06:14 5: HMLAN1 dispatch A1803A01047319F93AFB50202000A000B000C0016001F000000::-68:HMLAN1
2016.11.09 20:06:14 5: HMLAN: Skip ACK
2016.11.09 20:06:14 5: CUL_HM HM_47319F protEvent:CMDs_processing... pending:1
2016.11.09 20:06:14 5: CUL_HM HM_47319F sent ACK:2
2016.11.09 20:06:15 5: Triggering HM_47319F (2 changes)
2016.11.09 20:06:15 5: Starting notify loop for HM_47319F, first event R-pairCentral: 0x000000
2016.11.09 20:06:15 5: HMLAN/RAW: /R4A7BC374,0001,00082D1D,FF,FFBC,03A01047319F93AFB50202000A000B000C0016001F000000
2016.11.09 20:06:15 5: HMLAN_Parse: HMLAN1 R:R4A7BC374 stat:0001 t:00082D1D d:FF r:FFBC m:03 A010 47319F 93AFB5 0202000A000B000C0016001F000000
2016.11.09 20:06:15 5: HMLAN1 dispatch A1803A01047319F93AFB50202000A000B000C0016001F000000::-68:HMLAN1
2016.11.09 20:06:15 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:06:15 5: HMLAN_Send: HMLAN1 S:S4A7BC604 stat: 00 t:00000000 d:01 r:4A7BC604 m:04 A001 93AFB5 47319F 0103
2016.11.09 20:06:15 5: CUL_HM HM_47319F protEvent:CMDs_processing... pending:0
2016.11.09 20:06:15 4: <hidden>: HTTP response code 200
2016.11.09 20:06:15 5: HMLAN/RAW: /E47319F,0000,00082F1E,FF,FFBC,04A01047319F93AFB50100000000
2016.11.09 20:06:15 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:00082F1E d:FF r:FFBC m:04 A010 47319F 93AFB5 0100000000
2016.11.09 20:06:15 5: HMLAN1 dispatch A0E04A01047319F93AFB50100000000::-68:HMLAN1
2016.11.09 20:06:15 5: HMLAN: Skip ACK
2016.11.09 20:06:15 5: CUL_HM HM_47319F protEvent:CMDs_done
2016.11.09 20:06:15 5: CUL_HM HM_47319F sent ACK:2
2016.11.09 20:06:15 5: HMLAN/RAW: /R4A7BC604,0001,00082F23,FF,FFBC,04A01047319F93AFB50100000000
2016.11.09 20:06:15 5: HMLAN_Parse: HMLAN1 R:R4A7BC604 stat:0001 t:00082F23 d:FF r:FFBC m:04 A010 47319F 93AFB5 0100000000
2016.11.09 20:06:15 5: HMLAN1 dispatch A0E04A01047319F93AFB50100000000::-68:HMLAN1
2016.11.09 20:06:15 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:06:25 4: HMLAN_ack: timeout - clear queue
2016.11.09 20:06:26 4: WEB_192.168.1.148_18047 GET /fhem?room=CUL%5fHM; BUFLEN:0
2016.11.09 20:06:26 4: name: /fhem?room=CUL%5fHM / RL:1775 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:26 4: Connection closed for WEB_192.168.1.148_18026: EOF
2016.11.09 20:06:26 4: WEB_192.168.1.148_18047 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
...
2016.11.09 20:06:26 4: WEB_192.168.1.148_18047 GET /fhem?XHR=1&inform=type=status;filter=room=CUL%5fHM;since=1478718385;fmt=JSON&fw_id=334×tamp=1478718389132; BUFLEN:0
2016.11.09 20:06:27 5: HMLAN_Send: HMLAN1 I:K
2016.11.09 20:06:27 5: HMLAN/RAW: /HHM-LAN-IF,03C5,JEQ0707093,1E9EB8,93AFB5,00085EF4,0012,0C
2016.11.09 20:06:27 5: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0707093 d:1E9EB8 O:93AFB5 t:00085EF4 IDcnt:0012 L:12 %
2016.11.09 20:06:27 5: Triggering HMLAN1 (1 changes)
2016.11.09 20:06:27 5: Starting notify loop for HMLAN1, first event loadLvl: low
2016.11.09 20:06:28 4: WEB_192.168.1.148_18031 GET /fhem?detail=HM_47319F; BUFLEN:0
2016.11.09 20:06:29 4: name: /fhem?detail=HM_47319F / RL:5792 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:29 4: Connection closed for WEB_192.168.1.148_18047: EOF
2016.11.09 20:06:29 4: WEB_192.168.1.148_18031 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
...
2016.11.09 20:06:29 4: WEB_192.168.1.148_18062 => 304 Not Modified
2016.11.09 20:06:29 4: WEB_192.168.1.148_18060 GET /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:29 5: Cmd: >{AttrVal("HM_47319F","room","")}<
2016.11.09 20:06:29 4: name: /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:29 4: WEB_192.168.1.148_18031 GET /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:29 5: Cmd: >{ReadingsVal("HM_47319F","assignHmKey","")}<
2016.11.09 20:06:29 4: name: /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:29 4: WEB_192.168.1.148_18031 GET /fhem?XHR=1&inform=type=status;filter=HM_47319F;since=1478718387;fmt=JSON&fw_id=330×tamp=1478718391983; BUFLEN:0
2016.11.09 20:06:33 4: WEB_192.168.1.148_18060 GET /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22getConfig%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:33 5: Cmd: >{ReadingsVal("HM_47319F","getConfig","")}<
2016.11.09 20:06:34 4: name: /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22getConfig%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:36 4: WEB_192.168.1.148_18060 POST /fhem&detail=HM_47319F&dev.setHM_47319F=HM_47319F&cmd.setHM_47319F=set&arg.setHM_47319F=getConfig&val.setHM_47319F=; BUFLEN:0
2016.11.09 20:06:36 5: Cmd: >set HM_47319F getConfig<
2016.11.09 20:06:36 5: CUL_HM HM_47319F protEvent:CMDs_pending pending:1
2016.11.09 20:06:36 5: CUL_HM HM_47319F protEvent:CMDs_pending pending:2
2016.11.09 20:06:36 3: CUL_HM set HM_47319F getConfig
2016.11.09 20:06:36 5: HMLAN_Send: HMLAN1 S:S4A7C17FA stat: 00 t:00000000 d:01 r:4A7C17FA m:05 B001 93AFB5 47319F 00040000000000
2016.11.09 20:06:36 5: CUL_HM HM_47319F protEvent:CMDs_processing... pending:1
2016.11.09 20:06:36 4: WEB_192.168.1.148_18060 GET /fhem?detail=HM_47319F&fw_id=; BUFLEN:0
2016.11.09 20:06:36 4: name: /fhem?detail=HM_47319F&fw_id= / RL:5801 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:36 4: Connection closed for WEB_192.168.1.148_18031: EOF
2016.11.09 20:06:36 4: WEB_192.168.1.148_18060 GET /fhem/pgm2/jquery-ui.min.css; BUFLEN:0
...
2016.11.09 20:06:36 4: WEB_192.168.1.148_18060 GET /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:36 5: Cmd: >{AttrVal("HM_47319F","room","")}<
2016.11.09 20:06:36 4: name: /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:36 4: WEB_192.168.1.148_18064 GET /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:36 5: Cmd: >{ReadingsVal("HM_47319F","assignHmKey","")}<
2016.11.09 20:06:36 4: name: /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:36 4: WEB_192.168.1.148_18064 GET /fhem?XHR=1&inform=type=status;filter=HM_47319F;since=1478718395;fmt=JSON&fw_id=341×tamp=1478718399153; BUFLEN:0
2016.11.09 20:06:37 5: HMLAN/RAW: /R4A7C17FA,0008,00000000,FF,7FFF,05B00193AFB547319F00040000000000
2016.11.09 20:06:37 5: HMLAN_Parse: HMLAN1 R:R4A7C17FA stat:0008 t:00000000 d:FF r:7FFF m:05 B001 93AFB5 47319F 00040000000000
2016.11.09 20:06:37 5: HMLAN_Parse: HMLAN1 no ACK from 47319F
2016.11.09 20:06:40 4: CUL_HM_Resend: HM_47319F nr 2
2016.11.09 20:06:40 5: HMLAN_Send: HMLAN1 S:S4A7C2A6A stat: 00 t:00000000 d:01 r:4A7C2A6A m:05 B001 93AFB5 47319F 00040000000000
2016.11.09 20:06:40 5: HMLAN_Send: HMLAN1 I:K
2016.11.09 20:06:40 5: HMLAN/RAW: /HHM-LAN-IF,03C5,JEQ0707093,1E9EB8,93AFB5,00089213,0012,10
2016.11.09 20:06:40 5: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0707093 d:1E9EB8 O:93AFB5 t:00089213 IDcnt:0012 L:16 %
2016.11.09 20:06:40 5: Triggering HMLAN1 (1 changes)
2016.11.09 20:06:40 5: Starting notify loop for HMLAN1, first event loadLvl: low
2016.11.09 20:06:42 5: HMLAN/RAW: /R4A7C2A6A,0008,00000000,FF,7FFF,05B00193AFB547319F00040000000000
2016.11.09 20:06:42 5: HMLAN_Parse: HMLAN1 R:R4A7C2A6A stat:0008 t:00000000 d:FF r:7FFF m:05 B001 93AFB5 47319F 00040000000000
2016.11.09 20:06:42 5: HMLAN_Parse: HMLAN1 no ACK from 47319F
2016.11.09 20:06:46 5: Triggering HM_47319F (1 changes)
2016.11.09 20:06:46 5: Starting notify loop for HM_47319F, first event ResndFail
2016.11.09 20:06:46 5: CUL_HM HM_47319F protEvent:CMDs_done_Errors:1
2016.11.09 20:06:46 5: Triggering HM_47319F (1 changes)
2016.11.09 20:06:46 5: Starting notify loop for HM_47319F, first event RESPONSE TIMEOUT:RegisterRead
2016.11.09 20:06:49 4: WEB_192.168.1.148_18060 GET /fhem?detail=HM_47319F&fw_id=; BUFLEN:0
2016.11.09 20:06:50 4: name: /fhem?detail=HM_47319F&fw_id= / RL:5848 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:50 4: Connection closed for WEB_192.168.1.148_18064: EOF
...
2016.11.09 20:06:50 4: WEB_192.168.1.148_18060 GET /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:50 5: Cmd: >{AttrVal("HM_47319F","room","")}<
2016.11.09 20:06:50 4: name: /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:50 4: WEB_192.168.1.148_18062 GET /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:06:50 5: Cmd: >{ReadingsVal("HM_47319F","assignHmKey","")}<
2016.11.09 20:06:50 4: name: /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:06:50 4: WEB_192.168.1.148_18069 GET /fhem/icons/favicon; BUFLEN:0
2016.11.09 20:06:50 4: WEB_192.168.1.148_18062 GET /fhem?XHR=1&inform=type=status;filter=HM_47319F;since=1478718408;fmt=JSON&fw_id=341×tamp=1478718412950; BUFLEN:0
2016.11.09 20:06:50 4: HMLAN_ack: timeout - clear queue
2016.11.09 20:07:02 4: BlockingCall (WOL_Ping): created child (12308), uses telnetPort to connect back
2016.11.09 20:07:02 4: [WHS] executing: ping -c 1 -w 2 192.168.1.10
2016.11.09 20:07:04 4: [WHS] result executing ping: PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
--- 192.168.1.10 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1002ms
2016.11.09 20:07:04 4: Connection accepted from telnetPort_127.0.0.1_45986
2016.11.09 20:07:04 5: Cmd: >{BlockingStart('6')}<
2016.11.09 20:07:05 5: HMLAN_Send: HMLAN1 I:K
2016.11.09 20:07:05 5: HMLAN/RAW: /HHM-LAN-IF,03C5,JEQ0707093,1E9EB8,93AFB5,0008F3C2,0012,13
2016.11.09 20:07:05 5: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0707093 d:1E9EB8 O:93AFB5 t:0008F3C2 IDcnt:0012 L:19 %
2016.11.09 20:07:05 5: Triggering HMLAN1 (1 changes)
2016.11.09 20:07:05 5: Starting notify loop for HMLAN1, first event loadLvl: low
2016.11.09 20:07:16 4: WEB_192.168.1.148_18069 POST /fhem&detail=HM_47319F&dev.setHM_47319F=HM_47319F&cmd.setHM_47319F=set&arg.setHM_47319F=assignHmKey&val.setHM_47319F=; BUFLEN:0
2016.11.09 20:07:16 5: Cmd: >set HM_47319F assignHmKey<
2016.11.09 20:07:16 5: CUL_HM HM_47319F protEvent:CMDs_pending pending:1
2016.11.09 20:07:16 5: CUL_HM HM_47319F protEvent:CMDs_pending pending:2
2016.11.09 20:07:16 3: CUL_HM set HM_47319F assignHmKey
2016.11.09 20:07:16 5: HMLAN_Send: HMLAN1 S:S4A7CB642 stat: 00 t:00000000 d:01 r:4A7CB642 m:06 B004 93AFB5 47319F 0100
2016.11.09 20:07:16 5: CUL_HM HM_47319F protEvent:CMDs_processing... pending:1
2016.11.09 20:07:16 4: WEB_192.168.1.148_18069 GET /fhem?detail=HM_47319F&fw_id=; BUFLEN:0
2016.11.09 20:07:16 4: name: /fhem?detail=HM_47319F&fw_id= / RL:5868 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
...
2016.11.09 20:07:16 4: WEB_192.168.1.148_18069 => 304 Not Modified
2016.11.09 20:07:17 4: WEB_192.168.1.148_18060 GET /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:07:17 5: Cmd: >{AttrVal("HM_47319F","room","")}<
2016.11.09 20:07:17 4: name: /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:07:17 4: WEB_192.168.1.148_18071 GET /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:07:17 5: Cmd: >{ReadingsVal("HM_47319F","assignHmKey","")}<
2016.11.09 20:07:17 4: name: /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:07:17 4: WEB_192.168.1.148_18071 GET /fhem?XHR=1&inform=type=status;filter=HM_47319F;since=1478718435;fmt=JSON&fw_id=344×tamp=1478718439670; BUFLEN:0
2016.11.09 20:07:18 5: HMLAN/RAW: /R4A7CB642,0008,00000000,FF,7FFF,06B00493AFB547319F3494480EFCDC7712D1015FDA2A864475
2016.11.09 20:07:18 5: HMLAN_Parse: HMLAN1 R:R4A7CB642 stat:0008 t:00000000 d:FF r:7FFF m:06 B004 93AFB5 47319F 3494480EFCDC7712D1015FDA2A864475
2016.11.09 20:07:18 5: HMLAN_Parse: HMLAN1 no ACK from 47319F
2016.11.09 20:07:21 4: CUL_HM_Resend: HM_47319F nr 2
2016.11.09 20:07:21 5: HMLAN_Send: HMLAN1 S:S4A7CC7DB stat: 00 t:00000000 d:01 r:4A7CC7DB m:06 B004 93AFB5 47319F 0100
2016.11.09 20:07:22 5: HMLAN/RAW: /R4A7CC7DB,0008,00000000,FF,7FFF,06B00493AFB547319F3494480EFCDC7712D1015FDA2A864475
2016.11.09 20:07:22 5: HMLAN_Parse: HMLAN1 R:R4A7CC7DB stat:0008 t:00000000 d:FF r:7FFF m:06 B004 93AFB5 47319F 3494480EFCDC7712D1015FDA2A864475
2016.11.09 20:07:22 5: HMLAN_Parse: HMLAN1 no ACK from 47319F
2016.11.09 20:07:24 5: HMLAN/RAW: /E47319F,0000,00093C6C,FF,FFAE,85840047319F0000001000AA4E455130323437393931CE000100
2016.11.09 20:07:24 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:00093C6C d:FF r:FFAE m:85 8400 47319F 000000 1000AA4E455130323437393931CE000100
2016.11.09 20:07:24 5: HMLAN1 dispatch A1A85840047319F0000001000AA4E455130323437393931CE000100::-82:HMLAN1
2016.11.09 20:07:24 3: Device HM_47319F added to ActionDetector with 099:00 time
2016.11.09 20:07:24 4: Device HM_47319F is alive
2016.11.09 20:07:24 5: Triggering HM_47319F (3 changes)
2016.11.09 20:07:24 5: Starting notify loop for HM_47319F, first event Activity: alive
2016.11.09 20:07:25 5: Triggering HM_47319F (1 changes)
2016.11.09 20:07:25 5: Starting notify loop for HM_47319F, first event ResndFail
2016.11.09 20:07:25 5: CUL_HM HM_47319F protEvent:CMDs_done_Errors:1
2016.11.09 20:07:25 5: Triggering HM_47319F (1 changes)
2016.11.09 20:07:25 5: Starting notify loop for HM_47319F, first event MISSING ACK
2016.11.09 20:07:27 5: HMLAN/RAW: /E47319F,0000,00094822,FF,FFBC,85840047319F0000001000AA4E455130323437393931CE000100
2016.11.09 20:07:27 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:00094822 d:FF r:FFBC m:85 8400 47319F 000000 1000AA4E455130323437393931CE000100
2016.11.09 20:07:27 5: HMLAN1 dispatch A1A85840047319F0000001000AA4E455130323437393931CE000100::-68:HMLAN1
2016.11.09 20:07:27 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:07:30 5: HMLAN/RAW: /E47319F,0000,000953D9,FF,FFB9,85840047319F0000001000AA4E455130323437393931CE000100
2016.11.09 20:07:30 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:000953D9 d:FF r:FFB9 m:85 8400 47319F 000000 1000AA4E455130323437393931CE000100
2016.11.09 20:07:30 5: HMLAN1 dispatch A1A85840047319F0000001000AA4E455130323437393931CE000100::-71:HMLAN1
2016.11.09 20:07:30 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:07:30 5: HMLAN_Send: HMLAN1 I:K
2016.11.09 20:07:30 5: HMLAN/RAW: /HHM-LAN-IF,03C5,JEQ0707093,1E9EB8,93AFB5,00095571,0012,19
2016.11.09 20:07:30 5: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0707093 d:1E9EB8 O:93AFB5 t:00095571 IDcnt:0012 L:25 %
2016.11.09 20:07:30 5: Triggering HMLAN1 (1 changes)
2016.11.09 20:07:30 5: Starting notify loop for HMLAN1, first event loadLvl: low
2016.11.09 20:07:31 4: HMLAN_ack: timeout - clear queue
2016.11.09 20:07:33 5: HMLAN/RAW: /E47319F,0000,00095F90,FF,FFBB,85840047319F0000001000AA4E455130323437393931CE000100
2016.11.09 20:07:33 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:00095F90 d:FF r:FFBB m:85 8400 47319F 000000 1000AA4E455130323437393931CE000100
2016.11.09 20:07:33 5: HMLAN1 dispatch A1A85840047319F0000001000AA4E455130323437393931CE000100::-69:HMLAN1
2016.11.09 20:07:33 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:07:34 4: WEB_192.168.1.148_18060 GET /fhem?detail=HM_47319F&fw_id=; BUFLEN:0
2016.11.09 20:07:34 4: name: /fhem?detail=HM_47319F&fw_id= / RL:5848 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:07:34 4: Connection closed for WEB_192.168.1.148_18071: EOF
...
2016.11.09 20:07:35 4: WEB_192.168.1.148_18069 GET /fhem/images/default/fhemicon_dark.png; BUFLEN:0
2016.11.09 20:07:35 4: WEB_192.168.1.148_18069 => 304 Not Modified
2016.11.09 20:07:35 4: WEB_192.168.1.148_18060 GET /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:07:35 5: Cmd: >{AttrVal("HM_47319F","room","")}<
2016.11.09 20:07:35 4: name: /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:07:35 4: WEB_192.168.1.148_18075 GET /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:07:35 5: Cmd: >{ReadingsVal("HM_47319F","assignHmKey","")}<
2016.11.09 20:07:35 4: name: /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:07:35 4: WEB_192.168.1.148_18069 GET /fhem/icons/favicon; BUFLEN:0
2016.11.09 20:07:35 4: WEB_192.168.1.148_18075 GET /fhem?XHR=1&inform=type=status;filter=HM_47319F;since=1478718453;fmt=JSON&fw_id=341×tamp=1478718457690; BUFLEN:0
2016.11.09 20:07:36 5: HMLAN/RAW: /E47319F,0000,00096B47,FF,FFBB,85840047319F0000001000AA4E455130323437393931CE000100
2016.11.09 20:07:36 5: HMLAN_Parse: HMLAN1 R:E47319F stat:0000 t:00096B47 d:FF r:FFBB m:85 8400 47319F 000000 1000AA4E455130323437393931CE000100
2016.11.09 20:07:36 5: HMLAN1 dispatch A1A85840047319F0000001000AA4E455130323437393931CE000100::-69:HMLAN1
2016.11.09 20:07:36 4: CUL_HM HM_47319F dupe: dont process
2016.11.09 20:07:36 4: WEB_192.168.1.148_18069 GET /fhem?detail=HM_47319F&fw_id=; BUFLEN:0
2016.11.09 20:07:36 4: name: /fhem?detail=HM_47319F&fw_id= / RL:5851 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:07:37 4: WEB_192.168.1.148_18060 GET /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:07:37 5: Cmd: >{AttrVal("HM_47319F","room","")}<
2016.11.09 20:07:37 4: name: /fhem?cmd={AttrVal(%22HM_47319F%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.11.09 20:07:37 4: WEB_192.168.1.148_18069 GET /fhem?cmd={ReadingsVal(%22HM_47319F%22,%22assignHmKey%22,%22%22)}&XHR=1; BUFLEN:0
2016.11.09 20:07:37 5: Cmd: >{ReadingsVal("HM_47319F","assignHmKey","")}<
201
Nach dem getConfig im HM_47319F kein ACK mehr, wie gestern geschrieben.
Im VCCU steht mein AES Key an erster Stelle, also
hmKey 01:<der Key>
Also ich weiß echt nicht mehr weiter... :-[
In dem Thread, den du mir im posting #4 genannt hast, schreibt der Kollege (irgendwo auf Seite 3 des Threads), dass er doch die RM erst untereinander gepairt hat.
Gestern hatte ich das ja auch so, und sie ließen sich mit FHEM auch noch pairen, nur ging das peering mit dem virtuellen Lead nicht.
Jetzt habe ich das wiederholt (also erst untereinander gepairt), und ich kann sie anschließend nicht mal mehr mit FHEM pairen.
Hier der aktuelle List
Internals:
CFGFN
DEF 47319F
HMLAN1_MSGCNT 7
HMLAN1_RAWMSG R4ADDBB5E,0001,006A289F,FF,FFC6,02A61047319F93AFB50601000034
HMLAN1_RSSI -58
HMLAN1_TIME 2016-11-09 21:53:15
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 7
NAME HM_47319F
NOTIFYDEV global
NR 335
STATE unreachable
TYPE CUL_HM
protCmdDel 3
protResnd 1 last_at:2016-11-09 21:57:40
protResndFail 1 last_at:2016-11-09 21:57:45
protSnd 1 last_at:2016-11-09 21:57:35
protState CMDs_done_Errors:1
Readings:
2016-11-09 21:57:55 state unreachable
Helper:
HM_CMDNR 4
cSnd 0193AFB547319F00040000000000,0193AFB547319F010E
getCfgListNo
mId 00AA
rxType 6
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +47319F,00,01,00
nextSend 1478724795.50244
prefIO
rxt 0
vccu
p:
47319F
00
01
00
Mrssi:
mNo 02
Io:
HMLAN1 -56
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1478724795.57079
ack:
HASH(0x1dd5220)
02800293AFB547319F00
Tmpl:
Attributes:
IODev HMLAN1
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
room CUL_HM
serialNr NEQ0247991
subType smokeDetector
webCmd statusRequest
Muss man für die AES Kommunikation noch was machen außer den Key in der VCCU zu setzen?
Zitat von: dama am 09 November 2016, 22:05:58
Muss man für die AES Kommunikation noch was machen außer den Key in der VCCU zu setzen?
Ich hätte erstmal keinen AES Key gesetzt und den Systemeigenen gelassen....
Untereinander pairen kann man nicht, peeren geht. Aber das macht überhaupt keinen Sinn!!!
Man peert mit dem Teamlead! Und den macht man in FHEM aus guten Grund virtuell.
Wenn Du einen eigenen AES Key gesetzt hast, kannst Du kein Werksreset mehr machen!.
Pairen mit FHEM wäre der erste wichtige Schritt, solange dass nicht funktioniert braucht man nicht weiter machen!
Gruß Otto
@Otto: war ja nur eine Frage mit dem untereinander peeren. Steht so im Thread, auf den du hingewiesen hast - aber klar, dafür ist ja der virtuelle Lead in FHEM da.
Das mit dem AES-Key (auch wenn ich es nicht hätte tun sollen) kann meines Erachtens nicht falsch sein. Ich habe nicht mehrere durchprobiert, sondern einmalig einen selbst-generierten gesetzt. Das habe ich exakt nach der Anleitung aus dem wiki gemacht - und die Melder haben DAMIT auch schon mal funktioniert.
Ich drehe hier noch durch... weil ich jetzt langsam nichts mehr verstehe.
Der RM (ich teste mittlerweile nur noch mit einem) lässt sich - zumindest laut FHEM - nicht mehr pairen: der Melder selbst quittiert das Anlernen zwar mit grüner LED.
Aber wenn ich das betreffende Device in FHEM anschaue, dann sehe ich R-pairCentral/PairedTo=0x000000, also nicht gepaired. Das Log dazu im Post #12.
Ein paar Readings liefert er dann allerdings doch: smoke_detect, sdRepeat, peerList...
Ein getConfig führt er nicht aus, außer wenn ich ihn zuvor in den Anlernmodus versetze. Dann wird ein getConfig sofort umgesetzt und mit grüner LED quittiert. Ansonsten "RESPONSE TIMEOUT:RegisterRead" und "CMDs_done_Errors:1"
Und für mich völlig unerklärlich: ein teamCall aus FHEM auf dem Device selbst führt er jederzeit aus (grüne LED blinkt).
Kann das sein, dass FHEM sich die schon mal "gesehenen" Devices irgendwo merkt und sich deswegen so verhält? Ich habe die Devices jedes Mal gelöscht (delete im Web-Frontend im jew. Device), danach Save config und restart von FHEM durchgeführt. Im Log (s. oben) steht an diversen Stellen "dupe, dont process". Das kann ich nicht deuten in diesem Fall...
Eins der RM readings ist aesCBCCounter (steht auf 00009A). Das habe ich vorher nicht wahrgenommen. Was bedeutet das?
Grüße
dama
Hi dama,
durchdrehen macht keinen Sinn - Du kämpfst mit einem Rauchmelder ;D
Bei dem Log aus Post #12 blicke ich nicht durch.
Das mit der grünen LED klingt eigentlich zuversichtlich.
Was steht in der peerlist?
Pairing bedeutet nicht, dass FHEM sich irgendwas merkt. Dabei wird die hmId des IO im Gerät eingetragen. Das Gerät nimmt danach Befehle von dem IO an der diese hmId trägt.
Du hast AES eingerichtet, vorausgesetzt das hat mal funktioniert, hat das Gerät den hmkey und kann mit diesem Key signierte Nachrichten akzeptieren.
Ob der RM Daten übertragt ohne oder mit "Knopf" drücken kann ich nicht sagen. Ich weiß es nicht. Offenbar macht er es mit Knopf drücken, Du sagst ja dann geht getConfig.
getConfig ändert aber nicht die Readings bezüglich pairing?
Gruß Otto
Jetzt bin ich doch nicht durchgedreht, weil ich das Posting #237 ( https://forum.fhem.de/index.php/topic,35298.msg454390.html#msg454390 (https://forum.fhem.de/index.php/topic,35298.msg454390.html#msg454390) ) gefunden habe. :D
Ich habe penibelst aufgeräumt diesmal zwei Melder nach dieser Anleitung in FHEM reingebracht.
Pairing mit FHEM hat astrein geklappt und Peering mit dem virtuellen Teammelder auch.
Teamcall geht immer noch nicht... bzw. blinken die RMs nicht. Im state des devices sehe ich aber was von teamcall stehen...
List des Teammelders
Internals:
DEF 32132101
HMLAN1_MSGCNT 1
HMLAN1_RAWMSG E4731BF,0000,0567166E,FF,FFCC,8086104731BF00000006010000
HMLAN1_RSSI -52
HMLAN1_TIME 2016-11-10 21:07:48
LASTInputDev HMLAN1
MSGCNT 1
NAME Teammelder
NOTIFYDEV global
NR 320
STATE off
TESTNR 1
TYPE CUL_HM
chanNo 01
device TeamVirtuell
peerList HM_47319F,HM_4731BF,
sdTeam sdLead
Readings:
2016-11-10 21:17:03 aesCBCCounter 000007
2016-11-10 21:18:01 eventNo 01
2016-11-10 21:07:48 level 0
2016-11-10 21:13:04 peerList HM_47319F,HM_4731BF,
2016-11-10 21:18:01 smoke_detect none
2016-11-10 21:22:39 state off
2016-11-10 21:18:01 teamCall from TeamVirtuell:01
Helper:
count 1
fkt sdLead2
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
vrt 1
Tmpl:
Attributes:
model virtual_1
peerIDs 47319F01,4731BF01,
room Allgemein,CUL_HM,Technik
webCmd press short:press long
List der RMs
Internals:
CFGFN
DEF 47319F
HMLAN1_MSGCNT 45
HMLAN1_RAWMSG E47319F,0000,0574B092,FF,FFCD,80A61047319F93AFB506010000
HMLAN1_RSSI -51
HMLAN1_TIME 2016-11-10 21:22:39
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 45
NAME HM_47319F
NOTIFYDEV global
NR 335
STATE off
TYPE CUL_HM
lastMsg No:80 - t:10 s:47319F d:93AFB5 06010000
peerList Teammelder,
protEvt_AESCom-ok 4 last_at:2016-11-10 21:00:24
protLastRcv 2016-11-10 21:22:39
protResnd 2 last_at:2016-11-10 21:04:11
protSnd 33 last_at:2016-11-10 21:22:39
protState CMDs_done
rssi_HMLAN1 avg:-41.5 min:-46 max:-39 lst:-39 cnt:4
rssi_at_HMLAN1 avg:-46.55 min:-52 max:-42 lst:-51 cnt:36
Readings:
2016-11-10 21:04:12 PairedTo 0x93AFB5
2016-11-10 21:04:12 R-pairCentral 0x93AFB5
2016-11-10 21:04:12 RegL_00. 02:01 0A:93 0B:AF 0C:B5 16:00 1F:00 00:00
2016-11-10 21:22:39 alarmTest ok
2016-11-10 21:22:39 battery ok
2016-11-10 21:22:39 level 0
2016-11-10 21:04:12 peerList Teammelder,
2016-11-10 21:22:39 powerOn 2016-11-10 21:22:39
2016-11-10 21:22:39 recentStateType info
2016-11-10 21:04:12 sdRepeat off
2016-11-10 21:22:39 smokeChamber ok
2016-11-10 21:18:01 smoke_detect none
2016-11-10 21:22:39 state off
2016-11-10 21:18:01 teamCall from TeamVirtuell:01
Helper:
HM_CMDNR 128
cSnd 0193AFB547319F0103,0193AFB547319F010E
mId 00AA
peerIDsRaw ,32132101,00000000
rxType 6
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +47319F,00,01,00
nextSend 1478809359.64821
prefIO
rxt 0
vccu
p:
47319F
00
01
00
Mrssi:
mNo 80
Io:
HMLAN1 -49
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1478809359.5736
ack:
HASH(0x26395d0)
80800293AFB547319F00
Rssi:
Hmlan1:
avg -41.5
cnt 4
lst -39
max -39
min -46
At_hmlan1:
avg -46.5555555555556
cnt 36
lst -51
max -42
min -52
Shadowreg:
Tmpl:
Attributes:
IODev HMLAN1
IOgrp vccu:HMLAN1
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,32132101,
room CUL_HM
serialNr NEQ0247991
subType smokeDetector
webCmd statusRequest
Internals:
CFGFN
DEF 4731BF
HMLAN1_MSGCNT 46
HMLAN1_RAWMSG R4FE00F5B,0001,056CAB96,FF,FFCD,BBA6104731BF93AFB5060100002B
HMLAN1_RSSI -51
HMLAN1_TIME 2016-11-10 21:13:54
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 46
NAME HM_4731BF
NOTIFYDEV global
NR 375
STATE off
TYPE CUL_HM
lastMsg No:BB - t:10 s:4731BF d:93AFB5 060100002B
peerList Teammelder,
protEvt_AESCom-ok 1 last_at:2016-11-10 21:13:05
protLastRcv 2016-11-10 21:13:54
protSnd 9 last_at:2016-11-10 21:13:54
protState CMDs_done
rssi_HMLAN1 avg:-42 min:-43 max:-41 lst:-43 cnt:2
rssi_at_HMLAN1 avg:-48.66 min:-52 max:-45 lst:-51 cnt:9
Readings:
2016-11-10 21:13:05 CommandAccepted yes
2016-11-10 21:13:31 PairedTo 0x93AFB5
2016-11-10 21:13:31 R-pairCentral 0x93AFB5
2016-11-10 21:13:31 RegL_00. 02:01 0A:93 0B:AF 0C:B5 16:00 1F:00 00:00
2016-11-10 21:13:05 aesCommToDev ok
2016-11-10 21:13:05 aesKeyNbr 00
2016-11-10 21:13:54 alarmTest ok
2016-11-10 21:13:54 battery ok
2016-11-10 21:13:54 level 0
2016-11-10 21:13:32 peerList Teammelder,
2016-11-10 21:13:54 recentStateType info
2016-11-10 21:13:31 sdRepeat off
2016-11-10 21:13:54 smokeChamber ok
2016-11-10 21:18:01 smoke_detect none
2016-11-10 21:18:01 state off
2016-11-10 21:18:01 teamCall from TeamVirtuell:01
Helper:
HM_CMDNR 187
cSnd 0193AFB54731BF0103,0193AFB54731BF010E
mId 00AA
peerIDsRaw ,32132101,00000000
rxType 6
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +4731BF,00,01,00
nextSend 1478808834.16809
prefIO
rxt 0
vccu
p:
4731BF
00
01
00
Mrssi:
mNo BB
Io:
HMLAN1 -49
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1478808834.0831
ack:
HASH(0x26422c0)
BB800293AFB54731BF00
Rssi:
Hmlan1:
avg -42
cnt 2
lst -43
max -41
min -43
At_hmlan1:
avg -48.6666666666667
cnt 9
lst -51
max -45
min -52
Shadowreg:
Tmpl:
Attributes:
IODev HMLAN1
IOgrp vccu:HMLAN1
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,32132101,
room CUL_HM
serialNr NEQ0247885
subType smokeDetector
webCmd statusRequest
Wie macht man einen RM zum Repeater (M_I_B's Punkt 12)?
Das sieht jetzt gut aus!
Die RMs haben den Teamlead als peer und der Teamlead hat die RMs als peer, das ist richtig so!
Hast Du libcrypt-rijndael-perl installiert? Sonst geht wohl der Teamcall nicht.
Gruß Otto
Die pairings der SD2 scheinen noch nicht komplett zu sein. In den Readings fehlt bei dem ersten SD2 'aesKeyNbr' das zeigt welchen AES Key der SD2 benutzt. Wenn du in der VCCU den Key als '01' definiert hast, dann steht im Device 'aesKeyNbr 02' der Wert im Device ist immer der Wert in der VCCU mal 2, bei 'Key Nr2' also 'aesKeyNbr 04' - keine Ahnung warum - ist aber so. Wie gesagt, beim ersten fehlts noch und bei dem Zweiten steht 'aesKeyNbr 00' _ da stimmt also etwas noch nicht.
Grundsätzlich:
Man kann Devices nur mit einer Zentrale pairen und nicht untereinander. Also HM_SEC_SD2 mit FHEM oder einer CCU.
Man kann HM-Devices nur untereinander peeren. Genauer gesagt, die Kanäle der Devices (sofern es welche hat) kann man mit den Kanälen anderer Devices peeren.
Diese Begriffe bitte nicht verwechseln, das führt zu verwirrungen bei den Leser/Helfern.
Wenn du die SD2 pairst, dann Schritt für Schritt nach dieser Anleitung.
https://forum.fhem.de/index.php/topic,35298.msg460380.html#msg460380
Damit habe ich schon 30 St. gepairt und mit einem virt. Teamlead gepeert.
Mit Schritt für Schritt meine ich, dass du nicht alle Befehle stumpf eingibst, sondern nach jedem Schritt guckst ob das gewünschte Ergebnis da ist. Es kommt nicht immer alles was der Sender sendet beim Empfänger an...
Also nach dem Pairing gucken ob die entsprechenden Readings (pairedTo oder so ähnlich) da sind. Wenn nicht pairing wiederholen oder mal ein getConfig machen.
Dann assignHmKey und ein getConfig und das gegebenenfalls wiederholen, bis die Readings da sind und stimmen. Ansonsten brauchst du mit den nächsten Schritten nicht weiter zu machen.
Allgemeine Grundlagen sollte man natürlich auch beachten. Zum Beispiel den Abstand zum HMlan - nicht kleiner als 1m... Sonst gibts Funkprobleme.
Dann noch die Antwort auf:
ZitatHast Du libcrypt-rijndael-perl installiert? Sonst geht wohl der Teamcall nicht.
So sieht das Listing aus wenn der SD2 richtig mit FHEM gepairt und mit dem virtTeamLead gepeert ist:
Internals:
CHANGED
DEF 4C6C37
HMLANingo1_MSGCNT 5
HMLANingo1_RAWMSG E4C6C37,0000,00FEBCE1,FF,FFC5,85A6104C6C3735586706010000
HMLANingo1_RSSI -59
HMLANingo1_TIME 2016-11-10 23:44:18
HMLANingo3_MSGCNT 4
HMLANingo3_RAWMSG E4C6C37,0000,01004AF0,FF,FFC8,85A6104C6C3735586706010000
HMLANingo3_RSSI -56
HMLANingo3_TIME 2016-11-10 23:44:18
HMLGW_1_MSGCNT 4
HMLGW_1_RAWMSG 0501004385A6104C6C3735586706010000
HMLGW_1_RSSI -67
HMLGW_1_TIME 2016-11-10 23:44:18
IODev HMLGW_1
LASTInputDev HMLANingo3
MSGCNT 13
NAME Garage_SD2
NOTIFYDEV global
NR 1459
NTFY_ORDER 50-Garage_SD2
STATE off
TYPE CUL_HM
lastMsg No:85 - t:10 s:4C6C37 d:355867 06010000
peerList RM_TeamDev_Btn1,
protLastRcv 2016-11-10 23:44:18
protSnd 5 last_at:2016-11-10 23:44:18
protState CMDs_done
rssi_HMLANingo1 avg:-57 min:-57 max:-57 lst:-57 cnt:1
rssi_at_HMLANingo1 avg:-62.2 min:-63 max:-59 lst:-59 cnt:5
rssi_at_HMLANingo3 avg:-55.5 min:-56 max:-55 lst:-56 cnt:4
rssi_at_HMLGW_1 avg:-64.75 min:-67 max:-64 lst:-67 cnt:4
Readings:
2016-11-09 15:06:47 Activity alive
2016-06-23 16:14:33 CommandAccepted yes
2016-06-23 16:14:31 D-firmware 1.0
2016-06-23 16:14:31 D-serialNr NEQ0450074
2016-06-23 16:14:35 PairedTo 0x355867
2016-05-28 17:55:58 R-devRepeatCntMax 0
2016-06-23 16:14:35 R-pairCentral 0x355867
2016-06-23 16:14:33 aesCommToDev ok
2016-06-23 16:14:32 aesKeyNbr 04
2016-11-10 23:44:18 alarmTest ok
2016-11-10 23:44:18 battery ok
2016-11-10 23:44:18 level 0
2016-11-09 15:06:47 peerList RM_TeamDev_Btn1,
2016-05-29 11:07:36 powerOn 2016-05-29 11:07:36
2016-11-10 23:44:18 recentStateType info
2016-06-23 16:14:35 sdRepeat off
2016-11-10 23:44:18 smokeChamber ok
2016-11-11 07:51:25 smoke_detect none
2016-11-11 07:51:25 state off
2016-11-11 07:51:17 teamCall from RM_TeamDev:02
2016-05-28 18:34:50 trigLast RM_TeamDev_Btn1:0
2016-05-28 18:34:50 trig_RM_TeamDev_Btn1 0
Helper:
HM_CMDNR 133
cSnd ,013558674C6C37010E
mId 00AA
rxType 6
Ack:
Expert:
def 1
det 1
raw 0
tpl 0
Io:
newChn +4C6C37,00,02,00
nextSend 1478817858.6861
rxt 0
vccu vccu
p:
4C6C37
00
02
00
Mrssi:
mNo 85
Io:
HMLANingo1 -59
HMLANingo3 -56
HMLGW_1 -65
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLGW_1
flg A
ts 1478817858.59419
ack:
HASH(0x3a0de08)
8580023558674C6C3700
Rssi:
Hmlaningo1:
avg -57
cnt 1
lst -57
max -57
min -57
At_hmlaningo1:
avg -62.2
cnt 5
lst -59
max -59
min -63
At_hmlaningo3:
avg -55.5
cnt 4
lst -56
max -55
min -56
At_hmlgw_1:
avg -64.75
cnt 4
lst -67
max -64
min -67
Shadowreg:
Tmpl:
Attributes:
IODev HMLANingo1
IOgrp vccu
actCycle 099:00
actStatus alive
autoReadReg 5_readMissing
devStateIcon off:general_ok *:secur_alarm
event-on-change-reading .*
expert 1_allReg
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,19191901,
room __Geraete
serialNr NEQ0450074
subType smokeDetector
webCmd statusRequest Den Repeaterbetrieb benötigst du nur, wenn sich nicht alle SD2 untereinander direkt per Funk erreichen können.
Im Fall eines Alarms, sendet der Ausgelöste SD2 halt einen "teamCall" und der muss von dem SD2 aus bis zu allen anderen kommen. SD2 die das Signal nicht erreicht, machen halt keinen Alarm. Wenn du den TeamCall von dem VirtTeamLead aus auslöst, dann muss der HMlan halt alle SD2 erreichen können - das ist ja meisstens gegeben.
Gruß
Ingo
Hallo Ingo,
ich habe noch nicht verstanden (ich habe nur die SD und nicht die SD-2) wie Dein Listing die Sache mit der Installation/Funktion des libcrypt-rijndael-perl Paketes erklärt. Kannst Du das nochmal erklären?
Ich habe verstanden, dass aesCBC offenbar softwareseitig in CUL_HM geklärt ist.
Gruß Otto
libcrypt-rijndael-perl habe ich installiert.
Ausgehend von dem Zustand gestern abend habe ich nun set <RM> assignHmKey.
Das führt sofort zum MISSING_ACK
Ein anschließendes statusRequest löst das auf.
Wenn ich anschließend getConfig mache, kommt nicht so richtig viel rüber: nur peerList, RegL_00 und PairedTo...
aesKeyNbr verbleibt eisern bei 00
Ich habe den Key, wie schon geschrieben, nur in VCCU gesetzt, nicht aber im HMLAN. Das ist doch ausreichend oder?
Die RMs befinden sich ca. 4m weg vom HMLAN (ohne Hindernisse dazwischen)
Wir kommen langsam weiter :D
assignHmKey akzeptieren die Kollegen offensichtlich nur, wenn sie keinen peer haben.
Wie ich im vorigen Posting geschrieben habe, habe ich es mehrfach versucht mit assignHmKey, statusRequest und getConfig
Kaum habe ich den im RM noch gesetzten Teammelder ungepeert, siehe da, beim nächsten getConfig steht plötzlich aesKeyNbr auf 02 ...
Dann kam mir aber die 1% Regel ins Gehege... ::)
Es geht jetzt alles, auch der teamCall für alle... :D :D :D
Oh Mann, bin ich froh...
Für die Nachwelt, worauf es m.E. ankam:
- Falls man vorher schon rumprobiert hat, FHEM komplett bereinigen von den entsprechenden Devices (auch Log-Definitionen usw.), danach am besten restart und x-check ob wirklich alles weg ist
- Auch die RM reseten (Knopf für 10+s drücken)
- Immer zuerst mit FHEM pairen / im Falle von explizit gesetztem Schlüssel zusehen, dass die Kommunikation tatsächlich über den korrekten AES-Key signiert wird (d.h. aesKeyNbr <> 00)
- Erst wenn letzter Punkt sauber funktioniert, dann kann man mit dem virtuellen Lead teamen
Mein Problem war zuletzt ganz klar (leider erst hinterher ;)), dass die RMs den AES Key nicht akzeptieren wollten, weil sie den virtuellen Teamleader bereits in peerIDs gesetzt hatten.
"Again what learnt" würde ich sagen...
Danke allen für eure Geduld und Mühe.
Nachdem ich jetzt den dritten Melder im Bunde eingebunden habe, muss ich meine Beobachtungen noch etwas ergänzen:
- Der SD2 (ich schätze, nur wenn eigene AES-Key gesetzt ist) akzeptiert am Anfang kurz nach dem Pairen nur Kommandos, wenn er in Pairing-Mode versetzt wird (orange LED blinkt). Das gilt insbesondere für getConfig. Ein Kommando wird dann mit einer grünen LED quitiert
- assignHmKey akzeptierten meine SD2 dann trotzdem erstmal nicht. Obwohl kein Peer im SD2 gesetzt war. Erst mit dem Kommando unten (SD2 im Pairing-Mode!) wurde assignHmKey umgehend verarbeitet. Verstehen tue ich es nicht, aber es ist 100% reproduzierbar
set <Team> peerChan 0 <sd2> single unset actor
Zitat von: Otto123 am 11 November 2016, 09:59:40
Hallo Ingo,
ich habe noch nicht verstanden (ich habe nur die SD und nicht die SD-2) wie Dein Listing die Sache mit der Installation/Funktion des libcrypt-rijndael-perl Paketes erklärt. Kannst Du das nochmal erklären?
Ich habe verstanden, dass aesCBC offenbar softwareseitig in CUL_HM geklärt ist.
Gruß Otto
Mein Listing hatte nichts mit der Erklärung zu libcrypt-rijndael-perl zu tun... das sollte nur zeigen wie es aussieht wenn es funktioniert - also aesKeyNbr z.B.
Wie das libcrypt... genau arbeitet und was das mit dem TeamCall zu tun hat kann ich dir auch nicht sagen. Ich hab nur weitergeben was mgernoth in dem SD2 Thread geschrieben hat...
Zitat von: dama am 11 November 2016, 21:43:22
Nachdem ich jetzt den dritten Melder im Bunde eingebunden habe, muss ich meine Beobachtungen noch etwas ergänzen:
- Der SD2 (ich schätze, nur wenn eigene AES-Key gesetzt ist) akzeptiert am Anfang kurz nach dem Pairen nur Kommandos, wenn er in Pairing-Mode versetzt wird (orange LED blinkt). Das gilt insbesondere für getConfig. Ein Kommando wird dann mit einer grünen LED quitiert
- assignHmKey akzeptierten meine SD2 dann trotzdem erstmal nicht. Obwohl kein Peer im SD2 gesetzt war. Erst mit dem Kommando unten (SD2 im Pairing-Mode!) wurde assignHmKey umgehend verarbeitet. Verstehen tue ich es nicht, aber es ist 100% reproduzierbar
set <Team> peerChan 0 <sd2> single unset actor
ich tippe eher, dass das pairing noch nicht komplett abgeschlossen war. Wie gesagt jeden Schritt durchführen und dann kontrollieren ob es geklappt hat. erst dann den nächsten... Das gilt aber nicht nur für SD2 sondern auch für andere HM Geräte.
es wäre gut wenn man all diese Erkenntnisse ins Wiki einträgt, oder?
Zitat von: ramses am 15 November 2016, 18:44:06
es wäre gut wenn man all diese Erkenntnisse ins Wiki einträgt, oder?
Die Sache mit dem libcrypt-rijndael-perl Modul habe ich eingefügt. Das scheint ja so zu sein. Das ermittelte Verhalten von dama mit der Anmerkung von automatisierer kann ich mangels SD-2 nicht verifizieren. Da muss ein anderer ran.
Gruß Otto
Zitat von: dama am 11 November 2016, 21:43:22
Nachdem ich jetzt den dritten Melder im Bunde eingebunden habe, muss ich meine Beobachtungen noch etwas ergänzen:
- Der SD2 (ich schätze, nur wenn eigene AES-Key gesetzt ist) akzeptiert am Anfang kurz nach dem Pairen nur Kommandos, wenn er in Pairing-Mode versetzt wird (orange LED blinkt). Das gilt insbesondere für getConfig. Ein Kommando wird dann mit einer grünen LED quitiert
- assignHmKey akzeptierten meine SD2 dann trotzdem erstmal nicht. Obwohl kein Peer im SD2 gesetzt war. Erst mit dem Kommando unten (SD2 im Pairing-Mode!) wurde assignHmKey umgehend verarbeitet. Verstehen tue ich es nicht, aber es ist 100% reproduzierbar
set <Team> peerChan 0 <sd2> single unset actor
Die beschriebene Vorgehensweise kann ich bestätigen. Es verhält sich mit den SD2 quasi wie mit anderen Komponenten wenn ein "hmkey" <> "default" im Einsatz ist (siehe dazu u.a. auch: https://forum.fhem.de/index.php/topic,55357.msg469966.html#msg469966 ).
Da es beim SD2 kein "sign" gibt, muss ein " ... single unset actor" gefolgt von einem "... single set actor" den gewünschten Key-Austausch an triggern. :?)