Hallo,
Fhem sendet eine falsche '+'-Nachricht fuer Geraete mit aesCommReq:
- Es wird immer der Schluessel mit Index 1 angegeben
- Es werden nur Signaturen fuer Nachrichten der Kanaele 1-4 angefordert (0x1E)
Der Aufbau der +-Nachricht ist anscheinend wie folgt:
+IDIDID,FL,KI,MASK
IDIDID: HMID des Geraets
FL: Flags (1 << 0 - AES, 1 << 1 - data pending)
KI: Schluesselindex fuer AES
MASK: Kanalmaske fuer die AES-Signaturen angefordert werden
Fhem hat hier bei KI hartkodiert 01 stehen, hier sollte wohl am besten der hoechste Index aus hmKey* genommen werden.
Bei MASK wird hartkodiert 0x1E gesendet, was zumindest bei einer RC-19B deutlich zu wenig ist ;-) Dieses Feld kann laenger als ein Byte werden, wenn ich das auf 0xFFFF aendere, dann funktionierts auch mit einer RC-19B auf Kanal 13.
Wenn ich den Homegear Quellcode (https://github.com/Homegear/Homegear/blob/master/Modules/HomeMaticBidCoS/PhysicalInterfaces/IBidCoSInterface.cpp#L47) richtig interpretiere, wird die Kanalmaske als Little-Endian gesendet, um also Kanaele 1 bis 15 zu aktivieren (0 nicht), sollte FEFF gesendet werden.
Viele Gruesse
Michael
`mask' verstehe ich nicht. ist das ein Bitfeld? Kann man also 16 Kanäle kodieren und jeden einzeln einschalten?
schaltet man dann einfach FFFF ein alle Kanäle werden AES "behandelt"? Eigentlich sollte man es sogar mehr also 16 Bit erlauben. Sicher sind 32 Channels erlaubt.
Hallo Martin,
Zitat von: martinp876 am 02 Juli 2015, 21:06:07
`mask' verstehe ich nicht. ist das ein Bitfeld? Kann man also 16 Kanäle kodieren und jeden einzeln einschalten?
schaltet man dann einfach FFFF ein alle Kanäle werden AES "behandelt"? Eigentlich sollte man es sogar mehr also 16 Bit erlauben. Sicher sind 32 Channels erlaubt.
Ja, Mask ist ein Bitfeld in "verdrehter" Byteordnung (Little-Endian). Das Ding hat eine dynamische Länge, kann also 1 Byte oder mehr sein. Ich denke "FEFFFFFF" (11111111111111111111111111111110) wäre ein sinnvoller Default. Anscheinend erwartet eQ-3 fuer den Geraetekanal 0 nie eine Signatur, das muss ich aber an einer CCU2 mal pruefen.
Die dynamische Länge des Felds hat auch dazu geführt, dass ich es falsch an den HMCFGUSB uebertragen habe, da der da noch ein Laengenbyte erwartete, das habe ich dann durch Deine Kommentare in 10_CUL_HM erraten :-)
Wäre es sinnvoll, aesCommReq per Kanal setzbar zu machen? IIRC kann man das bei der CCU so tun. Muss meiner mal wieder Strom geben und schauen...
Gruß
Michael
Nur um das hier noch zu dokumentieren:
Ich hab mal an einer CCU2 mitgesniffed (hmland als HM-LAN-CFG angemeldet) und nacheinander aufsteigend alle Kanaele eines HM-MOD-Re-8 auf gesichert gestellt:
2015-07-02 22:41:54.608588: LAN > +353A6B,01,00,02
2015-07-02 22:42:11.217867: LAN > +353A6B,01,00,06
2015-07-02 22:42:26.347738: LAN > +353A6B,01,00,0E
2015-07-02 22:42:37.813488: LAN > +353A6B,01,00,1E
2015-07-02 22:42:48.925378: LAN > +353A6B,01,00,3E
2015-07-02 22:43:00.896104: LAN > +353A6B,01,00,7E
2015-07-02 22:43:13.797575: LAN > +353A6B,01,00,FE
2015-07-02 22:43:24.424470: LAN > +353A6B,01,00,FE01
Ist also wirklich Little-Endian mit dynamischer Laenge. Kanal 0 scheint nicht aktiviert zu werden, obwohl das Geraet in der WebUI auch als "gesichert" angezeigt wird.
Gruss
Michael
interessantes thema. da fallen mir gleich ein paar fragen zu ein. :)
2015.07.03 14:28:54.324 0: HMLAN_Send: hmlan1 S:+1DE620,00,01,FE1F
wenn ich es richtig verstanden habe, soll die message bedeuten, dass nur channel 12 von 1DE620
gesichert ist. also nicht alle 12 channel.
der sec-sc hat aber nur 1 channel und gesichert ist dort eigentlich auch nichts. ein weiterer sec-sc und ein sec-rhs zeigen das gleiche verhalten. müsste also statt "FE1F" "00" heissen, wie sonst bei allen anderen devices, da ich keine sicherung benutze. hier noch ein list nach frischem getconfig.
Internals:
.triggerUsed 1
DEF 1DE620
IODev hmlan1
LASTInputDev hmlan1
MSGCNT 15
NAME Tuer.SZ
NR 305
NTFY_ORDER 50-Tuer.SZ
STATE Tuer:open (to ccu), Status:open, Sabotage:on, Bat:ok
TYPE CUL_HM
hmlan1_MSGCNT 9
hmlan1_RAWMSG R53F6F283,0001,00C3ABA1,FF,FFC8,84A0101DE6201ACE1F0201000000
hmlan1_RSSI -56
hmlan1_TIME 2015-07-03 14:49:29
hmusb1_MSGCNT 6
hmusb1_RAWMSG E1DE620,0000,000BE77C,FF,FFC5,84A0101DE6201ACE1F0201000000
hmusb1_RSSI -59
hmusb1_TIME 2015-07-03 14:49:29
lastMsg No:84 - t:10 s:1DE620 d:1ACE1F 0201000000
peerList SwitchPBU01_Sw_01,
protLastRcv 2015-07-03 14:49:29
protSnd 9 last_at:2015-07-03 14:49:29
protState CMDs_done
rssi_at_hmlan1 avg:-56.77 min:-63 max:-55 lst:-56 cnt:9
rssi_at_hmusb1 avg:-62 min:-67 max:-59 lst:-59 cnt:6
Readings:
2015-07-03 14:49:27 .D-devInfo 810101
2015-07-03 14:49:27 .D-stc 80
2015-07-03 14:49:29 .protLastRcv 2015-07-03 14:49:29
2015-07-03 14:49:27 Activity alive
2015-05-11 11:56:29 CommandAccepted yes
2015-07-03 14:49:27 D-firmware 2.0
2015-07-03 14:49:27 D-serialNr JEQ0644828
2015-07-03 14:49:27 PairedTo 0x1ACE1F
2015-05-11 11:56:44 R-SwitchPBU01_Sw_01-expectAES off
2015-05-11 11:56:44 R-SwitchPBU01_Sw_01-peerNeedsBurst off
2015-05-11 11:55:12 R-cyclicInfoMsg on
2015-05-11 11:55:12 R-eventDlyTime 2 s
2015-05-11 11:55:12 R-ledOnTime 0.5 s
2015-05-11 11:55:12 R-msgScPosA closed
2015-05-11 11:55:12 R-msgScPosB open
2015-05-11 11:55:12 R-pairCentral 0x1ACE1F
2015-05-11 11:55:12 R-sabotageMsg on
2015-05-11 11:55:12 R-sign off
2015-05-11 11:55:12 R-transmDevTryMax 6
2015-05-11 11:55:12 R-transmitTryMax 6
2015-07-03 14:49:27 RegL_00: 02:01 09:01 0A:1A 0B:CE 0C:1F 10:01 14:06 00:00
2015-07-03 14:49:28 RegL_01: 08:00 20:60 21:02 22:64 30:06 00:00
2015-07-03 14:49:29 RegL_04:SwitchPBU01_Sw_01 01:00 00:00
2015-07-03 14:23:31 alive yes
2015-07-03 14:23:31 battery ok
2015-07-03 14:23:31 contact open (to ccu)
2015-07-03 14:49:29 peerList SwitchPBU01_Sw_01,
2015-07-03 14:23:31 recentStateType info
2015-07-03 14:23:31 sabotageError on
2015-07-03 14:23:31 state open
2015-05-12 10:18:29 trigger_cnt 37
Helper:
HM_CMDNR 132
cSnd 011ACE1F1DE6200103,011ACE1F1DE6200104266EA50304
mId 002F
peerIDsRaw ,266EA503,00000000
rxType 4
Bm:
Cul_hm_get:
cnt 4
dmx 0
max 1
tot 4
mAr:
HASH(0x1482d98)
Tuer.SZ
?
Cul_hm_set:
cnt 5
dmx 0
max 7
tot 24
mAr:
HASH(0x1482d98)
Tuer.SZ
getConfig
Io:
newChn +1DE620,00,01,FE1F
nextSend 1435927769.92919
rxt 0
vccu ccu
p:
1DE620
00
01
FE1F
prefIO:
hmlan1
Mrssi:
mNo 84
Io:
hmlan1 -54
hmusb1 -59
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO hmlan1
flg A
ts 1435927769.81553
ack:
HASH(0x1482d98)
8480021ACE1F1DE62000
Rssi:
At_hmlan1:
avg -56.7777777777778
cnt 9
lst -56
max -55
min -63
At_hmusb1:
avg -62
cnt 6
lst -59
max -59
min -67
Shadowreg:
Attributes:
IODev hmusb1
IOgrp ccu:hmlan1
actCycle 028:00
actStatus alive
autoReadReg 0_off
comment Lueftung
event-on-change-reading .*
expert 2_full
firmware 2.0
group Alarmmelder
model HM-SEC-SC
peerIDs 00000000,266EA503,
room 01_ALARM,50_SZ
serialNr JEQ0644828
stateFormat Tuer:contact, Status:state, Sabotage:sabotageError, Bat:battery
subType threeStateSensor
edit: ich sehe gerade, dass die "+"-message auf dieses device sogar in mehreren varianten erfolgt.
2015.07.03 10:38:13.335 0: HMLAN_Send: hmlan1 I:+1DE620,00,00,
2015.07.03 11:15:56.555 0: HMLAN_Send: hmlan1 I:+1DE620,00,01,FE1F
2015.07.03 14:28:54.324 0: HMLAN_Send: hmlan1 S:+1DE620,00,01,FE1F
die variante, ohne MASK, scheint nach einem umassignen zu kommen.
2015.07.03 10:38:13.331 0: HMLAN_Send: hmusb1 I:-1DE620
2015.07.03 10:38:13.335 0: HMLAN_Send: hmlan1 I:+1DE620,00,00,
gruss frank
Hallo,
Zitat von: frank am 03 Juli 2015, 15:17:37
2015.07.03 14:28:54.324 0: HMLAN_Send: hmlan1 S:+1DE620,00,01,FE1F
wenn ich es richtig verstanden habe, soll die message bedeuten, dass nur channel 12 von 1DE620
gesichert ist. also nicht alle 12 channel.
Nein, wieso?
1FFE sichert Kanaele 1-12, siehe Bitmuster: 1111111111110
Zitat
der sec-sc hat aber nur 1 channel und gesichert ist dort eigentlich auch nichts. ein weiterer sec-sc und ein sec-rhs zeigen das gleiche verhalten. müsste also statt "FE1F" "00" heissen, wie sonst bei allen anderen devices, da ich keine sicherung benutze.
Fuer gesicherte Uebertragung muesste es 02 heissen (bzw. wurde das ausreichen), fuer ungesicherte Uebertragung tut es 00.
Fhem schickt hier im Augenblick hartkodierte Werte, da die Bedeutung des Felds nicht klar war.
Gruss
Michael
ZitatNein, wieso?
habe ich so (falsch) aus deinem ccu2-sniff geschlussfolgert, da du die kanäle nacheinander einzeln gesichert hast. demnach wird also immer die komplette config gesendet.
Zitat1FFE sichert Kanaele 1-12, siehe Bitmuster: 1111111111110
das bitmuster war mir schon klar. bis zum ccu2-sniff hätte ich auch gemeint das hiermit die ersten 12 kanäle gesichert werden, macht ja auch mehr sinn.
gruss frank
Zitat von: frank am 03 Juli 2015, 15:46:47
habe ich so (falsch) aus deinem ccu2-sniff geschlussfolgert, da du die kanäle nacheinander einzeln gesichert hast.
Ah.
Zitat
demnach wird also immer die komplette config gesendet.
Genau, ein + ueberschreibt immer die vorherige Config eines Geraets.
Gruss
Michael
das Prinzip ist somit klar. Dass man es in der ccu einzel einstellen kann auch.
Grund ist sicher die nicht unerhebliche längere Verzögerung. Man kann damit einzelne Kanäle schützen, andere aber "schnell" lassen.
aesCommReq kann man (jetzt) für Channels setzen
aesKey setzt den zu nutzenden Key dieses Devices - default =default :)
Hallo Martin,
Zitat von: martinp876 am 04 Juli 2015, 10:42:30
aesCommReq kann man (jetzt) für Channels setzen
aesKey setzt den zu nutzenden Key dieses Devices - default =default :)
Wow, danke :-)
Allerdings werden jetzt fuer Geraete bei denen keine eigenen Channels angelegt werden (z.B. TFK) keine Requests mehr gestellt, Patch dafuer im Anhang.
Und der Defaultkey ist 00, auch im Patch.
EDIT: Hmm, wenn ich drueber nachdenke waere es wohl am sinnvollsten, doch den hoechsten Keyindex zu nehmen, wenn aesKey nicht gesetzt wurde.
EDIT2: Ich habe mal eingebaut, dass der Schluessel aus der VCCU oder dem HMLAN geholt wird aber anscheinend wird die Funktion zu frueh aufgerufen und owner_VCCU ist noch nicht unbedingt gesetzt...
Danke & Gruss
Michael
all in
Zitat von: martinp876 am 05 Juli 2015, 07:05:48
all in
Danke :-)
Kann man den Aufruf von CUL_HM_hmInitMsg soweit hinauszoegern, bis dem IO eine evtl. existierende VCCU zugewiesen wurde? Einige meiner Geraete bekommen noch den Defaultkey 0 zugewiesen, da ich den Key nur in der VCCU definiert habe und der IO noch nicht das owner_VCCU-Attribut hat.
Ich nehme mal an, dass da im Augenblick die Reihenfolge der Definition ausschlaggebend ist?
EDIT: Hmm, passiert auch wenn ich den Schluessel direkt im IO definieren. Anscheinend fehlt da beim restart die IO-Zuordnung noch komplett, kann das sein? Wenn ich das Attribut zur Laufzeit setze, ist alles OK.
Danke & Gruss
Michael
Muss ich mir ansehen, laesst sich sicher loesen
Zitat von: martinp876 am 05 Juli 2015, 13:34:23
Muss ich mir ansehen, laesst sich sicher loesen
Danke :-)
Wenn man die Keys direkt im IO definiert, geht es, wenn man meinen Bug im CUL_HM_getKeys behebt, da er ohne zugewiesene CCU auch gar nicht im Geraet geschaut hat. Das mit der VCCU ist aber wohl wirklich ein Timingproblem.
Patch fuer meinen Bug habe ich angehaengt.
Gruss
Michael
done
Hallo Martin,
Zitat von: martinp876 am 05 Juli 2015, 20:16:59
done
Danke :-)
Es wird aber die falsche Funktion aufgerufen, die die schon gecachte init-Message nochmal schickt. Ich hab das mal geaendert und auch den Timer nach der Definition einer VCCU neugestartet.
Mit anhaengendem Diff gehts jetzt bei mir vollstaendig.
Viele Gruesse
Michael
meine fensterkontakte werden nun entsprechend "richtig" initializiert.
beim umassignen der io's besteht aber wohl weiterhin ein problem. hier wird nie MASK an das neue io übergeben. der parameter fehlt grundsätzlich.
2015.07.06 09:47:40.192 0: HMLAN_Send: hmusb1 I:+83765A,00,00,00
2015.07.06 09:47:41.300 0: HMLAN_Send: hmusb1 I:-83765A
2015.07.06 09:47:41.304 0: HMLAN_Send: hmlan1 I:+83765A,00,00,
darüber hinaus wundere ich mich, dass nach restart manchen devices erst ein "falsches" io assigned wird, um es augenblicke später dem gesetzten prefered-io zu assignen. das device 6869B6 wird sogar 2x umassigned. zuerst richtiges prefered-io hmusb1, dann hmlan1 und zurück zu hmusb1.
dazu mal ein ungekürztes log nach restart.
2015.07.06 15:06:46.219 1: Including fhem.cfg
2015.07.06 15:06:49.363 1: HMLAN_Parse: hmusb1 new condition disconnected
2015.07.06 15:06:49.448 1: HMLAN_Parse: hmusb1 new condition init
2015.07.06 15:06:49.481 1: HMLAN_Parse: hmlan1 new condition disconnected
2015.07.06 15:06:49.502 1: HMLAN_Parse: hmlan1 new condition init
2015.07.06 15:07:13.289 0: HourCounter Pumpe.Garten.Brunnen.Cnt Define.228 parameters: Pumpe.Garten.Brunnen.Cnt HourCounter SwitchES01_Pwr:current:\s[0-9]{4,}$ SwitchES01_Pwr:current:\s[0-9]{1,2}$
2015.07.06 15:07:13.761 0: HourCounter hc_system_attak Define.228 parameters: hc_system_attak HourCounter ccu:system_attack:.on ccu:system_attack:.off
2015.07.06 15:07:13.828 1: Including ./log/fhem.save
2015.07.06 15:07:22.332 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 3454.
2015.07.06 15:07:22.377 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 3454.
2015.07.06 15:07:22.421 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 3454.
2015.07.06 15:07:22.466 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 3454.
2015.07.06 15:07:22.507 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 3454.
2015.07.06 15:07:29.678 1: HCS BROETJE monitoring of devices started
2015.07.06 15:07:33.536 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/98_apptime.pm line 24.
2015.07.06 15:07:33.543 1: PERL WARNING: Subroutine CallFn redefined at ./FHEM/98_apptime.pm line 58.
2015.07.06 15:07:37.317 0: Server started with 318 defined entities (version $Id: fhem.pl 8574 2015-05-14 07:59:32Z rudolfkoenig $, os linux, user root, pid 3049)
2015.07.06 15:07:38.131 1: Perfmon: possible freeze starting at 15:06:47, delay is 51.13
2015.07.06 15:07:40.452 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:07:40.460 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:07:40.631 0: HourCounter hc_system_attak Run.598 first run done countsOverall:22
2015.07.06 15:07:40.771 0: HourCounter Pumpe.Garten.Brunnen.Cnt Run.598 first run done countsOverall:140
2015.07.06 15:07:41.252 0: HMLAN_Send: hmusb1 I:+266A86,00,00,00
2015.07.06 15:07:41.256 0: HMLAN_Send: hmusb1 I:+1F64D8,00,00,00
2015.07.06 15:07:41.259 0: HMLAN_Send: hmlan1 I:+1C1BE3,00,00,00
2015.07.06 15:07:41.263 0: HMLAN_Send: hmusb1 I:+52C4DF,00,00,00
2015.07.06 15:07:41.266 0: HMLAN_Send: hmusb1 I:+52BB90,00,00,00
2015.07.06 15:07:41.270 0: HMLAN_Send: hmusb1 I:+52BB9D,00,00,00
2015.07.06 15:07:41.273 0: HMLAN_Send: hmlan1 I:+24AF1D,00,00,00
2015.07.06 15:07:41.277 0: HMLAN_Send: hmusb1 I:+266EA5,00,00,00
2015.07.06 15:07:41.280 0: HMLAN_Send: hmusb1 I:+266E75,00,00,00
2015.07.06 15:07:41.283 0: HMLAN_Send: hmusb1 I:+285A54,00,00,00
2015.07.06 15:07:41.286 0: HMLAN_Send: hmlan1 I:+285A44,00,00,00
2015.07.06 15:07:41.290 0: HMLAN_Send: hmusb1 I:+206278,00,00,00
2015.07.06 15:07:41.293 0: HMLAN_Send: hmusb1 I:+1936FF,00,00,00
2015.07.06 15:07:41.296 0: HMLAN_Send: hmusb1 I:+206487,00,00,00
2015.07.06 15:07:41.299 0: HMLAN_Send: hmusb1 I:+2064CB,00,00,00
2015.07.06 15:07:41.303 0: HMLAN_Send: hmusb1 I:+206219,00,00,00
2015.07.06 15:07:41.325 0: HMLAN_Send: hmusb1 I:+1D252E,00,00,00
2015.07.06 15:07:41.331 0: HMLAN_Send: hmusb1 I:+20DFE1,00,00,00
2015.07.06 15:07:41.335 0: HMLAN_Send: hmusb1 I:+1DFDA5,00,00,00
2015.07.06 15:07:41.338 0: HMLAN_Send: hmusb1 I:+1BF81B,00,00,00
2015.07.06 15:07:41.341 0: HMLAN_Send: hmusb1 I:+1DE620,00,00,00
2015.07.06 15:07:41.344 0: HMLAN_Send: hmusb1 I:+1DF7C6,00,00,00
2015.07.06 15:07:41.347 0: HMLAN_Send: hmlan1 I:+1C4E25,00,00,00
2015.07.06 15:07:41.350 0: HMLAN_Send: hmlan1 I:+193A9A,00,00,00
2015.07.06 15:07:41.353 0: HMLAN_Send: hmlan1 I:+1BFC52,00,00,00
2015.07.06 15:07:41.357 0: HMLAN_Send: hmlan1 I:+1F91AA,00,00,00
2015.07.06 15:07:41.361 0: HMLAN_Send: hmlan1 I:+1DFC2F,00,00,00
2015.07.06 15:07:41.364 0: HMLAN_Send: hmlan1 I:+1CE9F5,00,00,00
2015.07.06 15:07:41.368 0: HMLAN_Send: hmusb1 I:+83765A,00,00,00
2015.07.06 15:07:41.371 0: HMLAN_Send: hmusb1 I:+6869B6,00,00,00
2015.07.06 15:07:41.396 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:0290F433 IDcnt:000E L:7 %
2015.07.06 15:07:41.575 0: HMLAN_Send: hmusb1 I:+20DFE1,02,00,00
2015.07.06 15:07:42.136 0: HMLAN_Send: hmusb1 I:+2064CB,02,00,00
2015.07.06 15:07:42.677 0: HMLAN_Send: hmusb1 I:+206219,02,00,00
2015.07.06 15:07:43.129 0: HMLAN_Send: hmusb1 I:+206278,02,00,00
2015.07.06 15:07:43.417 0: HMLAN_Send: hmusb1 I:+1DFDA5,02,00,00
2015.07.06 15:07:44.725 0: HMLAN_Send: hmusb1 I:+1D252E,02,00,00
2015.07.06 15:07:44.901 0: HMLAN_Send: hmusb1 I:+206487,02,00,00
2015.07.06 15:07:45.320 0: HMLAN_Send: hmusb1 I:+1936FF,02,00,00
2015.07.06 15:07:45.713 0: IT set IT03 off
2015.07.06 15:07:46.328 0: IT set IT08 off
2015.07.06 15:07:47.695 0: HMLAN_Send: hmusb1 I:+1BF81B,02,00,00
2015.07.06 15:07:49.714 1: HMLAN_Parse: hmlan1 new condition ok
2015.07.06 15:07:50.013 0: HMLAN_Send: hmusb1 I:-206487
2015.07.06 15:07:50.017 0: HMLAN_Send: hmlan1 I:+206487,00,00,
2015.07.06 15:07:50.282 0: HMLAN_Send: hmusb1 I:-1D252E
2015.07.06 15:07:50.450 0: HMLAN_Send: hmusb1 I:-1936FF
2015.07.06 15:07:50.497 0: HMLAN_Send: hmusb1 I:-6869B6
2015.07.06 15:07:50.500 0: HMLAN_Send: hmlan1 I:+6869B6,00,00,
2015.07.06 15:07:50.746 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:0291BB4E IDcnt:000E L:7 %
2015.07.06 15:07:50.754 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:014F3A07 IDcnt:0010 L:6 %
2015.07.06 15:07:51.408 1: HMLAN_Parse: hmusb1 new condition ok
2015.07.06 15:07:52.109 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:01500165 IDcnt:0015 L:6 %
2015.07.06 15:07:52.312 1: Perfmon: possible freeze starting at 15:07:39, delay is 13.311
2015.07.06 15:07:52.991 0: HMLAN_Send: hmlan1 I:-1936FF
2015.07.06 15:07:53.044 0: HMLAN_Send: hmlan1 I:-1D252E
2015.07.06 15:07:55.209 1: Perfmon: possible freeze starting at 15:07:53, delay is 2.208
2015.07.06 15:07:56.697 0: HMLAN_Send: hmusb1 I:-52C4DF
2015.07.06 15:07:56.708 0: HMLAN_Send: hmlan1 I:+52C4DF,00,00,
2015.07.06 15:07:58.155 0: HMLAN_Send: hmusb1 I:-52BB90
2015.07.06 15:07:58.167 0: HMLAN_Send: hmlan1 I:+52BB90,00,00,
2015.07.06 15:07:59.190 0: HMLAN_Send: hmlan1 I:+1BFC52,02,00,00
2015.07.06 15:07:59.365 0: HMLAN_Send: hmusb1 I:-52BB9D
2015.07.06 15:07:59.374 0: HMLAN_Send: hmlan1 I:+52BB9D,00,00,
2015.07.06 15:08:00.135 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:08:00.246 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:01504E84 IDcnt:000E L:7 %
2015.07.06 15:08:00.776 0: HMLAN_Send: hmusb1 I:+1936FF,00,00,
2015.07.06 15:08:01.303 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:08:01.331 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:02920CBD IDcnt:0010 L:13 %
2015.07.06 15:08:01.581 0: HMLAN_Send: hmlan1 I:-206487
2015.07.06 15:08:01.585 0: HMLAN_Send: hmusb1 I:+206487,00,00,
2015.07.06 15:08:01.725 0: HMLAN_Send: hmlan1 I:+1BFC52,00,00,00
2015.07.06 15:08:04.594 0: HMLAN_Send: hmusb1 I:+1D252E,00,00,
2015.07.06 15:08:07.600 0: HMLAN_Send: hmusb1 I:-266EA5
2015.07.06 15:08:08.781 0: HMLAN_Send: hmlan1 I:+266EA5,00,00,
2015.07.06 15:08:11.169 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:08:11.185 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:02923348 IDcnt:000F L:17 %
2015.07.06 15:08:17.639 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:08:17.666 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:02924CA4 IDcnt:000F L:19 %
2015.07.06 15:08:25.140 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:08:25.205 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0150B005 IDcnt:0010 L:8 %
2015.07.06 15:08:27.233 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:08:27.350 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0150B865 IDcnt:0010 L:8 %
2015.07.06 15:08:29.040 0: HMLAN_Send: hmusb1 I:+1BF81B,00,00,00
2015.07.06 15:08:42.644 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:08:42.655 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:0292AE42 IDcnt:000F L:20 %
2015.07.06 15:08:46.608 0: HMLAN_Send: hmusb1 I:+1DFDA5,00,00,00
2015.07.06 15:08:52.240 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:08:52.277 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:015119C4 IDcnt:0010 L:9 %
2015.07.06 15:08:59.954 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:09:00.053 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:01513824 IDcnt:0010 L:9 %
2015.07.06 15:09:01.930 0: HMLAN_Send: hmusb1 I:+20DFE1,00,00,00
2015.07.06 15:09:07.651 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:09:07.663 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:02930FF5 IDcnt:000F L:20 %
2015.07.06 15:09:18.125 0: HMLAN_Send: hmusb1 I:+206487,00,00,00
2015.07.06 15:09:24.544 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:09:24.661 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:01519843 IDcnt:0010 L:9 %
2015.07.06 15:09:27.053 0: HMLAN_Send: hmusb1 I:+206278,00,00,00
2015.07.06 15:09:29.354 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:09:29.524 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0151AB43 IDcnt:0010 L:10 %
2015.07.06 15:09:29.612 0: HMLAN_Send: hmusb1 I:+2064CB,00,00,00
2015.07.06 15:09:32.647 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:09:32.658 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:0293719D IDcnt:000F L:20 %
2015.07.06 15:09:32.853 0: HMLAN_Send: hmusb1 I:+1D252E,00,00,00
2015.07.06 15:09:47.889 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:09:48.052 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0151F3A3 IDcnt:0010 L:11 %
2015.07.06 15:09:48.142 0: HMLAN_Send: hmusb1 I:+1936FF,00,00,00
2015.07.06 15:09:57.656 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:09:57.672 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:0293D353 IDcnt:000F L:20 %
2015.07.06 15:10:12.897 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:10:12.948 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:015254E3 IDcnt:0010 L:11 %
2015.07.06 15:10:22.660 0: HMLAN_Send: hmlan1 I:K
2015.07.06 15:10:22.671 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:02943502 IDcnt:000F L:20 %
2015.07.06 15:10:37.904 0: HMLAN_Send: hmusb1 I:K
2015.07.06 15:10:37.972 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:0152B6A2 IDcnt:0010 L:11 %
2015.07.06 15:10:46.117 0: HMLAN_Send: hmlan1 I:-6869B6
2015.07.06 15:10:46.121 0: HMLAN_Send: hmusb1 I:+6869B6,00,00,
gruss frank
ist etwas entschärft. Doppelt sollte es nicht kommen. Aber wenn kein preffered Device gesetzt ist wird eines gesucht - das kann natürlich wechseln.
Hi Martin,
Zitat von: martinp876 am 06 Juli 2015, 21:12:34
ist etwas entschärft. Doppelt sollte es nicht kommen. Aber wenn kein preffered Device gesetzt ist wird eines gesucht - das kann natürlich wechseln.
hier sieht alles gut aus, Danke :-)
Einen kleinen Patch habe ich noch: bisher kommen keine trig_aes_XXX-Trigger fuer Geraete ohne explizit angelegte Channels (z.B. TFK). Das ist in dem Patch behoben.
Viele Gruesse
Michael