Alarmmeldung von HM-Lan ausschalten

[Ralli_]

Ich lasse diese (bei mir sehr selten vorkommenden und nicht nachvollziehbaren) Alarmmeldungen nun automatisch bestätigen:

Code: Alles auswählen

var gw_al = dom.GetObject('RF-Gateway-Alarm').AlCounter();
var wd_al = dom.GetObject('WatchDog-Alarm').AlCounter();

if (gw_al > 0) {
  dom.GetObject("RF-Gateway-Alarm").AlReceipt();
}
if (wd_al > 0) {
  dom.GetObject("WatchDog-Alarm").AlReceipt();
}

[papi]

Damit kann man sich aber schnell ins Knie schießen, wenn sie mal nicht mehr nur selten vorkommen.
Nur gut, dass Du die Verzögerung drin hast.

[katsud]

Ja, das funktioniert ob mit und ohne Verzögerung nur gut, wenn der Zustand nicht häufig auftritt. Bei mir ging das einen Tag gut, dann kam der Alarm sehr zuverlässig und exakt jede Minute. Das Protokoll läuft voll, DC steigt an und die Box ist immer ausgelastet. Man kann dann mit dem Hintergrund-Scripting etwas machen....

[mittelhessen]

Auch ich reihe mich mit einem original HM-LGW-O-TW-W-EW-2 ein. Auf dem Gateway läuft die aktuelle FW 1.4.1, auf meiner Raspberrymatic die aktuelle 3.59.6.20210703. Ob die IP des Gateways fest vergeben oder per DHCP bezogen wird, macht keinen Unterschied. Sobald die Alarmmeldung auftritt, beginnt auch die "Network"-LED am Gateway zu blinken. Das Gateway ist dennoch auch in diesem Moment zuverlässig anpingbar. Dass die Pingantwort aber kein hinreichendes Kriterium für die intakte Verbindung ist, wurde ja bereits einige Beiträge weiter vorne beantwortet.

Es wurde ja bereits berichtet, dass das Problem eher (ausschließlich?) beim original HM-LGW auftaucht und weniger (nicht?) bei der zum HM-LGW umkonfigurierten CCU2. Aus der FHEM-Wiki entnehme ich folgende Info: Es existieren zwei Revisionen dieses Geräts, HM-LGW-O-TW-W-EU und HM-LGW-O-TW-W-EU-2. Vielleicht ist es hilfreich mal zu prüfen, ob das Problem bei beiden Revisionen auftritt. Bei meinem HM-LGW-O-TW-W-EW-2 kann ich das leider bestätigen.

[virgin]

Wobei ich jetzt noch ein weiteres merkwürdiges Phänomen beobachte.

- Meine „umfunktionierte“ CCU2 ist im Lan Netzwerk plötzlich nicht mehr sichtbar bzw. zu finden.
- in der RaspberryMatic, Systemeinstellungen erscheint sie als nicht verbunden
- auf dem Startbildschirm ist sie nicht zu sehen
aaaaber sie funktioniert und ist offenbar doch verbunden.

Ich bin komplett verwirrt….

[papi]

Habe ich auch gelegentlich, starte die Dinger mal durch!

[katsud]

Wobei ich jetzt noch ein weiteres merkwürdiges Phänomen beobachte.

- Meine „umfunktionierte“ CCU2 ist im Lan Netzwerk plötzlich nicht mehr sichtbar bzw. zu finden.
- in der RaspberryMatic, Systemeinstellungen erscheint sie als nicht verbunden
- auf dem Startbildschirm ist sie nicht zu sehen
aaaaber sie funktioniert und ist offenbar doch verbunden.

Ich bin komplett verwirrt….

Das ist bei mir der "Normalzustand". Alles funktioniert, das Gateway (in meinem Fall das Original) ist nicht verbunden mit einem negativen Dutycycle(-1%), aber alles arbeitet richtig.
Abhilfe (für Minuten oder wenige Stunden) bringt nur ein kompletter Neustart der beteiligten Geräte (CCU und LAN-GW).

Solange der offensichtlich vorhandene grundsätzliche Fehler nicht beseitigt wird, ist das für mich der "Status Quo". Eben auch mit Skript-Änderung bei jedem Update der CCU (Raspmatic) Firmware.

[Daimler]

Hi,

Das ist bei mir der "Normalzustand"

Also das ist abs. nicht 'Normal'

Ich setze hier insgesamt 6 Lan-Gateways (5 Originale und ein Fake) ein und hatte nie eine diesbez. Fehlermeldung.
Allerdings alle direkt am Netz (Kein W- oder D-Lan) und piVCCU - also quasi o. CCU3-FW.

[Sat_Dad]

Hallo Zusammen,
auch ich habe den Feher seit dem letzen Update.
Konfiguration:
3* HM-LGW-O-TW-W-EU: ohne Probleme
1* HM-CFG-Lan : steigt immer wieder aus

Meine Beobachtung bis dato: wenn ich einen Dauer- Ping auf den HM-CFG-Lan absetze, dann schaukelt sich die Antwortzeit innerhalb von kurzer Zeit von anfangs ca. 200 ms auf über 2.000 ms auf, dann steigt er mit Zeitüberschreitung aus, erholt sich wieder kurz und dann von vorne.

Code: Alles auswählen

Antwort von 192.168.17.119: Bytes=32 Zeit=288ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=400ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=935ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=939ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1060ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=876ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=821ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1069ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1172ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1739ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2043ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1826ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2204ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2342ms TTL=128
Zeitüberschreitung der Anforderung.
Antwort von 192.168.17.119: Bytes=32 Zeit=827ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=780ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1324ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1386ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1568ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1715ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2156ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1908ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2400ms TTL=128
Zeitüberschreitung der Anforderung.
Antwort von 192.168.17.119: Bytes=32 Zeit=233ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=223ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=897ms TTL=128

Als ich dann, aus lauter Verzweiflung den Raspmatic neu gestartet habe waren die PingZeiten konstant bei 50- 150 ms, sobald die Zentrale wieder am Netz hing ging das Spiel von vorne los.
Irgendetwas mit der Kommunikation mit den "alten" Gateways scheint da seit dem Update nicht zu stimmen.

Vielleicht hilft das bei der Fehlereingrenzung, ich habe leider keine Ahnung wo ich denn hinschauen müsste/ könnte.

Gruß
Detlef

[condor07]

Hallo Zusammen,
auch ich habe den Feher seit dem letzen Update.
Konfiguration:
3* HM-LGW-O-TW-W-EU: ohne Probleme
1* HM-CFG-Lan : steigt immer wieder aus

...

Code: Alles auswählen

Antwort von 192.168.17.119: Bytes=32 Zeit=288ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=400ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=935ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=939ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1060ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=876ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=821ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1069ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1172ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1739ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2043ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1826ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2204ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2342ms TTL=128
Zeitüberschreitung der Anforderung.
Antwort von 192.168.17.119: Bytes=32 Zeit=827ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=780ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1324ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1386ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1568ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1715ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2156ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=1908ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=2400ms TTL=128
Zeitüberschreitung der Anforderung.
Antwort von 192.168.17.119: Bytes=32 Zeit=233ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=223ms TTL=128
Antwort von 192.168.17.119: Bytes=32 Zeit=897ms TTL=128

....

Ich würde eher sagen bei dir ist das ein Problem mit dem Netzwerk
das sind selbst in deinem frisch gebooteten Zustand "Lieferfristen"
Bei mir sind es unter < 1ms teilweise über mehrere Switche.
1.)
Ich weiß nicht ob du management fähige Switche hast wenn ja dann würde ich mir mal
den Status anschauen full/halb Duplex 10/100 mbit und Errors.

Sollte ungefähr so aussehen:

Code: Alles auswählen

GigabitEthernet1/0/20 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 00ca.e5c3.2714 (bia 00ca.e5c3.2714)
  Description: CCU-ANT-KE
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 1000 bits/sec, 2 packets/sec
     810201 packets input, 89873327 bytes, 0 no buffer
     Received 6 broadcasts (0 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     2489643 packets output, 264340442 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

2.)
Desweiteren haben die LAN-Gateways probleme mit zuviel Multicast und Broadcast Traffic auf dem Interface.
Dieser wird z.B. von Mediareceivern beim Streamen verursacht wenn der Switch das nicht sauber von den nicht benötigten interfacen fern hält (Stichwort igmp). Am besten wenn möglich die Hausautomation in ein seperates VLAN oder dedizierte Swiche aufbauen und mit dem Home/PC Netz über eine Layer3 Instanz(z.B. Router/Firewall) verbinden.
3.)
Probleme können auch z.B zwischengeschaltete Powerline Adapter sein
4.)
WLAN bridges sind auch immer ein beliebtes Problem
5.)
oder einfach mal das Anschluss Patchkabel tauschen

Sorry für ggf. etwas viel technisches geplänkel

Michael