HMLAN - disconnects

[Benni]

Code Auswählen Erweitern

2016.12.01 00:33:56 1: Perfmon: possible freeze starting at 00:33:53, delay is 3.008
Wenn fhem 3 Sekunden lang durch "irgendetwas" blockiert ist dann bringt schönste der Elko, auch mit platinbeinchen, ... genau nix 
Der HMLAN ist braucht ein genaues timing. Das bekommt er nur wenn fhem nicht "irgendwo" 3 Sekunden schläft.

Wird der 3-Sekunden-Freeze an der Stelle nicht durch den disconnect und reconnect-Versuch vom HMLAN selbst verursacht?
Ich meine, das mal in irgendeinem Thread gelesen zu haben, nur find' ich den im Moment leider nicht wieder 

[frank]

Code Auswählen Erweitern

2016.12.01 00:33:50 5: PRESENCE (HMCFGLANcheck) - starting ping scan: HMCFGLANcheck|192.168.10.118|0|4
2016.12.01 00:33:50 5: HMLAN_Send:  HMLAN1 I:K
2016.12.01 00:33:51 1: HMLAN_Parse: HMLAN1 new condition timeout
warum irritierst du den sensiblen hmlan auch noch mit lan-ping?

[baerbel]

- das war die Konsequenz aus den Abbrüchen - habe den HMLAN gelingt - nun natürlich alle LAN pings draußen -

[baerbel]

kurzes Update nach 6 stunden uptime:

RASPI + HMLAN an einem Switch, der zur Fritzbox verbunden ist: bis jetzt kein disconnect - mal gucken, was die Nacht so bringt, denn zum Abend kommt ein wenig Last aufs System - verstehen tue ich es bis jetzt immer noch nicht, da laut apptime FHEM auf jemanden warten musste - warum das durch das Umstöpseln besser geworden ist ..... die einzigen zwei Abfragen, die ich noch einbauen werde, wenn bis morgen alles gut läuft ist die Fritzbox Abfrage auf das Gerät meiner Tochter (WLAN/Mac) und die Abfrage nach Batteriestatus (die hatte ich anfangs nämlich in Verdacht.

P.S.: HM Funklan liegt bereits auf dem Schreibtisch

Danke an alle -

Grüße - Bernd

[frank]

- das war die Konsequenz aus den Abbrüchen - habe den HMLAN gelingt - nun natürlich alle LAN pings draußen -

mir sieht das aber eher nach einem eigentor aus. 
ausserdem kann ich den grund für den ping nicht verstehen, der hmlan gibt noch genügend infos von sich aus.

das keepalive und der lanping (non blocking, aus 2. fhem instanz) kommen quasi gleichzeitig beim hmlan an.
anscheinend kommt es dadurch zum reboot des hmlan, denn die antwort vom keepalive kommt nicht mehr (timeout). ich denke auch, dass der 3 sekunden freeze danach vermutlich durch den reboot selbst erzeugt wird. 3 sekunden sind sicherlich nicht gut, aber für einen disconnect des hmlan, sollte das noch nicht genügen.

pings auf andere geräte sollten grundsätzlich auch keine probleme machen.

[baerbel]

Hi Frank, danke für die Antwort - hmm 2. FHEM Instanz: habe ich eigentlich nicht . Das mit dem Eigentor, tja da stimmt wohl - wollte mehr monitoring und habe noch ne Tasse Sprit ins Feuer gegossen - die drei Sekunden konnte ich auch so nachvollziehen, somit passt das.

Habe nun vorsorglich mal dennoch alle pings "abgeschafft" - monitoring "light" für meine presence Kollektoren über ein BT device, welches nur rumliegt - sollte das nicht mehr zu sehen sein Pushover Benachrichtigung - zwar nicht 100%-ig, gibt aber ein Gefühl dafür wann entweder FHEM nicht da ist oder in der Tat ein Netzwerk Thema anstehen könnte.

Seit gestern noch ein HM Funklan GW eingebunden - mal sehen, wie es die kommenden Tage weitergeht -

Danke und Gruß,

Bernd

[frank]

hmm 2. FHEM Instanz: habe ich eigentlich nicht

nicht grundsätzlich.
presence arbeitet nicht-blockierend. für die dauer des pingens wird daher ein fork von fhem ("fheminstanz") etabliert.

[baerbel]

Ahhhh - jetzt verstehe ich (wieder ein wenig) mehr

[Danny]

Darf ich mich hier einklinken ?
Ich habe/hatte bis vor kurzem massive Disconnect Probleme (minütlich) und wollte Mal meine Untersuchungen hier kundtun.

Nun:
Ich hatte zwar ab und an Disconnects, hatte sie aber bisher ignoriert, bis ich dann gelesen hatte, dass man diese 'unterdrücken' kann, indem eine VCCU definiert. Es kamen verschiedene andere Anpassungen und Erweiterungen sowie updates hinzu. Plötzlich hatte ich jedoch diese minütlichen Disconnects und Reappears. FHEM war quasi nicht mehr bedienbar . Was ist geschehen ?
Ich hatte natürlich auch die Vermutung, dass irgendwie mein HMLAN, welches direkt and Fritzbox hängt, Connection Probleme hatte.
Aber da war eine Änderung, die ich begonnen aber noch nicht fertiggestellt hatte, welche ich sowieso noch nicht verstanden hatte:
SYSSTAT
Ich hatte gelesen, damit könnte ich meine Synology NAS monitoren.
Meine Definition sah wie folgt aus (Vorlage hier):

Code Auswählen Erweitern


define KN_NASStat SYSSTAT 60 600 10.0.5.59

attr KN_NASStat disable 1
attr KN_NASStat mibs .1.3.6.1.4.1.6574.2.1.1.6.0:temp_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.6.1:temp_hdd2 ,.1.3.6.1.4.1.6574.2.1.1.5.0:state_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.5.1:state_hdd2
attr KN_NASStat room Wohnung
attr KN_NASStat snmp 1
attr KN_NASStat snmpCommunity fritz.box
attr KN_NASStat snmpVersion 2
attr KN_NASStat synologytemperature 1
attr KN_NASStat uptime 1


Dann habe ich mir gedacht, ich gehe alles wieder Schritt für Schritt zurück und habe meine SYSSTAT Definition disabled.
Und siehe da, (fast) keine Disconnects mehr 

Nur, wieso? kann ich nicht sagen!
Ich hatte dazu gelesen, daß sog. Multicast Pakete auf dem Netz für Ausfälle des HMLAN sorgen können. Ob so etwas durch SYSSTAT bzw. SNMP verursacht wird ... dazu kann ich nichts sagen. Da bin ich kein Experte. Vielleicht können sich Experten dazu äussern und dazu beitragen, das Problem in den Griff zu bekommen.

Übrigens:
Ich hatte mich auch schon an eq3 gewendet. Die Rückmeldung war ungefähr: "So wie Sie die Sachlage beschreiben, scheint das HMLAN defekt zu sein. Falls noch Garantie besteht sollten Sie sich an den Händler wenden ... blah blah". Ich hatte ihn schon abgeschrieben ...

[baerbel]

Hi Danny,

stecke gerade selber mitten in der "Aufklärung" - was mir hilft ist perfmon und apptime - hattest du damit und den entsprechenden Anpassungen bzgl. Logging bereits mal "experimentiert"?

Apptime bringt mich direkt zu einer Sache, die ich heute in der Früh gesehen hatte:

Code Auswählen Erweitern

name             function    max  count    total  average maxDly
                 tmr-CODE(0x5799480)      HASH(0x5c1c2c0)      0      1        0     0.00 1480757262841
                 tmr-CODE(0x5c05ff0)      HASH(0x5c19428)      0      1        0     0.00 1480757262841
                 tmr-CODE(0x5c14fe0)      HASH(0x5c03648)      0      1        0     0.00 1480757262841
                 tmr-CODE(0x5c1ce60)      HASH(0x5bfeb10)      0      1        0     0.00 1480757262841
          tmr-Heating_Control_Update      HASH(0x4fdbc68)     21      1       21    21.00 5271053 HASH(HCB_2)
          tmr-Heating_Control_Update      HASH(0x576f278)     21      1       21    21.00 5271031 HASH(HCB.Schlafzimmer_2)
          tmr-Heating_Control_Update      HASH(0x4fdc828)     21      1       21    21.00 5271009 HASH(HCB.Wohnzimmer_Klavier_2)
          tmr-Heating_Control_Update      HASH(0x4fde4e8)     22      1       22    22.00 5270987 HASH(HCB.Wohnzimmer.Arbeitsplatz_2)
            tmr-perfmon_ProcessTimer      HASH(0x1e17308)      0    353        0     0.00   2841
                   tmr-CUL_HM_procQs        CUL_HM_procQs     52     17      129     7.59   2820 CUL_HM_procQs
           tmr-WeekdayTimer_SetTimer      HASH(0x52c59d0)     52      1       52    52.00   2150 HASH(Test.da)
           tmr-WeekdayTimer_SetTimer      HASH(0x4f5af90)     52      1       52    52.00   2108 HASH(Monika.anwesend)
        tmr-Heating_Control_SetTimer      HASH(0x4ffc5b0)    110      1      110   110.00   2090 HASH(HCB.Wohnzimmer.Arbeitsplatz)
        tmr-Heating_Control_SetTimer      HASH(0x59d3d00)    102      1      102   102.00   2016 HASH(HCB.Schlafzimmer)
        tmr-Heating_Control_SetTimer      HASH(0x527aea8)    109      1      109   109.00   1993 HASH(HCB)
        tmr-Heating_Control_SetTimer      HASH(0x5a0c9c8)    102      1      102   102.00   1862 HASH(HCB.Wohnzimmer_Klavier)
tmr-WeekdayTimer_delayedTimerInPast      HASH(0x609f0f8)      0      1        0     0.00   1527
          tmr-FRITZBOX_Readout_Start     Fritzbox.Readout     78      3      110    36.67   1432 Fritzbox.Readout
             tmr-CUL_HM_updateConfig         updateConfig   1344      1     1344  1344.00   1375 updateConfig
          tmr-HMUARTLGW_CheckCredits HMUARTLGW_CheckCredits:HMLAN2      3     27       59     2.19   1192 HMUARTLGW_CheckCredits:HMLAN2
                    tmr-HMLAN_clearQ      hmClearQ:HMLAN1      0      3        0     0.00   1053

Mein Verständnis war/ist, dass alles über eine Sekunden / 3 Sekunden kritisch ist und die Kommunikation zum HMxxx gefährdet. Kann mir jemand helfen, wie die obentehenden Einträge zu bewerten sind? Habe trotz der Einträge keine Disconnects -

Grüße, Bernd

[budy]

Moin Bernd,

ich sehe in deiner Liste nichts bedrohliches...? Das man mal von perfmon den Hinweis bekommt, das da etwas blockt, ist glaube ich normal. Außerdem meine ich mich auch zu erinnern, dass der HMLAN erst nach 30s einen heartbeat timeout erzeugt. Selbst wenn ich mal nachts beim verkleinern der MySQL DBs eine Blockade von 7s habe, bekomme ich noch keinen HMLAN disconnect...

Gruß,
Stephan

[herrmannj]

naja, normal ist relativ 

Ob es zu Problemen dadurch kommt hängt von den Umständen ab. Generell bedeutet es jedoch das, wenn man in dem Moment auf einen Lichtschalter drückt, das Licht erst 7 Sekunden später angeht. Ob man damit leben möchte muss man entscheiden

vg
joerg

[budy]

Moin Jörg,

das ist mir schon klar... Ich wollte auch nur damit ausdrücken, dass es noch keinen HMLAN disconnect gibt, wenn mal ein Prozess länger als 3s blockiert. Und dbReduce setzte ich halt deswegen auch immer Nachts um 04.00 Uhr ein, weil die Wahrscheinlichkeit, dass da genau mal jemand ein Licht anschalten möchte doch schon seeehr klein ist.

Sollte das aber doch mal wiederholt vorkommen, könnte man das sicherlich auch anders lösen, da die DB gar nicht auf dem RPi läuft.

Gruß,
Stephan

[baerbel]

Hi Stefan, Jörg,

danke euch für die Einschätzungen - hatte bis dato das grosse Glück, dass ich noch nie 7 Sekunden warten musste - wenn, dann ging "gar nichts mehr" - die Werte die ich nicht zuordnen kann sind die in den ersten Zeilen - denn die Zahlen sind ja exorbitant - kann kein delay sein, aber was ist das oder worauf beziehst sich das?

Grüße - Bernd

[baerbel]

... so jetzt nochmal zurück zum Ausgangsthema - disconnects - die Veränderungen von Ort und Switch zwischen hängen waren schon mal nicht schlecht - was aber nun seit fast einem Tag zu richtiger Stabilität geführt hat:

Mein eigenes Unvermögen ausbügeln - ich hatte zwei Fritzbox(en) definiert - was schon mal per se keine gute Idee ist, vor allem wenn sie auf das gleiche Device zeigen - was vermutlich so richtig ungeschickt war: die eine Definition war ohne IP angelegt und die Fritzbox selber hat auch noch einen anderen Namen -

die "namenlose" Definition gelöscht und nun wie gesagt seit einiger Zeit (fast einem Tag) keinen disconnect - also sollte jemand ähnlich "unerklärliche" Phänomene haben: guckt mal in die Richtung ....

In diesem Sinne einen schönen Abend -

- Bernd