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:
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 (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:
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.
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. :D
Also erstmal kein Update für mich!
Dto.
http://forum.fhem.de/index.php/topic,37787.msg302596.html#msg302596
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.
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.
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
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
/etc/init.d/fhem stop
3. via git den aktuellen HMLAND gezogen
git clone git://git.zerfleddert.de/hmcfgusb
4. in das Verzeichnis gewechselt
cd hmcfgusb
5. den Kompiler angeworfen
make
6. fhem wieder angeworfen
/etc/init.d/fhem start
Alles wieder so wie es sein soll :)
Wenn der Beitrag unsinnig ist, bitte ignorieren...
Ich teste morgen mal. Die Probleme oben waren mit originalen HMLAN-Adaptern, ohne hmland und HMUSB.
In dem Fall brauchst nicht testen, obiges Prozedere hilft nicht :(
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.
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
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
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.
@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?
Hab noch ein wenig getestet: Wenn der HMUSB auf "disconnected" geht, ist das oben beschriebene Verhalten jederzeit reproduzierbar.
Ich habe dann mal HMUSB aus der IOList der vccu gelöscht. Wenn der HMUSB dann auf disconnected geht
- 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.
Irgendwie scheint die vccu mir zu sehr an HMUSB zu hängen. ;) Ich habe nach dem Löschen von HMUSB aus der IOList auch die Config einmal gespeichert und FHEM neu gestartet. Das Logfile ist nach wie vor fehlermeldungslos.
Schönes Wochenende,
Christian
Edith liefert noch nach:
list auf das Fenster mit State "IOErr", bei dem das IODev aus irgendeinem Grund immer noch HMUSB ist:
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
deine rssi werte unter internals sind bei den 2 hmlan komischerweise unterschiedlich sortiert!
Interesant waere ein list der iodevices. Das koennte klaeren, warum die vccu das eine als ok und das anderr (falsche) als ok erkennt
Hier die lists:
HMLAN1:
Internals:
DEF 192.168.1.25:1000
DeviceName 192.168.1.25:1000
FD 51
HMLAN1_MSGCNT 3385
HMLAN1_TIME 2015-06-13 23:13:50
NAME HMLAN1
NR 177
NTFY_ORDER 50-HMLAN1
PARTIAL
RAWMSG E301909,0000,01035FF8,FF,FFBD,1186103019090000000A24E90E0040
RSSI -67
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 39
msgKeepAlive dlyMax:3.005 bufferMin:1
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly min:-9 max:3177 last:11 cnt:3351
owner AA1001
uptime 000 04:43:19.241
Readings:
2015-06-13 18:32:34 D-HMIdAssigned AA1001
2015-06-13 18:32:34 D-HMIdOriginal 2AEDE4
2015-06-13 18:32:34 D-firmware 0.964
2015-06-13 18:32:34 D-serialNr LEQ0403722
2015-06-13 18:32:34 Xmit-Events disconnected:1 init:1 ok:1
2015-06-13 18:32:34 cond ok
2015-05-06 12:42:16 prot_ERROR-Overload last
2015-05-06 13:00:51 prot_Warning-HighLoad last
2015-06-13 18:32:26 prot_disconnected last
2015-06-13 18:32:26 prot_init last
2015-06-07 05:30:26 prot_keepAlive last
2015-06-13 18:32:34 prot_ok last
2015-06-08 19:32:58 prot_timeout last
2015-06-13 18:32:26 state opened
Helper:
assIdCnt 39
assIdRep 39
info 03C4,LEQ0403722,2AEDE4,AA1001
setTime 43769
Cnd:
0 1
253 1
255 1
Dly:
cnt 3351
lst 11
max 3177
min -9
Ids:
2881ac:
name Sens_Heizkeller
2881d4:
name Sens_Waschkueche
2a7855:
name Sens_Keller
2a7989:
name Sens_Vorrat
2dde87:
name Wasser_Waschmaschine
2ddf45:
name Wasser_Heizung
2e5a49:
name Hzg_Gaestezimmer
2f2452:
name Sens_Aussen
2f2828:
name Sens_Garage
2f57b6:
name Fstr_Garagentor
3018c5:
chn 02
flg 0
msg
name Hzg_Wohnzimmer2
to 1434220095.7284
3018ca:
name Hzg_Bad
301905:
chn 02
flg 0
msg
name Hzg_Wohnzimmer1
to 1434219165.0173
301909:
name Hzg_Kueche
30190e:
chn 02
flg 0
msg
name Hzg_Wohnzimmer3
to 1434225127.85699
301926:
name Hzg_Schlafzimmer
30192a:
name Hzg_WC
301934:
chn 02
flg 0
msg
name Hzg_Julius
to 1434213661.7196
301bf1:
chn 02
flg 0
msg
name Hzg_Flur
to 1434221865.07341
301bfc:
name Hzg_Eingang
33b27b:
name Hzg_OG_links
33b27f:
name Hzg_OG_rechts
33b492:
chn 41
flg 0
msg
name Gong
to 1434223700.87705
359eac:
name Fstr_Vorratskeller
359ed6:
name Fstr_Treppenhaus
359ed7:
name Fstr_Heizungskeller
359efa:
name Fstr_OG_links2
359f54:
name Fstr_OG_links3
359f61:
name Fstr_OG_links1
359fb8:
name Fstr_OG_rechts
35c0da:
name Fstr_WohnzimmerTuer2
35c246:
name Fstr_KuecheGross2
35c247:
chn 01
flg 0
msg
name Fstr_Schlafzimmer2
to 1434219646.4269
35c24e:
chn 01
flg 0
msg
name Fstr_Schlafzimmer1
to 1434221845.99991
35c26d:
chn 01
flg 0
msg
name Fstr_WC
to 1434229418.90224
35c27b:
chn 01
flg 0
msg
name Fstr_Haustuer
to 1434224074.46142
35c28b:
chn 01
flg 0
msg
name Fstr_KuecheKlein
to 1434229444.83848
35c28d:
chn 01
flg 0
msg
name Fstr_KuecheGross1
to 1434229433.85414
35e14a:
chn 01
flg 0
msg
name Fstr_Schlafzimmer4
to 1434218978.29358
K:
BufMin 1
DlyMax 3.005
Next 1434230056.39096
Start 1434230031.39096
Log:
all 0
sys 0
ids:
ARRAY(0x1e51890)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Cap:
0 156
1 0
2 63
3 105
4 42
5 21
last 1
sum 387
Ref:
drft -0.00015999360025599
hmtL 16999241
kTs 0
offL 1434213032152
sysL 1434230031393
Attributes:
hmId AA1001
hmKey 02:747220e654d6046e4b9d6190d604ba54
hmLanQlen 1_min
room Cfg_HM
HMLAN2:
Internals:
DEF 192.168.1.26:1000
DeviceName 192.168.1.26:1000
FD 110
HMLAN2_MSGCNT 1496
HMLAN2_TIME 2015-06-13 23:14:39
NAME HMLAN2
NR 349
NTFY_ORDER 50-HMLAN2
PARTIAL
RAWMSG E2F2452,0000,0001E7E6,FF,FFB7,A386702F245200000000BB41
RSSI -73
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 8
msgKeepAlive dlyMax:0.633 bufferMin:4
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly min:6 max:2190 last:52 cnt:1449
owner AA1001
uptime 000 00:02:04.902
Readings:
2015-06-13 18:32:34 D-HMIdAssigned AA1001
2015-06-13 18:32:34 D-HMIdOriginal 2BA02F
2015-06-13 18:32:34 D-firmware 0.964
2015-06-13 18:32:34 D-serialNr LEQ0579692
2015-06-13 23:13:24 Xmit-Events disconnected:2 timeout:1 ok:2 init:2
2015-06-13 23:13:24 cond ok
2015-06-13 20:26:17 prot_disconnected last
2015-06-13 23:13:24 prot_init last
2015-06-07 05:30:26 prot_keepAlive last
2015-06-13 23:13:24 prot_ok last
2015-06-13 20:26:17 prot_timeout last
2015-06-13 23:13:24 state opened
Helper:
assIdCnt 8
assIdRep 8
info 03C4,LEQ0579692,2BA02F,AA1001
setTime 43769
Cnd:
0 2
252 1
253 2
255 2
Dly:
cnt 1449
lst 52
max 2190
min 6
Ids:
2422c4:
name Sens_Regen
2c7c23:
name Sens_Bad
31898c:
chn 04
flg 0
msg
name Swi_Pump2
to 1434215071.22967
3189b1:
chn 02
flg 0
msg
name Swi_Pump1
to 1434215109.78385
324531:
name HM_324531
324549:
name Sens_Briefkasten
3255f7:
chn 01
flg 0
msg
name Motion_Terrasse
to 1434219169.60246
349f19:
chn 02
flg 0
msg
name Swi_Garten
to 1434218222.0221
K:
BufMin 4
DlyMax 0.633
Next 1434230104.39502
Start 1434230079.39502
Log:
all 0
sys 0
ids:
ARRAY(0x325a0e0)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
apIDs:
Cap:
0 0
1 20
2 0
3 0
4 0
5 0
last 1
sum 20
Ref:
drft -0.00015996800639872
hmtL 124582
kTs 0
offL 1434229954815
sysL 1434230079397
Attributes:
hmId AA1001
hmKey 02:747220e654d6046e4b9d6190d604ba54
hmLanQlen 1_min
room Cfg_HM
HMUSB:
Internals:
DEF 192.168.1.29:1000
DeviceName 192.168.1.29:1000
HMUSB_MSGCNT 3442
HMUSB_TIME 2015-06-13 23:12:06
NAME HMUSB
NEXT_OPEN 1434230173.42952
NR 20
NTFY_ORDER 50-HMUSB
PARTIAL
RAWMSG E33B264,0000,14F09EF3,FF,FFC2,FE861033B2640000000A24E20F0040
RSSI -62
STATE disconnected
TYPE HMLAN
XmitOpen 0
assignedIDsCnt 19
msgKeepAlive dlyMax:2.984 bufferMin:2
msgLoadEst 1hour:0% 10min steps: 0/0/0/0/0/0
msgParseDly min:-10 max:3190 last:23 cnt:2998
owner AA1001
uptime 004 97:35:13.651
Readings:
2015-06-13 18:32:34 D-HMIdAssigned AA1001
2015-06-13 18:32:34 D-HMIdOriginal 2CC5DF
2015-06-13 18:32:34 D-firmware 0.967
2015-06-13 18:32:34 D-serialNr LEQ0659344
2015-06-13 23:12:11 Xmit-Events disconnected:2 init:1 ok:1
2015-06-13 23:12:11 cond disconnected
2015-01-27 15:14:44 prot_ERROR-Overload last
2015-06-08 09:40:41 prot_Unknown:53 last
2015-01-27 15:20:47 prot_Warning-HighLoad last
2015-06-13 23:12:11 prot_disconnected last
2015-06-13 18:32:25 prot_init last
2015-05-24 11:40:33 prot_keepAlive last
2015-06-13 18:32:34 prot_ok last
2015-06-12 07:24:23 prot_timeout last
2015-06-13 23:15:13 state disconnected
Helper:
assIdCnt 19
assIdRep 19
info 03C7,LEQ0659344,2CC5DF,AA1001
setTime 43769
Cnd:
0 1
253 2
255 1
Dly:
cnt 2998
lst 23
max 3190
min -10
Ids:
2ae6f4:
chn 01
flg 0
msg
name Fstr_Flurtuer
to 1434221978.11507
2e59eb:
name Hzg_Buero
301929:
name Hzg_Gaestebad
301a5f:
name Hzg_Waschkueche
33b25d:
name Hzg_Keller
33b264:
name Hzg_AusgTerrasse
35bf3a:
chn 01
flg 0
msg
name Fstr_Buero
to 1434229853.52678
35c07d:
chn 01
flg 0
msg
name Fstr_Gast
to 1434219331.09994
35c1de:
chn 01
flg 0
msg
name Fstr_Bad1
to 1434222042.3279
35c257:
chn 01
flg 0
msg
name Fstr_AusgTerrasse
to 1434221956.33875
35c264:
name Fstr_Schlafzimmer3
35c28e:
name Fstr_Wohnzimmer2
35e0bd:
chn 01
flg 0
msg
name Fstr_WohnzimmerTuer
to 1434223164.69426
35e103:
name Fstr_Wohnzimmer1
35e144:
chn 01
flg 0
msg
name Fstr_Bad2
to 1434222040.80624
35e151:
name Fstr_Keller
35e261:
name Fstr_Waschkueche
35e264:
name Fstr_Gaestebad
35e26e:
chn 01
flg 0
msg
name Fstr_Julius
to 1434221970.62434
K:
BufMin 2
DlyMax 2.984
Next 1434229943.38868
Start 1434229918.38868
Log:
all 0
sys 0
ids:
ARRAY(0x150f368)
Q:
HMcndN 253
answerPend 0
hmLanQlen 1
keepAliveRec 0
keepAliveRpt 0
apIDs:
Cap:
0 42
1 111
2 63
3 84
4 63
5 0
last 1
sum 363
Ref:
drft 5.61674689253478e-05
hmtL 351305124
kTs 0
offL 1433878613284
sysL 1434229668375
Attributes:
hmId AA1001
hmKey 02:747220e654d6046e4b9d6190d604ba54
hmLanQlen 1_min
room Cfg_HM
Grüße, Christian
Noch eine kleine Ergänzung:
Mir ist aufgefallen, dass nach einem Update auf die aktuellen Versionen in den IOs, die in IOList definiert sind, NICHT mehr das Internal "owner_CCU" vermerkt ist. Vielleicht gibt das einen Hinweis ...
ja, habe ich gefunden. genau der update wurde nicht mehr automatisch nach INIT aufgerufen.
Ist behoben.
Sehr gut. Danke! :)
Edit: Läuft!
Ja, das hat auch hier die Probleme beseitigt.
Vielen Dank!
Hallo,
ich lasse diesen Thread einmal wieder aufleben.
Mein hmusb macht mir Probleme und disconnected sich sehr oft. Aufgefallen ist es, als meine Lichtschalter zwischendurch eine rote Statusmeldung abgaben und die Steckdose im Keller auf einmal nicht mehr erreichbar war.
list hmusb:
Internals:
CHANGED
DEF 127.0.0.1:1234
DeviceName 127.0.0.1:1234
FD 19
IFmodel USB
NAME hmusb
NR 152
NTFY_ORDER 50-hmusb
PARTIAL
RAWMSG E24A658,0000,0DFCC490,FF,FFB7,29845E24A65800000082CDCA000021003008DAFE
RSSI -73
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 7
hmusb_MSGCNT 20
hmusb_TIME 2018-01-05 11:46:32
msgKeepAlive dlyMax:0.003 bufferMin:4
msgLoadCurrent 55
msgLoadHistoryAbs 5min steps: 55/54/0/0/0/0/0/0/0/0/0/0
owner 000345
uptime 002 65:12:05.155
READINGS:
2018-01-05 11:40:32 D-HMIdAssigned 000345
2018-01-05 11:40:32 D-HMIdOriginal 2639FD
2018-01-05 11:40:32 D-firmware 0.967
2018-01-05 11:40:32 D-serialNr KEQ1111250
2018-01-05 11:40:32 Xmit-Events ok:1 disconnected:1 init:1
2018-01-05 11:40:32 cond ok
2018-01-05 11:47:28 loadLvl batchLevel
2018-01-05 11:40:23 prot_disconnected last
2018-01-05 11:40:23 prot_init last
2018-01-05 11:40:32 prot_ok last
2018-01-05 11:40:23 state opened
helper:
assIdCnt 7
assIdRep 7
info 03C7,KEQ1111250,2639FD,000345
setTime 46238
cnd:
0 1
253 1
255 1
ids:
24A658:
cfg +24A658,00,00,00
chn 01
flg 0
msg
name HM_Steckdose
to 1515148839.24769
3AE0DB:
cfg +3AE0DB,00,00,00
chn 01
flg 0
msg
name HM_SZ.Lichtschalter
to 1515148839.29694
3CD48A:
cfg +3CD48A,00,00,00
name SZ.Fenster.Geschlossen
3F0C4E:
cfg +3F0C4E,00,00,00
name HM_3F0C4E
56F5A8:
cfg +56F5A8,00,00,00
chn 01
flg 0
msg
name HM_56F5A8
to 1515148835.38648
57CF01:
cfg +57CF01,00,00,00
name HM_57CF01
57D3C0:
cfg +57D3C0,00,00,00
name HM_57D3C0
k:
BufMin 4
DlyMax 0.003
Next 1515149273.28887
Start 1515149248.28887
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0x1c76a90)
q:
HMcndN 0
answerPend 0
hmLanQlen 3
keepAliveRec 1
keepAliveRpt 0
loadLastMax 55
loadNo 9
scnt 6
ald:
55
54
0
0
0
0
0
0
0
0
0
0
apIDs:
ref:
hmtL 234725155
kTs 0
Attributes:
event-on-change-reading .*
hmId 000345
hmLanQlen 3_normal
loadLevel 0:low,40:batchLevel,90:high,99:suspended
Ein Firmware Update eines Lichtschalters hat sogar garnicht funktioniert.
2018.01.05 11:11:47 3: CUL_HM set HM_SZ.Lichtschalter fwUpdate HM-LC-Sw1PBU-FM_update_V2_8_2_150713.eq3
2018.01.05 11:11:48 2: CUL_HM fwUpdate HM_SZ.Lichtschalter entered mode. IO-speed: fast
2018.01.05 11:11:53 1: HMLAN_Parse: hmusb new condition disconnected
2018.01.05 11:11:53 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2018.01.05 11:11:53 1: HMLAN_Parse: hmusb new condition disconnected
2018.01.05 11:11:54 1: HMLAN_Parse: hmusb new condition init
2018.01.05 11:11:54 1: 127.0.0.1:1234 reappeared (hmusb)
2018.01.05 11:11:55 1: HMLAN_Parse: hmusb new condition ok
2018.01.05 11:12:01 1: HMLAN_Parse: hmusb new condition disconnected
2018.01.05 11:12:01 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2018.01.05 11:12:01 1: HMLAN_Parse: hmusb new condition disconnected
2018.01.05 11:12:02 1: HMLAN_Parse: hmusb new condition init
2018.01.05 11:12:02 1: 127.0.0.1:1234 reappeared (hmusb)
2018.01.05 11:12:03 1: HMLAN_Parse: hmusb new condition ok
2018.01.05 11:12:08 1: HMLAN_Parse: hmusb new condition disconnected
2018.01.05 11:12:08 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2018.01.05 11:12:08 1: HMLAN_Parse: hmusb new condition disconnected
2018.01.05 11:12:09 1: HMLAN_Parse: hmusb new condition init
2018.01.05 11:12:09 1: 127.0.0.1:1234 reappeared (hmusb)
2018.01.05 11:12:10 1: HMLAN_Parse: hmusb new condition ok
2018.01.05 11:12:15 1: HMLAN_Parse: hmusb new condition disconnected
2018.01.05 11:12:15 1: 127.0.0.1:1234 disconnected, waiting to reappear (hmusb)
2018.01.05 11:12:15 1: HMLAN_Parse: hmusb new condition disconnected
2018.01.05 11:12:16 1: HMLAN_Parse: hmusb new condition init
2018.01.05 11:12:16 1: 127.0.0.1:1234 reappeared (hmusb)
2018.01.05 11:12:17 1: HMLAN_Parse: hmusb new condition ok
2018.01.05 11:12:22 1: HMLAN_Parse: hmusb new condition disconnected
FHEM ist nun auf dem aktuellen Stand und auch hmland habe ich einmal neu geladen und kompiliert.
Danach ist das Firmware Update zwar durchgelaufen, allerdings kommen immer noch zwischendurch disconnects.
Verabschiedet sich der hmusb nun langsam oder woran kann es liegen?
Vielleicht sind das normale Alterserscheinungen. Einer meiner HMLANs hat das auch immer mal wieder... Letztens wollte ich ihn schon ganz aufgeben, aber er hat sich dann doch noch wieder berappelt.