IOErr wegen "disconnected" HMUSB?

Motivierte linke Hände · 10 Juni 2015, 17:53:17

Hi Martin, alle!

Gestern habe ich das FHEM-Update gemacht, einschließlich 10_CUL_HM. Seitdem haben nun über den Tag verteilt ca. 70% meiner HM-SEC-SCo den Status "IOErr":

List auf ein Beispiel:

Code Auswählen

Internals: 
   DEF        35C1DE 
   HMLAN1_MSGCNT 59 
   HMLAN1_RAWMSG E35C1DE,0000,036A1460,FF,FFAC,E3A61035C1DEAA100106010000 
   HMLAN1_RSSI -84 
   HMLAN1_TIME 2015-06-10 17:06:15 
   HMLAN2_MSGCNT 60 
   HMLAN2_RAWMSG E35C1DE,0000,118F17E3,FF,FFB3,E3A61035C1DEAA100106010000 
   HMLAN2_RSSI -77 
   HMLAN2_TIME 2015-06-10 17:06:15 
   IODev      HMUSB 
   LASTInputDev HMLAN2 
   MSGCNT     119 
   NAME       Fstr_Bad1 
   NR         172 
   NTFY_ORDER 50-Fstr_Bad1 
   STATE      IOerr 
   TYPE       CUL_HM 
   lastMsg    No:E3 - t:10 s:35C1DE d:AA1001 06010000 
   peerList   Hzg_Bad_WindowRec, 
   protCmdDel 70 
   protIOerr  11 last_at:2015-06-10 17:07:11 
   protLastRcv 2015-06-10 17:06:15 
   protState  CMDs_done_Errors:1 
   rssi_at_HMLAN1 max:-81 cnt:59 avg:-88.28 lst:-84 min:-99 
   rssi_at_HMLAN2 min:-79 cnt:60 avg:-76.71 lst:-77 max:-76 
   Readings: 
     2015-06-10 08:36:28   Activity        alive 
     2015-05-22 08:36:23   CommandAccepted no 
     2015-01-31 11:43:03   D-firmware      1.0 
     2015-01-31 11:43:03   D-serialNr      LEQ1467507 
     2015-06-03 12:00:41   PairedTo        0xAA1001 
     2015-01-31 11:43:08   R-Hzg_Bad_WindowRec-expectAES off 
     2015-01-31 11:43:08   R-Hzg_Bad_WindowRec-peerNeedsBurst on 
     2015-01-31 11:34:24   R-cyclicInfoMsg on 
     2015-01-31 11:34:24   R-eventDlyTime  0 s 
     2015-01-31 11:34:24   R-msgScPosA     open 
     2015-01-31 11:34:24   R-msgScPosB     closed 
     2015-01-31 11:34:24   R-pairCentral   0xAA1001 
     2015-01-31 11:34:24   R-sabotageMsg   on 
     2015-01-31 11:34:24   R-sign          on 
     2015-01-31 11:34:24   R-transmDevTryMax 6 
     2015-01-31 11:34:24   R-transmitTryMax 6 
     2015-06-03 12:00:41   RegL_00:        02:01 09:01 0A:CD 0B:20 0C:07 10:01 14:06 00:00 
     2015-06-03 12:00:41   RegL_01:        08:01 20:9C 21:00 30:06 00:00 
     2015-06-03 12:00:42   RegL_04:Hzg_Bad_WindowRec 01:01 00:00 
     2015-01-31 11:43:06   aesKeyNbr       00 
     2015-06-10 17:06:15   alive           yes 
     2015-06-10 17:06:15   battery         ok 
     2015-06-10 17:06:15   contact         closed (to vccu) 
     2015-06-10 08:36:28   peerList        Hzg_Bad_WindowRec, 
     2015-05-29 03:35:24   powerOn         2015-05-29 03:35:24 
     2015-06-10 17:06:15   recentStateType info 
     2015-06-03 12:01:31   sabotageAttack  ErrIoAttack cnt:3 
     2015-06-10 17:06:15   sabotageError   off 
     2015-06-10 17:07:11   state           IOerr 
     2015-01-31 15:28:56   trigDst_AA1001  noConfig 
     2015-06-10 12:40:32   trigDst_vccu    noConfig 
     2015-06-10 12:40:32   trigger_cnt     212 
   Helper: 
     HM_CMDNR   227 
     mId        00C7 
     rxType     28 
     Io: 
       newChn     +35C1DE,00,01,1E 
       nextSend   1433948775.83208 
       rxt        2 
       vccu       vccu 
       p: 
         35C1DE 
         00 
         01 
         1E 
       prefIO: 
         HMLAN1 
     Mrssi: 
       mNo        E3 
       Io: 
         HMLAN1     -84 
         HMLAN2     -77 
     Prt: 
       bErr       0 
       sProc      0 
       sleeping   0 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       chn        1 
       dev        1 
     Rpt: 
       IO         HMLAN1 
       flg        A 
       ts         1433948775.74436 
       ack: 
         HASH(0x412f768) 
         E38002AA100135C1DE00 
     Rssi: 
       At_hmlan1: 
         avg        -88.2881355932203 
         cnt        59 
         lst        -84 
         max        -81 
         min        -99 
       At_hmlan2: 
         avg        -76.7166666666667 
         cnt        60 
         lst        -77 
         max        -76 
         min        -79 
Attributes: 
   IODev      HMUSB 
   IOgrp      vccu:HMLAN1 
   actCycle   001:05 
   actStatus  alive 
   autoReadReg 4_reqStatus 
   devStateIcon open:fts_window_1w_tilt@orange closed:fts_window_1w IOerr:it_wifi@red 
   event-on-change-reading state 
   expert     2_full 
   firmware   1.0 
   fp_EG      60,450,0, 
   fp_fp_Grundriss_EG 180,450,0, 
   group      EG,Fenster 
   model      HM-SEC-SCo 
   peerIDs    00000000,3018CA03, 
   room       Bad,Cfg_Fenster 
   serialNr   LEQ1467507 
   struc_chkFstrKlein struc_FstrKlein 
   subType    threeStateSensor 
   userattr   struc_chkFstrKlein struc_chkFstrKlein_map structexclude

Auffällig finde ich, dass bei den Fenstern mit Fehlern "IODev HMUSB" steht, während "IOgrp vccu:HMLAN1" angegeben ist. Erschwerend kommt hinzu, dass es HMUSB derzeit gar nicht gibt (state disconnected - weil ich den mit hmland am Raspi derzeit nicht ordentlich zum Laufen bekomme, wie unter http://forum.fhem.de/index.php/topic,13071.msg302381.html#msg302381 beschrieben).

Laut Wiki "Das Attribut IODev wird automatisch gesetzt, Usereinträge sind irrelevant. Es zeigt indirekt das letzte genutzte output-device." könnte das die Ursache des Fehlers sein. Aber warum versucht die vccu den einzigen IO zu benutzen, der "disconnected" ist?

Meine vccu ist so definiert:

Code Auswählen

Internals: 
   DEF        AA1001 
   HMLAN1_MSGCNT 104 
   HMLAN1_RAWMSG EAA1001,0000,0384BDAA,FF,FFD4,4A8002AA100135E15100 
   HMLAN1_RSSI -44 
   HMLAN1_TIME 2015-06-10 17:35:22 
   HMLAN2_MSGCNT 296 
   HMLAN2_RAWMSG EAA1001,0000,11A769E6,FF,FFD3,898002AA100135C24E00 
   HMLAN2_RSSI -45 
   HMLAN2_TIME 2015-06-10 17:32:49 
   IODev      HMUSB 
   LASTInputDev HMLAN1 
   MSGCNT     400 
   NAME       vccu 
   NR         200 
   NTFY_ORDER 50-vccu 
   STATE      CMDs_done 
   TYPE       CUL_HM 
   channel_01 vccu_Btn1 
   channel_02 vccu_Btn2 
   channel_03 Btn_HUE_Kamin_Kueche 
   lastMsg    No:4A - t:02 s:AA1001 d:35E151 00 
   protLastRcv 2015-06-10 17:35:22 
   rssi_at_HMLAN1 min:-44 max:-43 avg:-43.78 cnt:104 lst:-44 
   rssi_at_HMLAN2 min:-46 lst:-45 avg:-45.72 cnt:296 max:-45 
   Readings: 
     2015-06-10 17:35:22   CommandAccepted yes 
     2015-03-26 09:17:02   aesKeyNbr       04 
     2015-02-02 16:36:12   recentStateType ack 
     2015-04-27 22:33:50   state           CMDs_done 
     2015-02-22 21:49:10   unknown_1389FB  received 
     2015-02-21 15:25:56   unknown_2422C4  received 
     2015-02-22 22:15:33   unknown_2881AC  received 
     2015-02-22 21:45:17   unknown_2881D4  received 
     2015-02-01 09:37:42   unknown_2A7855  received 
     2015-02-01 11:03:15   unknown_2A7989  received 
     2015-03-12 07:50:20   unknown_2C7C23  received 
     2015-02-10 21:50:56   unknown_2DDE87  received 
     2015-02-10 20:35:16   unknown_2DDF45  received 
     2015-06-05 13:57:11   unknown_2F2452  received 
     2015-02-05 11:12:09   unknown_2F2828  received 
     2015-02-06 10:31:10   unknown_2F57B6  received 
     2015-02-14 08:43:42   unknown_301BF1  received 
     2015-03-22 16:45:38   unknown_31898C  received 
     2015-03-22 11:29:09   unknown_3189B1  received 
     2015-05-17 10:46:03   unknown_324531  received 
     2015-02-15 09:32:34   unknown_324549  received 
     2015-03-12 08:35:04   unknown_3255F7  received 
     2015-02-05 06:54:11   unknown_33B27B  received 
     2015-02-04 08:59:56   unknown_33B27F  received 
     2015-02-02 07:32:34   unknown_33B492  received 
     2015-03-26 08:58:20   unknown_349F19  received 
     2015-02-05 08:58:41   unknown_359EAC  received 
     2015-02-05 07:51:36   unknown_359ED6  received 
     2015-02-05 09:00:36   unknown_359ED7  received 
     2015-02-05 08:40:00   unknown_359EFA  received 
     2015-02-05 08:51:20   unknown_359F54  received 
     2015-02-05 08:36:05   unknown_359F61  received 
     2015-02-05 08:53:56   unknown_359FB8  received 
     2015-02-01 20:00:10   unknown_35C264  received 
     2015-02-22 21:48:44   unknown_CD2006  received 
   Helper: 
     HM_CMDNR   74 
     mId        FFF0 
     rxType     1 
     Io: 
       nextSend   1433950522.82236 
       prefIO 
       vccu 
     Mrssi: 
       mNo        4A 
       Io: 
         HMLAN1     -44 
     Prt: 
       bErr       0 
       sProc      0 
       Rspwait: 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       dev        1 
     Rssi: 
       At_hmlan1: 
         avg        -43.7884615384615 
         cnt        104 
         lst        -44 
         max        -43 
         min        -44 
       At_hmlan2: 
         avg        -45.7263513513514 
         cnt        296 
         lst        -45 
         max        -45 
         min        -46 
Attributes: 
   IODev      HMUSB 
   IOList     HMUSB,HMLAN1,HMLAN2 
   expert     2_full 
   model      CCU-FHEM 
   room       Cfg_HM 
   subType    virtual 
   webCmd     virtual:update

Bis vor dem Update funktionierte es hier - auch wenn der HMUSB disconnected war.

Im Log finden sich keine Fehler.

Danke, Christian

Edith hat den sinnlosen Betreff korrigiert.

cruser1800 · 10 Juni 2015, 18:51:25

Ich hatte das gleich Problem nach einem Update mit den HM-LC-Bl1PBU-FM. Selbt ein Reset und neu anlernen des Device hat nicht geholfen. Habe ein Restore der letzten Sicherung gemacht und alles ist wieder i.O.

Also erstmal kein Update für mich!

Ralli · 10 Juni 2015, 19:04:23

Dto.

http://forum.fhem.de/index.php/topic,37787.msg302596.html#msg302596

Motivierte linke Hände · 10 Juni 2015, 19:23:59

Noch 3 Infos: Die Fensterkontakte leuchten bei Öffnen/Schließen rot, nicht mehr grün. Thermostate machen auch Probleme. Die Rausnahme des HMUSB aus der IOList hat nichts geändert.

Nach Einspielen des Backups funktioniert es wieder.

martinp876 · 10 Juni 2015, 21:56:59

hm - seltsam. Da hat sich nichts geändert.

wie sieht es mit dem HMUSB aus? Welchen Status hat der? und was steht in XmitOpen (Internal)?

was gibt ein

{my $n = "sw";;CUL_HM_assignIO($defs{$n});;return AttrVal($n,"IODev","keiner")}
zurück? sw musst du gegen den Namen des Devices ersetzen - klar.

Motivierte linke Hände · 10 Juni 2015, 23:10:42

Danke, dass Du Dich kümmerst.

Status HMUSB "disconnected". Den Rest liefere ich morgen Abend oder am Freitag nach. Dafür müsste ich wieder die andere Version zurückspielen. Da dann keine Homematic-Komponente mehr funktioniert und ich morgen früh raus muss, geht's jetzt erstmal in die Horizontale.

Gute Nacht, Christian

Rince · 11 Juni 2015, 21:18:14

Habe keine AES Komponenten, aber nach einem Update wohl das gleiche Problem (IOerr, kann nix schalten...)

Habe es so gelöst bekommen:

1. ssh Terminal aufmachen, anmelden
2. fhem stoppen

Code Auswählen

/etc/init.d/fhem stop
3. via git den aktuellen HMLAND gezogen

Code Auswählen

git clone git://git.zerfleddert.de/hmcfgusb
4. in das Verzeichnis gewechselt

Code Auswählen

cd hmcfgusb
5. den Kompiler angeworfen

Code Auswählen

make
6. fhem wieder angeworfen

Code Auswählen

/etc/init.d/fhem start

Alles wieder so wie es sein soll

Wenn der Beitrag unsinnig ist, bitte ignorieren...

Motivierte linke Hände · 11 Juni 2015, 22:35:23

Ich teste morgen mal. Die Probleme oben waren mit originalen HMLAN-Adaptern, ohne hmland und HMUSB.

Rince · 11 Juni 2015, 23:55:05

In dem Fall brauchst nicht testen, obiges Prozedere hilft nicht

Ralli · 12 Juni 2015, 05:42:05

Und auch bei mir bringt das nix, den hmland für die HM-CFG-USB2 hatte ich nämlich vorher schon geupdatet.

Bei mir ist der Fehler reproduzierbar; sobald ich von diesen funktionierenden Versionen

# $Id: fhem.pl 8690 2015-06-04 16:47:20Z rudolfkoenig $
# $Id: 00_CUL.pm 8679 2015-06-02 12:19:23Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 8683 2015-06-03 21:26:40Z martinp876 $
# $Id: 00_HMLAN.pm 7822 2015-02-01 16:28:10Z martinp876 $
# $Id: 98_HMinfo.pm 8632 2015-05-25 09:09:05Z martinp876 $

ein Update auf die aktuellen Versionen durchführe, klappen keine HomeMatic-Devices mehr. Ich habe mit Verbose 5 ein Log vom Start mitgeschnitten, das ist aber riesig.

Die IO stehen auf opened und laut Log scheint es zu/von den HMLANs auch Funkverkehr zu geben aber die CCU scheint das nicht korrekt weiter zu verarbeiten. Das Log habe ich Dir, Martin, per PN geschickt.

Philipp · 12 Juni 2015, 10:54:08

Hallo,

eben bei meinem Kollegen auch passiert, neue aktuelle FHEM Installation, 2 HMLAN, 2 6fach Taster, 11 Rollädenaktoren.
HMLAN definiert, VCCU angelegt, ,alles angelernt. Kein Problem.

Dann den Fehlerfall simuliert und einen HMLAN ausgesteckt und nix geht. Kein Neustart hilft, sendet immer nur über den letzten HMLAN.

Hab dann meine 10_CUL_HM.pm 8426 eingespielt und alles läuft. Rückmeldungen auf den 6fach Tastern, nach kurzer Wartezeit funktionieren auch die Aktoren wieder. Vielleicht liegt der Fehler schon weiter zurück und ist noch Niemanden aufgefallen?

lg
Philipp

Motivierte linke Hände · 12 Juni 2015, 11:15:56

Also, die gute Nachricht ist, das ist reproduzierbar. Eben update&restart, Fenster auf, Fenstermelder leuchtet grün. Ich denke mir, alles in Ordnung, gehe joggen, komme wieder - lauter IOErr auf dem Statustablet. Selbes Fenster wieder auf - rot. Logfile ist frei von Meldungen (was natürlich auch am Loglevel liegen kann).

IODev wurde auch überall wieder auf HMUSB geändert, das einzige "disconnected" IO Device. Die beiden HMLAN existieren, scheinen aber nicht verwendet zu werden.

Die von Martin erbetenen Informationen, bevor ich jetzt wieder die alte Version einspiele:

Zitat von: martinp876 am 10 Juni 2015, 21:56:59
wie sieht es mit dem HMUSB aus? Welchen Status hat der? und was steht in XmitOpen (Internal)?

State disconnected, XmitOpen "0"

Zitat von: martinp876 am 10 Juni 2015, 21:56:59
was gibt ein

{my $n = "sw";;CUL_HM_assignIO($defs{$n});;return AttrVal($n,"IODev","keiner")}
zurück? sw musst du gegen den Namen des Devices ersetzen - klar.

HMUSB wird zurückgegeben.

Hilft das? Mache gerne weitere Tests. Interessant ist vielleicht wirklich auch die oben erwähnte Tatsache, dass es am Anfang nach dem Update kurz funktionierte.

Edith weiß was!

Da ich den HMUSB am Raspi inzwischen wieder relativ verlässlich zum Laufen bringe, habe ich hmland auf dem Raspi wieder gestartet. Erwartungsgemäß ging der HMUSB in FHEM nach kurzer Zeit über init auf ok und - der Fenstersensor funktioniert wieder.

Vielleicht funktioniert ja "nur" der "Failover" in der vccu jetzt anders/nicht mehr? Oder die HMLANs werden in ihrer Funkkapazität durch irgendwelche Probleme erschöpft, gar nicht genutzt...? Strenggenommen ist es übrigens m.E sinnfrei, den HMUSB als IO zu nutzen. Der hängt nämlich im Garten, die beiden HMLANs sind im Haus, je Stockwerk einer. RSSI des HMUSB ist für die meisten Devices hier mit am schlechtesten. Beispiel des Testfensters von eben:

HMLAN1_RSSI -64
HMLAN2_RSSI -64
HMUSB_RSSI -72

Der HMUSB hängt nur für zwei Sensoren da draußen, weil die wegen der Distanz teilweise Probleme haben und ich den HMUSB halt übrig hatte...

Ich lasse jetzt mal - solange der HMUSB durchhält - die neue Version laufen. Wenn ich was testen soll, bitte melden.

Grüße, Christian

Ralli · 12 Juni 2015, 11:23:11

Ich könnte raten, dass es was mit der IOList bzw. der darin befindlichen Reihenfolge zu tun haben könnte - das darin als erstes aufgeführte Device, ein CUL0, ist zur Zeit nämlich nicht in Betrieb. Und eigentlich sollte die vCCU ja damit umgehen können (was sie bis zum Update auch problemlos tut). Aber das ist jetzt ein Stochern im Nebel.

Motivierte linke Hände · 12 Juni 2015, 11:25:47

@Ralli: Siehe mein Edit oben: Kannst Du den CUL0 testweise in Betrieb nehmen?

Vielleicht hat die neue Version von CUL_HM ja tatsächlich eine andere Logik, welcher IO genutzt wird, die Funkstärke und Verbindung "falsch" oder "krumm" interpretiert?

Motivierte linke Hände · 13 Juni 2015, 17:57:56

können die Fenstermelder weiter Statusänderungen melden (LED leuchtet grün),
werden die Statusänderungen auch in FHEM empfangen und verarbeitet,
ABER: nach einer Zeit ohne Statusänderung gehen die Devices trotzdem alle auf "IOErr"; eine erneute Statusänderung dann setzt den Status richtig und überschreibt "IOErr" dadurch; allerdings tritt nach einiger Zeit wieder IOErr auf.
Edith hat festgestellt: Wenn der HMUSB aus der IOList der vccu entfernt wurde, gehen auch dann alle Devices nach einiger Zeit auf "IOErr", wenn HMUSB wieder "opened" statt disconnected ist. Offenbar will die vccu zwingend was über HMUSB machen, meint aber, dass es nicht geht, schon wenn HMUSB nicht mehr in der IOList steht. Ich füge daher jetzt HMUSB wieder der IOList hinzu.
Und Edith hat festgestellt: Wenn ich statt HMUSB HMLAN2 abhänge, entstehen keine IOErr.

Code Auswählen

Internals: 
   DEF        35BF3A 
   HMLAN1_MSGCNT 21 
   HMLAN1_RAWMSG E35BF3A,0000,1308945A,FF,FFC5,C4A64135BF3AAA100101FFC8 
   HMLAN1_RSSI -59 
   HMLAN1_TIME 2015-06-13 17:52:58 
   HMLAN2_MSGCNT 22 
   HMLAN2_RAWMSG E35BF3A,0000,212D9B6B,FF,FFBE,C4A64135BF3AAA100101FFC8 
   HMLAN2_RSSI -66 
   HMLAN2_TIME 2015-06-13 17:52:58 
   IODev      HMUSB 
   LASTInputDev HMLAN1 
   MSGCNT     43 
   NAME       Fstr_Buero 
   NR         31 
   NTFY_ORDER 50-Fstr_Buero 
   STATE      IOerr 
   TYPE       CUL_HM 
   lastMsg    No:C4 - t:41 s:35BF3A d:AA1001 01FFC8 
   peerList   Hzg_Buero_WindowRec,Hzg_Flur_WindowRec, 
   protCmdDel 14 
   protIOerr  4 last_at:2015-06-13 17:53:49 
   protLastRcv 2015-06-13 17:52:58 
   protState  CMDs_done_Errors:1 
   rssi_at_HMLAN1 max:-59 cnt:21 lst:-59 avg:-60.28 min:-64 
   rssi_at_HMLAN2 avg:-63.77 lst:-66 min:-68 cnt:22 max:-57 
   Readings: 
     2015-06-13 17:13:16   Activity        alive 
     2015-02-14 08:54:03   CommandAccepted yes 
     2015-02-14 08:54:02   D-firmware      1.0 
     2015-02-14 08:54:02   D-serialNr      LEQ1468201 
     2015-05-23 14:14:55   PairedTo        0xAA1001 
     2015-01-16 12:56:41   R-Hzg_Buero_WindowRec-expectAES on 
     2015-01-16 12:56:41   R-Hzg_Buero_WindowRec-peerNeedsBurst on 
     2015-01-31 10:50:54   R-Hzg_Flur_WindowRec-expectAES off 
     2015-01-31 10:50:54   R-Hzg_Flur_WindowRec-peerNeedsBurst on 
     2015-01-15 20:30:53   R-cyclicInfoMsg on 
     2015-01-15 20:30:53   R-eventDlyTime  0 s 
     2015-01-15 20:30:53   R-msgScPosA     open 
     2015-01-15 20:30:53   R-msgScPosB     closed 
     2015-01-15 20:30:53   R-pairCentral   0xAA1001 
     2015-01-15 20:30:53   R-sabotageMsg   on 
     2015-01-15 20:30:53   R-sign          on 
     2015-01-15 20:30:53   R-transmDevTryMax 6 
     2015-01-15 20:30:53   R-transmitTryMax 6 
     2015-05-23 14:14:55   RegL_00:        02:01 09:01 0A:CD 0B:20 0C:07 10:01 14:06 00:00 
     2015-05-23 14:14:55   RegL_01:        08:01 20:9C 21:00 30:06 00:00 
     2015-05-23 14:14:56   RegL_04:Hzg_Buero_WindowRec 01:81 00:00 
     2015-05-23 14:14:57   RegL_04:Hzg_Flur_WindowRec 01:01 00:00 
     2015-02-14 08:54:02   aesKeyNbr       04 
     2015-06-13 17:37:37   alive           yes 
     2015-06-13 17:52:58   battery         ok 
     2015-06-13 17:52:58   contact         open (to vccu) 
     2015-06-13 17:13:16   peerList        Hzg_Buero_WindowRec,Hzg_Flur_WindowRec, 
     2015-05-23 12:22:47   powerOn         2015-05-23 12:22:47 
     2015-06-13 17:37:37   recentStateType info 
     2015-06-13 17:37:37   sabotageError   off 
     2015-06-13 17:53:49   state           IOerr 
     2015-01-31 09:51:29   trigDst_AA1001  noConfig 
     2015-01-15 20:30:48   trigDst_broadcast noConfig 
     2015-06-13 17:52:58   trigDst_vccu    noConfig 
     2015-06-13 17:52:58   trigger_cnt     255 
   Helper: 
     HM_CMDNR   196 
     mId        00C7 
     rxType     28 
     Io: 
       newChn     +35BF3A,00,01,1E 
       nextSend   1434210778.80116 
       rxt        2 
       vccu       vccu 
       p: 
         35BF3A 
         00 
         01 
         1E 
       prefIO: 
         HMLAN2 
     Mrssi: 
       mNo        C4 
       Io: 
         HMLAN1     -59 
         HMLAN2     -66 
     Prt: 
       bErr       0 
       sProc      0 
       sleeping   0 
     Q: 
       qReqConf 
       qReqStat 
     Role: 
       chn        1 
       dev        1 
     Rpt: 
       IO         HMLAN2 
       flg        A 
       ts         1434210778.71313 
       ack: 
         HASH(0x28570a8) 
         C48002AA100135BF3A0101C800 
     Rssi: 
       At_hmlan1: 
         avg        -60.2857142857143 
         cnt        21 
         lst        -59 
         max        -59 
         min        -64 
       At_hmlan2: 
         avg        -63.7727272727273 
         cnt        22 
         lst        -66 
         max        -57 
         min        -68 
Attributes: 
   IODev      HMUSB 
   IOgrp      vccu:HMLAN2 
   actCycle   001:05 
   actStatus  alive 
   autoReadReg 4_reqStatus 
   devStateIcon closed:fts_window_1w open:fts_window_1w_open@red IOerr:it_wifi@red 
   event-on-change-reading state 
   expert     2_full 
   firmware   1.0 
   fp_UG      390,610,0, 
   fp_fp_Grundriss_UG 606,628,0,, 
   group      UG,Fenster 
   model      HM-SEC-SCo 
   peerIDs    00000000,2E59EB03,301BF103, 
   room       Büro,Cfg_Fenster,Flur 
   serialNr   LEQ1468201 
   struc_chkFstrGross struc_FstrGross 
   subType    threeStateSensor 
   userattr   struc_ChkFstrGross struc_ChkFstrGross_map struc_Fenster struc_Fenster_map struc_chkFenster struc_chkFenster_map struc_chkFstrGross struc_chkFstrGross_map structexclude