HMLAN Adapter wechselt permanent zwischen disconnected / connected

martinp876 · 19 April 2016, 21:31:20

Welches send? Ich brauche mehrere msgs vor dem Crash.

rx · 19 April 2016, 21:43:42

Beispiel:


2016.04.19 05:23:20.388 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:20.398 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0706588 d:1EA04F O:1EA04F t:031B8189 IDcnt:0078 L:31 %
2016.04.19 05:23:22.845 0: HMLAN_Parse: HMLAN1 R:E390C23   stat:0000 t:031B8B11 d:FF r:FFA9     m:C3 8410 390C23 1EA04F 06010400
2016.04.19 05:23:23.139 0: HMLAN_Parse: HMLAN1 R:E33972F   stat:0000 t:031B8C3A d:FF r:FFC8     m:0B A410 33972F 1EA04F 06010000
2016.04.19 05:23:24.391 0: HMLAN_Parse: HMLAN1 R:E31DC02   stat:0000 t:031B911F d:FF r:FFCE     m:0F 865A 31DC02 000000 88E021
2016.04.19 05:23:28.118 0: HMLAN_Parse: HMLAN1 R:E3903E3   stat:0000 t:031B9FAE d:FF r:FFDC     m:46 865A 3903E3 000000 88E21D
2016.04.19 05:23:33.784 0: HMLAN_Parse: HMLAN1 R:E21A55C   stat:0000 t:031BB5AC d:FF r:FFE2     m:CF 8410 21A55C 1EA04F 06012000
2016.04.19 05:23:42.674 0: HMLAN_Parse: HMLAN1 R:E2516C8   stat:0000 t:031BD88C d:FF r:FFCC     m:C6 845E 2516C8 000000 8A5714000023003508F8FC
2016.04.19 05:23:43.991 0: HMLAN_Parse: HMLAN1 R:E3903E3   stat:0000 t:031BDDB1 d:FF r:FFDC     m:09 A03F 3903E3 1EA04F 
2016.04.19 05:23:44.093 0: HMLAN_Send:  HMLAN1 S:S2C8B8F52 stat:  00 t:00000000 d:01 r:2C8B8F52 m:09 803F 1EA04F 3903E3 02041EA8613F
2016.04.19 05:23:44.094 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:49.096 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:54.097 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:59.099 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:24:04.100 1: HMLAN_Parse: HMLAN1 new condition timeout

Und hier dann vom zweiten HMLAN die Messages - da sieht man, dass noch was reinkommt aber vom ersten HMLAN nicht mehr empfangen wird:

Code Auswählen


2016.04.19 05:23:34.645 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:34.649 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0986152 d:3223B5 O:000041 t:2227FA21 IDcnt:0008 L:0 %
2016.04.19 05:23:42.653 0: HMLAN_Parse: HMLAN1 R:E2516C8   stat:0000 t:2228195A d:FF r:FFB2     m:C6 845E 2516C8 000000 8A5714000023003508F8FC
2016.04.19 05:23:43.969 0: HMLAN_Parse: HMLAN1 R:E3903E3   stat:0000 t:22281E7F d:FF r:FFB4     m:09 A03F 3903E3 1EA04F 
2016.04.19 05:23:44.097 0: HMLAN_Parse: HMLAN1 R:E1EA04F   stat:0000 t:22281EFF d:FF r:FFC1     m:09 803F 1EA04F 3903E3 02041EA86141
2016.04.19 05:23:44.370 0: HMLAN_Parse: HMLAN1 R:E31DC02   stat:0000 t:22282010 d:FF r:FFB6     m:0F 8470 31DC02 000000 00E021
2016.04.19 05:23:45.131 0: HMLAN_Parse: HMLAN1 R:E1EA04F   stat:0000 t:22282309 d:FF r:FFC1     m:09 803F 1EA04F 3903E3 02041EA8613F
2016.04.19 05:23:48.097 0: HMLAN_Parse: HMLAN1 R:E3903E3   stat:0000 t:22282E9F d:FF r:FFB4     m:46 8470 3903E3 000000 00E21D
2016.04.19 05:23:51.483 0: HMLAN_Parse: HMLAN1 R:E239878   stat:0000 t:22283BDA d:FF r:FFC0     m:9E 8670 239878 000000 00E325
2016.04.19 05:23:59.654 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:59.658 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0986152 d:3223B5 O:000041 t:22285BD6 IDcnt:0008 L:0 %
2016.04.19 05:24:03.060 0: HMLAN_Parse: HMLAN1 R:E3BAAC2   stat:0000 t:22286915 d:FF r:FFB2     m:52 8410 3BAAC2 1EA04F 06012600
2016.04.19 05:24:04.310 0: HMLAN_Parse: HMLAN1 R:E24EB56   stat:0000 t:22286DF9 d:FF r:FFAF     m:27 8410 24EB56 000000 06010000
2016.04.19 05:24:08.394 0: HMLAN_Parse: HMLAN1 R:E206A27   stat:0000 t:22287DEC d:FF r:FFB7     m:21 8670 206A27 000000 005444
2016.04.19 05:24:08.447 0: HMLAN_Parse: HMLAN1 R:E288145   stat:0000 t:22287E21 d:FF r:FFB4     m:5F 8670 288145 000000 008E45
2016.04.19 05:24:12.797 0: HMLAN_Parse: HMLAN1 R:E2E8C2D   stat:0000 t:22288F20 d:FF r:FFC4     m:5D 8610 2E8C2D 000000 0AC0F00C6400
2016.04.19 05:24:22.396 0: HMLAN_Parse: HMLAN1 R:E1F84EE   stat:0000 t:2228B4A0 d:FF r:FFB8     m:0C 8410 1F84EE 1EA04F 06012000

martinp876 · 20 April 2016, 21:25:58

Nichts zu sehen.
Wieviel devices hast du am hmlan?
Werden am io internal angezeigt.

franky08 · 20 April 2016, 21:45:42

Melde mich auch mal zu dem Thema. Seit ich die HM-OU-LED16 aus meinem System verbannt habe ist Schluss mit den ewigen disconnects.

VG
Frank

rx · 22 April 2016, 13:32:45

Nachdem mein HMLAN jetzt eine Uptime von 80 Stunden hat, wage ich mal zu behaupten, dass mein System jetzt stabil läuft. Vielleicht führt meine Vorgehensweise auch bei anderen zu einer Besserung, daher eine kurze Schilderung meiner Maßnahmen.

Nach allen Optimierungen innerhalb von fhem bezüglich Timeouts und einem direkten Anschluss des HMLAN an eine USB-Netzwerkkarte am Cubietruck hatte ich nur noch jeweils ein bis vier Reboots des HMLAN am Tag. Ich habe dann wie im Wiki beschrieben das Sniffen von HMLAN-Paketen aktiviert und mir nach einem Reboot im Logfile die folgende Stelle gesucht:

Code Auswählen

HMLAN_Parse: HMLAN1 new condition disconnected

Dann habe ich mir die Meldungen davor angeschaut und insbesondere die HMLAN_Send - Meldungen. Denn ich hatte mit einem zweiten HMLAN herausgefunden, dass die Reboots nicht auftauchen wenn das HMLAN nur empfängt.

Ein Beispiel habe ich hier:

Code Auswählen

2016.04.19 05:23:20.388 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:20.398 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:JEQ0706588 d:1EA04F O:1EA04F t:031B8189 IDcnt:0078 L:31 %
2016.04.19 05:23:22.845 0: HMLAN_Parse: HMLAN1 R:E390C23   stat:0000 t:031B8B11 d:FF r:FFA9     m:C3 8410 390C23 1EA04F 06010400
2016.04.19 05:23:23.139 0: HMLAN_Parse: HMLAN1 R:E33972F   stat:0000 t:031B8C3A d:FF r:FFC8     m:0B A410 33972F 1EA04F 06010000
2016.04.19 05:23:24.391 0: HMLAN_Parse: HMLAN1 R:E31DC02   stat:0000 t:031B911F d:FF r:FFCE     m:0F 865A 31DC02 000000 88E021
2016.04.19 05:23:28.118 0: HMLAN_Parse: HMLAN1 R:E3903E3   stat:0000 t:031B9FAE d:FF r:FFDC     m:46 865A 3903E3 000000 88E21D
2016.04.19 05:23:33.784 0: HMLAN_Parse: HMLAN1 R:E21A55C   stat:0000 t:031BB5AC d:FF r:FFE2     m:CF 8410 21A55C 1EA04F 06012000
2016.04.19 05:23:42.674 0: HMLAN_Parse: HMLAN1 R:E2516C8   stat:0000 t:031BD88C d:FF r:FFCC     m:C6 845E 2516C8 000000 8A5714000023003508F8FC
2016.04.19 05:23:43.991 0: HMLAN_Parse: HMLAN1 R:E3903E3   stat:0000 t:031BDDB1 d:FF r:FFDC     m:09 A03F 3903E3 1EA04F 
2016.04.19 05:23:44.093 0: HMLAN_Send:  HMLAN1 S:S2C8B8F52 stat:  00 t:00000000 d:01 r:2C8B8F52 m:09 803F 1EA04F 3903E3 02041EA8613F
2016.04.19 05:23:44.094 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:49.096 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:54.097 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:23:59.099 0: HMLAN_Send:  HMLAN1 I:K
2016.04.19 05:24:04.100 1: HMLAN_Parse: HMLAN1 new condition timeout
2016.04.19 05:24:04.139 3: Disconnect return value: -1
2016.04.19 05:24:04.272 1: 172.16.2.1:1000 disconnected, waiting to reappear (HMLAN1)
2016.04.19 05:24:04.294 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.04.19 05:24:07.394 1: Perfmon: possible freeze starting at 05:24:05, delay is 2.394
2016.04.19 05:25:07.535 1: 172.16.2.1:1000 reappeared (HMLAN1)

Das letzte HMLAN_Send vor dem Timeout geht an das Device mit der ID 3903E3. In dem Fall war das ein Wand-Thermostat (HM-TC-IT-WM-W-EU). In anderen Fällen war es mehrmals ein Bewegungsmelder oder auch ein Unterputzschaltaktor.

Ich habe dann jeweils

1. das Device zurückgesetzt (5 Sekunden Pairingknopf drücken, dann nochmal 5 Sekunden Pairingknopf oder wie im Handbuch des Device beschrieben)
2. das Device aus fhem komplett gelöscht
3. das Device neu gepaired
4. das Device konfiguriert (beim Bewegungsmelder z.B. Parameter wie "minInterval" angepasst)

Das habe ich für jedes Device wiederholt was vor dem Disconnect ein Send bekommen hat (das waren bei mir 5 verschiedene).

Und jetzt habe ich Ruhe mit Reboots - warum auch immer.

Grüße

Rampler · 22 April 2016, 15:25:27

Zitat von: rx am 22 April 2016, 13:32:45
Und jetzt habe ich Ruhe mit Reboots - warum auch immer.

Abwarten, ich glaube noch nicht dran....
Irgendwie habe ich keine Lust alle meine 55 Devices neu zu pairen ...
Trotzdem Danke für Deine Mühen

Nobby1805 · 22 April 2016, 16:34:23

Zitat von: Rampler am 22 April 2016, 15:25:27
Abwarten, ich glaube noch nicht dran....

Ich auch nicht

Ich habe durch diverse Maßnahmen im Netz Uptimes bis zu 844 Stunden erreicht ... aber manchmal sind es auch nur 200.
Als nur der HMLAN und ein Port des Rechners an einem LAN hingen gab es sogar keine Reboots bis zum Überlauf des internen Zeitzählers

Aus meiner Sicht ist allerdings jeder Reboot der nicht durch einen Stromausfall oder ein (nicht bekanntes) Kommando willentlich ausgelöst wird ein Fehler in der Firmware des HMLAN.

Mein Verdacht ist, dass der HMLAN Probleme hat wenn Aufgaben auf der LAN-Seite und der Funk-Seite quasi gleichzeitig ausgeführt werden sollen/müssen ... oder IT-technisch gesagt: irgendwo stimmt die Reentrancy der Kodierung nicht

rx · 28 April 2016, 23:08:24

Ich habe auch ca. 50 Devices und musste für den o.g. Effekt lediglich 5 neu pairen. Bislang keine Reboots mehr. Ich schließe daraus, dass es bei einer "schlechten" fhem-Konfiguration möglich ist, das HMLAN zum Reboot zu bringen. Da ich schon mehrere Monate teste, kann ich einen Uptime-Zufall mittlerweile ausschließen. Ich hatte vor dem Neu-Pairing immer mindestens 2 Reboots pro Tag.

PS: Dass es auch viele andere Gründe für einen Reboot des HMLAN gibt, steht für mich außer Frage.

Rampler · 29 April 2016, 20:17:30

Zitat von: rx am 28 April 2016, 23:08:24
Ich habe auch ca. 50 Devices und musste für den o.g. Effekt lediglich 5 neu pairen.

Ich frage mich, was anders ist oder wurde, nachdem neu gepairt wurde. Eigentlich sollte sich nach einem erneuten pairen doch nichts ändern. Oder ist der Softwarestand beim pairen von Bedeutung ?
Evtl.kann sich Martin mal dazu äußern ..

rx · 29 April 2016, 23:31:05

Aus dem älteren Backup habe ich aus der fhem.save folgendes extrahieren können:

vorher:

Code Auswählen

setstate FileLog_parkstrasse_vorratsraum_licht active
setstate parkstrasse_vorratsraum_licht off
setstate parkstrasse_vorratsraum_licht 2014-05-21 22:09:16 .D-devInfo 010100
setstate parkstrasse_vorratsraum_licht 2014-05-21 22:09:16 .D-stc 10
setstate parkstrasse_vorratsraum_licht 2014-10-20 17:45:31 .R-intKeyVisib invisib
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:35 .peerListRDate 2016-03-11 01:03:35
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 .protLastRcv 2016-03-11 06:58:27
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:56:23 CommandAccepted yes
setstate parkstrasse_vorratsraum_licht 2014-05-21 22:09:16 D-firmware 1.12
setstate parkstrasse_vorratsraum_licht 2014-05-21 22:09:16 D-serialNr KEQ0435000
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:34 PairedTo 0x1EA04F
setstate parkstrasse_vorratsraum_licht 2014-10-20 17:45:31 R-pairCentral 0x1EA04F
setstate parkstrasse_vorratsraum_licht 2014-10-20 17:45:32 R-sign off
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:34 RegL_00.  02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:34 RegL_01.  08:00 00:00
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 deviceMsg off (to broadcast)
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 level 0
setstate parkstrasse_vorratsraum_licht 2015-12-14 19:34:30 levelMissed desired:100
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 pct 0
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:32 powerOn 2016-03-11 01:03:32
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 recentStateType info
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 state off
setstate parkstrasse_vorratsraum_licht 2016-03-11 06:58:27 timedOn off

nachher:

Code Auswählen

setstate FileLog_parkstrasse_vorratsraum_licht active
setstate parkstrasse_vorratsraum_licht off
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:21 .D-devInfo 010100
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:21 .D-stc 10
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:27 .R-intKeyVisib invisib
setstate parkstrasse_vorratsraum_licht 2016-04-18 20:06:19 .peerListRDate 2016-04-18 20:06:19
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 .protLastRcv 2016-04-28 20:14:49
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:12:47 CommandAccepted yes
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:21 D-firmware 1.12
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:21 D-serialNr KEQ0435000
setstate parkstrasse_vorratsraum_licht 2016-04-18 20:06:18 PairedTo 0x1EA04F
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:27 R-pairCentral 0x1EA04F
setstate parkstrasse_vorratsraum_licht 2016-04-17 09:40:27 R-sign off
setstate parkstrasse_vorratsraum_licht 2016-04-18 20:06:18 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_vorratsraum_licht 2016-04-18 20:06:18 RegL_01. 08:00 00:00
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 deviceMsg off (to broadcast)
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 level 0
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 pct 0
setstate parkstrasse_vorratsraum_licht 2016-04-28 17:20:02 powerOn 2016-04-28 17:20:02
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 recentStateType info
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 state off
setstate parkstrasse_vorratsraum_licht 2016-04-28 20:14:49 timedOn off

Treppenlicht:

vorher:

Code Auswählen

setstate FileLog_parkstrasse_flur_treppe_licht active
setstate parkstrasse_flur_treppe_licht off
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:02 .R-intKeyVisib invisib
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:33 .peerListRDate 2016-03-05 19:28:33
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 .protLastRcv 2016-03-11 07:01:49
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:00:43 CommandAccepted yes
setstate parkstrasse_flur_treppe_licht 2014-05-21 22:09:15 D-firmware 1.12
setstate parkstrasse_flur_treppe_licht 2014-05-21 22:09:15 D-serialNr KEQ0632741
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:32 PairedTo 0x1EA04F
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:02 R-pairCentral 0x1EA04F
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:03 R-sign off
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:32 RegL_00.  02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:32 RegL_01.  08:00 00:00
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 deviceMsg off (to broadcast)
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 level 0
setstate parkstrasse_flur_treppe_licht 2014-08-17 07:25:00 levelMissed desired:0
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 pct 0
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:21:30 powerOn 2016-03-05 19:21:30
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 recentStateType info
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 state off
setstate parkstrasse_flur_treppe_licht 2016-03-11 07:01:49 timedOn off

nachher:

Code Auswählen

setstate FileLog_parkstrasse_flur_treppe_licht active
setstate parkstrasse_flur_treppe_licht off
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:02 .R-intKeyVisib invisib
setstate parkstrasse_flur_treppe_licht 2016-04-11 04:21:37 .peerListRDate 2016-04-11 04:21:37
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 .protLastRcv 2016-04-28 06:37:15
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:36:12 CommandAccepted yes
setstate parkstrasse_flur_treppe_licht 2014-05-21 22:09:15 D-firmware 1.12
setstate parkstrasse_flur_treppe_licht 2014-05-21 22:09:15 D-serialNr KEQ0632741
setstate parkstrasse_flur_treppe_licht 2016-04-11 04:21:35 PairedTo 0x1EA04F
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:02 R-pairCentral 0x1EA04F
setstate parkstrasse_flur_treppe_licht 2014-05-22 11:37:03 R-sign off
setstate parkstrasse_flur_treppe_licht 2016-04-11 04:21:35 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_flur_treppe_licht 2016-04-11 04:21:36 RegL_01. 08:00 00:00
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 deviceMsg off (to broadcast)
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 level 0
setstate parkstrasse_flur_treppe_licht 2014-08-17 07:25:00 levelMissed desired:0
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 pct 0
setstate parkstrasse_flur_treppe_licht 2016-04-27 05:05:50 powerOn 2016-04-27 05:05:50
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 recentStateType info
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 state off
setstate parkstrasse_flur_treppe_licht 2016-04-28 06:37:15 timedOn off

Was mir grundsätzlich auffällt ist, dass bei den alten RegL-Einträgen 2 Leerzeichen hinter "RegL_0X." stehen:

Code Auswählen

RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00

Bei den neu gepairten ist das nicht der Fall. Ich finde in meiner alten Config noch mehrere Einträge mit den zwei Leerzeichen:

# grep "RegL_00. 0" fhem.save
setstate parkstrasse_flur_tablet 2016-03-11 00:51:26 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_flur_treppe_licht 2016-03-05 19:28:32 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_flur_unten_licht 2016-03-07 21:21:11 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_hwr_licht 2016-03-07 19:01:45 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_kueche_lampe 2016-03-11 06:26:21 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00
setstate parkstrasse_vorratsraum_licht 2016-03-11 01:03:34 RegL_00. 02:01 03:00 04:00 05:00 06:00 07:00 08:00 09:00 0A:1E 0B:A0 0C:4F 00:00

In meiner aktuellen Config nicht mehr...

Rampler · 30 April 2016, 09:54:58

Ist schon merkwürdig...
Ich habe auch zwei Kanditaten:

Code Auswählen

klaus@Raspberry /opt/fhem/log $ grep "RegL_00.   0" fhem.save
setstate HW.licht 2016-04-28 21:14:49 RegL_00.   02:81 0A:29 0B:A0 0C:83 15:FF 18:00 00:00
setstate WC.licht 2016-04-29 00:19:42 RegL_00.   02:81 0A:29 0B:A0 0C:83 15:FF 18:00 00:00

klaus@Raspberry /opt/fhem/log $ grep "RegL_01.  0" fhem.save
setstate HW.licht 2016-04-28 21:14:50 RegL_01.  08:00  30:06 57:24 00:00
setstate WC.licht 2016-04-29 00:19:43 RegL_01.  08:00  30:06 57:24 00:00

Und das bekommt man nur durch repairen wieder hin ?

rx · 30 April 2016, 19:44:04

Meine Vermutung wäre: fhem stoppen, Datei fhem.save ändern (die Leerzeichen entfernen) und fhem wieder starten.

martinp876 · 30 April 2016, 20:01:08

Ein clear Register und dann ein getconfig halte ich fuer sinnvoller. Was soll!das editieren in der readings?
Fhem schreibt es auf eine Weise. Das muss passen oder adaptiert werden.

P.s. wo seht ihr ein Problem?

FhemPiUser · 18 Mai 2016, 20:49:11

gibt es inzwischen Neuigkeiten zu dem Thema? Ich habe auch häufig hmlan reboots mit ca 100 devices...

@rx: ist noch immer kein reboot aufgetaucht nach dem neu pairen?

Nobby1805 · 18 Mai 2016, 23:06:33

eQ-3 hat mich über ELV gebeten einen Wireshark-Log des Netzwerk-Traffic während eines Boots zur Verfügung zu stellen ... den ersten Log bei einem Boot der durch massiven Multicast-Verkehr der durch T-Entertain ausgelöst worden ist konnte ich bereits an ELV schicken.

Die selteneren Boots, die bei mir in Abständen von einigen zig bis zu 800 Stunden auftreten, erwarte ich z. Zt. ... wireshark läuft mit (uptime ist aktuell 223 Stunden)