Letztes Update Probleme mit HM-OU-LED16 u. HMLAN Disappear/Reappear

[franky08]

Habe jetzt mal apptime gestartet, melde mich dann mal wenn genug Daten da sind (apptime max).

VG
Frank

[franky08]

So, habe mal ein set ilum 0 0 auf das LED Teil losgelassen und dabei den HMLAN im Auge behalten. Kurz nach dem absetzen des Befehls, geht der HMLAN auf disconnect und das LED Teil bringt ein RESPONSE TIMEOUT:RegisterRead. Apptime max von diesem Zeitabschnitt bringt:

Code Auswählen Erweitern

name             function    max  count    total  average maxDly
                 tmr-Calendar_Wakeup      HASH(0x48a2e78)    387      1      387   387.00      5 HASH(Ferien)
                              HMLAN2           HMLAN_Read    368    523    13960    26.69      0 HASH(HMLAN2)
                              HMLAN1           HMLAN_Read    352    413    41179    99.71      0 HASH(HMLAN1)
                   Klima_Schalter_ny          notify_Exec    337      9     2527   280.78      0 HASH(Klima_Schalter_ny); HASH(TH_Sensor_WZ)
                     Klima_test1_nty          notify_Exec    290      9     2101   233.44      0 HASH(Klima_test1_nty); HASH(Temperatur_Garten)
                                 ds2       FHEM2FHEM_Read    283     27     2988   110.67      0 HASH(ds2)
                         tmr-at_Exec      HASH(0x559ae68)    283      5      988   197.60    617 HASH(Notabschaltung_at)
                              HMLAN3           HMLAN_Read    278    439     5163    11.76      0 HASH(HMLAN3)
                         tmr-at_Exec      HASH(0x5544980)    268    139    26537   190.91    580 HASH(Sub_DAC_Aufruf)
                     HZ_WZ_gesteuert        THRESHOLD_Set    256     13      890    68.46      0 HASH(HZ_WZ_gesteuert); HZ_WZ_gesteuert; external
                             myDbLog            DbLog_Get    215     52     2899    55.75      0 HASH(myDbLog); myDbLog; HISTORY; INT; 2015-01-01_00:00:00; 2016-01-01_00:00:01; Temperatur_Garten:temperature_avg_day:::; Temperatur_Garten:temperature_avg_day:::$val=($val>9?9:$val); Temperatur_Garten:temperature_avg_day:::$val=($val>14?14:$val); Temperatur_Garten:temperature_avg_day:::$val=($val>18?18:$val); Temperatur_Garten:temperature_avg_day:::
                                 ds1       FHEM2FHEM_Read    192     45     3788    84.18      0 HASH(ds1)
                         tmr-at_Exec      HASH(0x559b2e0)    187     12     1661   138.42    380 HASH(ADC_Abfrage)
                         tmr-at_Exec      HASH(0x4f68a00)    176     23     1773    77.09    194 HASH(HZ_Flur_Temp)
                         tmr-at_Exec      HASH(0x559a910)    176    175    12202    69.73    715 HASH(HZ_TH_at)
                   tmr-SYSMON_Update      HASH(0x4e630f8)    167     23     1527    66.39      8 HASH(Zotac_Status)
                         tmr-at_Exec      HASH(0x5616c48)    161      5      597   119.40    606 HASH(Fenster_oeffnen_Sommer)
                      Heizungswerte2 readingsGroup_Notify    159   4338    10745     2.48      0 HASH(Heizungswerte2); HASH(Kueche_Heizung_ClimRT_tr)
                    FileLog_sunDummy          FileLog_Get    156      5      594   118.80      0 HASH(FileLog_sunDummy); FileLog_sunDummy; CURRENT; INT; 2015-01-01_00:00:00; 2016-01-01_00:00:01; 4:sunDummy.sunrise\x3a::time2dec($fld[3]); 4:sunDummy.sunset\x3a::time2dec($fld[3]); 4:sunDummy.sunset\x3a::time2dec($fld[3])
                         tmr-at_Exec      HASH(0x55d9848)    154      8      752    94.00    401 HASH(Durchschnitt_Temp_Aufruf)
                         tmr-at_Exec      HASH(0x4e66500)    146      5      563   112.60    736 HASH(Gas_split_Abfrage)

P.S. Das lässt sich beliebig oft wiederholen, nach einem set ilum x 0 gleich darauf disconnect vom HMLAN

VG
Frank

[mgernoth]

Hallo,

passiert das auch, wenn man direkt das regBulk ausführt, welches von ilum intern benutzt wird?

Code Auswählen Erweitern


set Display regBulk RegL_00: 04:00 08:00


Bei mir (mit HMCFGUSB) läuft sowohl ilum wie auch regBulk ohne Probleme oder merkliche Hänger durch.

Gruß
  Michael

[martinp876]

Das Problem tritt nicht beim setzen sondern beim lesen auf. Besonders beim device sind die vielen Kanäle. Konnte damit zu tun haben. Aber das sollten wir hin bekommen.

[franky08]

Prima!

Vlt. könnte man mit prepare das Ganze gesammelt vorbereiten und dann mit exec ausführen, ähnlich wie beim RT.

VG
Frank

[frank]

der hmlan muss während der 10 sek pause sogar einen reboot gemacht haben, da die load nach dem reconnect von 8% auf 0% gesunken ist.

[franky08]

Stimmt, hat er gemacht, hatte ihn die ganze Zeit nicht aus dem Auge gelassen 

VG
Frank

[frank]

wenn du reproduzierbar mit jedem ilum einen hmlan reboot produzierst, müsstest du eigentlich mal den netzwerk traffic sniffen. vielleicht könnte man dadurch mal die misteriösen reboots des hmlan aufklären.

[franky08]

@frank
Könnte ich machen, hat aber wahrscheinlich nur mit einem gemanagten Switch Sinn und den habe ich z.Zt. in der Firma, habe dort über das WE Wireshark laufen, da dort im Netzwerk auch irgendwas im Argen liegt.

VG
Frank

[franky08]

So,da ich nur 5min von der Firma entfernt wohne, hab jetzt mal Wireshark angeworfen und ein set ilum 0 0 auf das LED Teil losgelassen, disconnect und reboot wie gehabt. Anbei der Wireshark Abschnitt, nach Timestamp 16:23:58 wird es interessant:

192.168.2.222 ist der hmlan1
192.168.2.66 fhem

[frank]

hi frank,

das ist ja schon mal ein anfang. da fehlen aber jetzt noch die daten in richtung hmlan. und bitte etwas mehr vor dem reboot, um den auslöser zu entdecken. 

[franky08]

Hatte einen Filter gesetzt, kann aber den kompletten Wireshark Mittschnitt mal hochladen, ist aber ziemlich viel! Sind über 2 MB!

[franky08]

Hier noch gefiltert hmlan ==> fhem:

[frank]

das komplette wär schon gut. ist aber leider gar nichts von fhem nach hmlan enthalten.

[franky08]

Weil ich dann den Switch umstellen mus 
Habe ich vergessen, ich gehe mit Wireshark jetzt mal direkt auf den "Haupt-Switch" dort laufen alle Pakete drüber ich setze diesmal aber keinen Filter und mache ein set ilum 1 0