Alarmmeldung von HM-Lan ausschalten

[jmaus]

Ich hab mir auch mal ein paar Kurven aus dem Januar ausgeben lassen und da gab es dieses verhalten auch schon.
Also definitiv vor dem update

Das ist in der Tat eine interessante Beobachtung und spricht in der Tat dafür das ggf. der RFD Prozess oder das dort verbaute Funkmodul kurzzeitig aussteigt und deshalb auch der DC absinkt. Eine Frage hatte ich noch nicht gestellt: Handelt es sich bei den HM-LAN Gateways von den hier berichtet wird um RaspberryMatic Installation die im LAN-Gateway Modus arbeiten oder um originale eQ3 LAN Gateways (HM-LGW-O-TW-W-EU)?

[Ban]

Handelt es sich bei den HM-LAN Gateways von den hier berichtet wird um RaspberryMatic Installation die im LAN-Gateway Modus arbeiten oder um originale eQ3 LAN Gateways (HM-LGW-O-TW-W-EU)?

Bei mir sind es keine HM-LGW-O-TW-W-EU.
Bei mir sind es eQ3 HM-CFG-LAN (die runden) mit Firmware: 0.965, die das Problem haben. Einen HM-LGW-O-TW-W-EU habe ich nicht laufen.
Ich habe gestern ein Funkmodul bestellt und setzte mit RaspberryMatic ein HM-LAN-Gateway auf, dann kann ich damit gegentesten.

[condor07]

Ich hab mir auch mal ein paar Kurven aus dem Januar ausgeben lassen und da gab es dieses verhalten auch schon.
Also definitiv vor dem update

Das ist in der Tat eine interessante Beobachtung und spricht in der Tat dafür das ggf. der RFD Prozess oder das dort verbaute Funkmodul kurzzeitig aussteigt und deshalb auch der DC absinkt. Eine Frage hatte ich noch nicht gestellt: Handelt es sich bei den HM-LAN Gateways von den hier berichtet wird um RaspberryMatic Installation die im LAN-Gateway Modus arbeiten oder um originale eQ3 LAN Gateways (HM-LGW-O-TW-W-EU)?

Bei mir sind es alle 3 die originalen alten runden HM-CFG-LAN mit Firmware: 0.965

Michael

[jmaus]

Also beschränkt sich das problem momentan auf die alten HM-CFG-LAN Gateways wie es aussieht.

[Ukle]

Dann gibt es doch immerhin einen Ansatz für diese Fehler, evtl. HM-CFG-LAN als die Ursache. Diesen hatte ich übrigens auch mal kurz im Einsatz und wurde wegen diverser Probleme bei mir wieder ausgemustert.

Ich kenne diese Alarme überhaupt nicht, es sei denn, meine Fritzbox fällt mal wegen Firmware-Upgrades länger aus (z.B. gestern beim Upgrade auf 07.25).
Meine LAN-Gateways bestehen aus Pi2 mit RaspberryMatic und einem Pi HM-MOD-RPI-PCB als LGW umgebaut und meiner alten CCU2, die zur HM-LGW-O-TW-W-EU umgewandelt wurde.

Alle meine Geräte und Zentralen sowie LAN-Gateways und HMIP-HAPs beziehen seit Jahren ihre IPs per DHCP von der Fritzbox mit der Reservierung für die jeweilige Adresse und das funktioniert einwandfrei und ohne Probleme.
Eine feste IP-Vergabe am Endgerät ist mir zu unflexibel und da habe ich nicht genug Übersicht im LAN und kann bei Auffälligkeiten nicht remote klären - Geschmackssache meinerseits

[Ban]

Also beschränkt sich das problem momentan auf die alten HM-CFG-LAN Gateways wie es aussieht.

Das stimmt, könnte eine Richtung sein.
Im anderen Thread waren auch zwei, die das Problem haben.

@virgin
@Dragonfly
(werden die beiden so informiert?)

Welche Hardeware verwendet ihr als HM-Lan-Gateway?

[virgin]

Ich habe mir jetzt mal eine Alarmierung eingerichtet, wenn der Duty Cycle des FLGW bei -1 steht. Grund: das FLGW wurde mehr abgehängt.

Ergebnis: ich hatte bisher zwei Alarme. Offenbar hat sich das FLGW aber in beiden Fällen wieder selbst neu verbunden.

Davor wurde es als nicht verbunden gezeigt. Der Neustart des RFD führte aber nicht dazu, dass sich das FLGW wieder neu verbunden hat. Nach einem Neustart der RaspberryMatic (Dezember Version) war es dann wieder verbunden.

Ich verstehe dieses inkonsistente Verhalten nicht und suche nach dem Schüssel? Was könnte ich testen, um dazu beizutragen, dass wir dieses Problem mit den FLGW in den Griff bekommen?

[virgin]

Also beschränkt sich das problem momentan auf die alten HM-CFG-LAN Gateways wie es aussieht.

Das stimmt, könnte eine Richtung sein.
Im anderen Thread waren auch zwei, die das Problem haben.

@virgin
@Dragonfly
(werden die beiden so informiert?)

Welche Hardeware verwendet ihr als HM-Lan-Gateway?

Bei mir sind es zwei FLGW mit mit der Firmware Version 1.4.1. wobei ich mich gerade frage, was die „alten“ FLGW sind?

<<<<Nein, es sind nicht die alten runden, sondern die viereckigen, die wie eine CCU aussehen>>>>>

Allerdings habe ich auch eine alte CCU2 zum FLGW umgebaut, die dieses Verhalten bisher nicht gezeigt hat. Könnte das ein Ansatz sein? Ich habe noch eine weitere alte CCU2 und könnte diese ebenfalls „umbauen‘, um dann zu testen, ob dort auch die Fehler auftreten.

[roe1974]

Man könnte z.B. die LGW Überwachung aus der "UpdateDCVars.tcl" ausgliedern in ein eigenes Script (z.B. "StatusLGWs.tcl"), und das nur alle 5min laufen lassen. Ich denke ein Zeitfenster von 5min ist aussagkräftig genug. Wenn da ein LGW von der "Bildfläche" verschwindet und für den RFD nicht mehr auftaucht, dann stimmt wirklich etwas nicht. Einen check jede Minute halte ich persönlich für zu "engmaschig".
Bei mir hängt das LGW zB. via VPN Tunnel im Netzwerk, da gab/gibt es regelmässig "Aussetzer" die ich aber (in den Versionen davor) gar nicht mitbekommen habe (Bei mir hängen keine Geräte dahinter die regelmässig senden).
Nur ein Vorschlag von mir
lg Richard

[virgin]

Man könnte z.B. die LGW Überwachung aus der "UpdateDCVars.tcl" ausgliedern in ein eigenes Script (z.B. "StatusLGWs.tcl"), und das nur alle 5min laufen lassen. Ich denke ein Zeitfenster von 5min ist aussagkräftig genug. Wenn da ein LGW von der "Bildfläche" verschwindet und für den RFD nicht mehr auftaucht, dann stimmt wirklich etwas nicht. Einen check jede Minute halte ich persönlich für zu "engmaschig".
Bei mir hängt das LGW zB. via VPN Tunnel im Netzwerk, da gab/gibt es regelmässig "Aussetzer" die ich aber (in den Versionen davor) gar nicht mitbekommen habe (Bei mir hängen keine Geräte dahinter die regelmässig senden).
Nur ein Vorschlag von mir
lg Richard

Ich verstehe leider nur Bahnhof. Wo sind die beiden tcl Scripte? Alle 5 Minuten? Ich brauche ein bisschen mehr Erklärung und Nachhilfe! Danke