RaspberryMatic 3.59.6.20210911 – Neue Version

[joerg_rw]

Wie kann ich helfen?

Aufzeigen, wie sich das Problem reproduzieren lässt.
Welche Schritte sind notwendig / was muss passieren, damit der Fehler auftritt.

Ich starte mein GW willkürlich neu, ziehe den Strom ab, LAN Stecker raus-/rein, mal nur am Switch den Strom weg... nix.
Der RFD verbindet sich immer wieder korrekt neu und ich kann es leider nicht nachvollziehen.

packetloss zwischen CCU und FLGW in Groessenordnung von mindestens 1%, besser mehr, sicherstellen. Dann warten. Sonst kann man wohl nicht viel tun um diesen Fehler zu triggern, scheint ein timing / racecondition Problem zu sein, das um so haeufiger auftritt um so haeufiger ein "kritisches packet" verloren geht oder zu lange RTT hat und damit Chancen hat genau in die Zeitspanne zu fallen wo der rfd sich verschluckt

gruss
jOERG

[jp112sdl]

packetloss zwischen CCU und FLGW in Groessenordnung von mindestens 1%, besser mehr, sicherstellen. Dann warten.

Ok, danke. Klingt überschaubar.
Mal schauen ob meine alte WANem Appliance noch läuft, um das zu simulieren.

[joerg_rw]

Bitte stellen Sie Dokumentation zur Verfuegung welche Bedingungen im LAN-
Routing (multicast, broadcast, firewall-rules, ARP, was auch immer) erfuellt
sein muessen damit der HmIP-HAP korrekt mit der CCU3 verbindet.
Eine technische Beschreibung der Arbeitsweise des HmIP-HAP im Zusammenspiel
mit der CCU insbesondere auf Netzwerkprotokoll-Ebene waere sehr hilfreich und
hoch willkommen

warum sollte eq3 das offenlegen ? da gibt es keinen grund für !

Der Grund, Dokumentation bereitzustellen zu Typ von Paketen incl dest-port etc, ist eben genau der jedem Network-Admin zu erlauben selber die Firewalls richtig zu konfigurieren, zu evaluieren was "am besten an einem gemeinsamen Router" wohl im Klartext bedeuten mag, wodurch es sich begruendet und ob es evtl auch anders geht. So wie eQ-3 derzeit seine HAPs bewirbt muessen sie absolut damit rechen dass man ihnen das Zeug zurueckschickt und das Geld zurueckverlangt weil sie wesentliche Angaben zur Kompatibilitaet und Systemvoraussetzungen nicht gemacht haben. Mein Kunde hat genau das getan.

NORMAL gehoeren solche Angaben wie "nur im selben Subnetz" als absolutes Minimum auf die Verpackung und in die Webpage mit der Produktwerbung! Und von einer Firma die praezisere fuer Techniker nuetzliche Angaben macht kaufe ich natuerlich viel lieber. Insofern hat eQ-3 die selbe Motivation solche Dokumentation zur Verfuegung zu stellen, die sie auch dazu brachte OCCU "ueber'n Zaun zu werfen"

Gruss
jOERG

[joerg_rw]

Ok, danke. Klingt überschaubar.

Als Anhaltspunkt:

jr@saturn:~> for ((i=30; i>0; i-- )); do accu sh -c 'date; c="-q -c1 -W1"; time 2>&1 -f %E sh -c " while ping $c 192.168.178.22 && ping $c 192.168.178.1 && ping $c 8.8.8.8 && ping $c 192.168.111.1 && ping $c 192.168.111.21; do sleep 0.9; done|tail -n2 "; date' | /usr/bin/paste - - - - -; done
# nun mit ping auf 1260E 192.168.178.22
Wed Sep 29 22:37:31 CEST 2021 --- 192.168.178.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 1m 8.87s Wed Sep 29 22:38:40 CEST 2021
Wed Sep 29 22:38:50 CEST 2021 --- 192.168.178.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 7m 55.27s Wed Sep 29 22:46:46 CEST 2021
Wed Sep 29 22:46:52 CEST 2021 --- 192.168.178.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 23m 38.26s Wed Sep 29 23:10:30 CEST 2021
Wed Sep 29 23:10:34 CEST 2021 --- 192.168.178.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 5m 57.44s Wed Sep 29 23:16:31 CEST 2021
Wed Sep 29 23:16:37 CEST 2021 --- 192.168.111.21 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 3m 28.60s Wed Sep 29 23:20:06 CEST 2021
Wed Sep 29 23:20:12 CEST 2021 --- 192.168.178.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 10m 55.37s Wed Sep 29 23:31:07 CEST 2021
Wed Sep 29 23:31:13 CEST 2021 --- 192.168.111.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 5m 51.76s Wed Sep 29 23:37:05 CEST 2021
Wed Sep 29 23:37:06 CEST 2021 --- 192.168.178.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 3m 33.64s Wed Sep 29 23:40:40 CEST 2021
Wed Sep 29 23:40:45 CEST 2021 --- 192.168.178.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss 9m 57.02s Wed Sep 29 23:50:42 CEST 2021

pings entlang der route ueber ein offenbar sehr wackeliges Powerline (192.168.178.22), zwei fritzboxen (192.168.178.1 & 192.168.111.1) mit auch nicht ganz solidem VPN dazwischen, zum FLGW 192.168.111.21 - ergibt hier so etwa mal ein bis zwei Fehler pro Woche

Als wir 1 bis 2 Fehler / Tag hatten lagen die Pingzeiten (also Zeit bis packetloss) fuer obigen test in der Groessenordnung 5s, also geschaetzt 20% loss


Im Fehlerfall fand ich immer ne stale (kein process) connection:

Code: Alles auswählen

root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        0      0 192.168.178.40:53172    192.168.111.21:2000     ESTABLISHED -

im Gegensatz zum normalen

Code: Alles auswählen

root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        6      0 192.168.178.40:38542    192.168.111.21:2001     ESTABLISHED 12570/rfd
tcp        0      0 192.168.178.40:48902    192.168.111.21:2000     ESTABLISHED 12570/rfd

Code: Alles auswählen

jr@saturn:~> date; time accu; date
Wed Oct  6 01:08:27 CEST 2021
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        0      0 192.168.178.40:39820    192.168.111.21:2000     ESTABLISHED -
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        0      0 192.168.178.40:39820    192.168.111.21:2000     ESTABLISHED -
root@ccu3-webui:~# monit restart rfd
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        0      0 192.168.178.40:39820    192.168.111.21:2000     TIME_WAIT   -
tcp        0      0 192.168.178.40:60230    192.168.111.21:2000     ESTABLISHED 24165/rfd
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        6      0 192.168.178.40:49870    192.168.111.21:2001     ESTABLISHED 24165/rfd
tcp        0      0 192.168.178.40:39820    192.168.111.21:2000     TIME_WAIT   -
tcp        0      0 192.168.178.40:60230    192.168.111.21:2000     ESTABLISHED 24165/rfd
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        6      0 192.168.178.40:49870    192.168.111.21:2001     ESTABLISHED 24165/rfd
tcp        0      0 192.168.178.40:39820    192.168.111.21:2000     TIME_WAIT   -
tcp        0      0 192.168.178.40:60230    192.168.111.21:2000     ESTABLISHED 24165/rfd
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        6      0 192.168.178.40:49870    192.168.111.21:2001     ESTABLISHED 24165/rfd
tcp        0      0 192.168.178.40:39820    192.168.111.21:2000     TIME_WAIT   -
tcp        0      0 192.168.178.40:60230    192.168.111.21:2000     ESTABLISHED 24165/rfd
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        0      5 192.168.178.40:49870    192.168.111.21:2001     ESTABLISHED 24165/rfd
tcp        0      0 192.168.178.40:39820    192.168.111.21:2000     TIME_WAIT   -
tcp        0      0 192.168.178.40:60230    192.168.111.21:2000     ESTABLISHED 24165/rfd
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        6      0 192.168.178.40:49870    192.168.111.21:2001     ESTABLISHED 24165/rfd
tcp        0      0 192.168.178.40:60230    192.168.111.21:2000     ESTABLISHED 24165/rfd
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp        6      0 192.168.178.40:49870    192.168.111.21:2001     ESTABLISHED 24165/rfd
tcp        0      0 192.168.178.40:60230    192.168.111.21:2000     ESTABLISHED 24165/rfd
root@ccu3-webui:~# 

Frohes hacken
jOERG

[jmaus]

pings entlang der route ueber ein offenbar sehr wackeliges Powerline (192.168.178.22), zwei fritzboxen (192.168.178.1 & 192.168.111.1) mit auch nicht ganz solidem VPN dazwischen, zum FLGW 192.168.111.21 - ergibt hier so etwa mal ein bis zwei Fehler pro Woche

Als wir 1 bis 2 Fehler / Tag hatten lagen die Pingzeiten (also Zeit bis packetloss) fuer obigen test in der Groessenordnung 5s, also geschaetzt 20% loss

Öhmm, mal abgesehen davon das der rfd natürlich in der Tat unter diesen Bedingungen trotzdem nicht abschmieren darf würde ich trotzdem gerne wissen was dich dazu bewegt zu glauben das mit solch einer Netzwerkkonstellation (Powerline, site-to-site VPN, etc.) die LAN-Gateway Funktionalität problemlos funktionieren sollte. Es ist eigentlich weitläufig bekannt, das - wenn man denn unbedingt ein LAN Gateway braucht (was zu vermeiden gehört!) - dieser in einem stabilen LAN betrieben werden sollte, kein WLAN, kein wackeliges Powerline, etc. etc. Da sind die Laufzeiten einfach mitunter viel zu groß für die mitunter recht zeitkritische Kommunikation mit den jeweiligen HomeMatic Geräten.

[joerg_rw]

wissen was dich dazu bewegt zu glauben

Tue ich nicht, also falsche Frage, ich weiss nicht wie antworten

Es ist eigentlich weitläufig bekannt

Das dachte sich eQ-3 offenbar auch, sonst haetten sie das wohl auf den Karton ihrer FLGWs geschrieben, aehnlich wie der fehlende Hinweis "nur im gleichen Subnetz" auf dem Karton der HAPs. Im Ernst, wieso solte das "allgemein bekannt" sein? Wo steht das in irgendeinem FAQ oder Anleitung oder so?

Ich weiss dass ich moeglicherweise etwas voreingenommen bin bei dem Thema da ich beruflich aus dem Bereich CIM / Feldbusse fuer die Fertigungsautomatisierung komme (unter anderem), aber an sich scheint mir dass da am Design des Protokolls was nicht stimmt wenn das sogar derart timing-empfindlich ist. Aber die max 80ms RTT auf der Anlage des Kunden hat das FLGW bisher gut weggesteckt solange nicht mal wieder die packet Verluste dazwischenfunkten.

Code: Alles auswählen

64 bytes from 192.168.111.21: seq=96 ttl=126 time=23.401 ms
64 bytes from 192.168.111.21: seq=97 ttl=126 time=23.374 ms
64 bytes from 192.168.111.21: seq=98 ttl=126 time=24.175 ms
64 bytes from 192.168.111.21: seq=99 ttl=126 time=36.804 ms

--- 192.168.111.21 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 19.582/23.973/36.804 ms
root@ccu3-webui:~# 

Ab welchem RTT/jitter/wasauchimmer ist denn allgemein bekannt dass das FLGW den Dienst versagt? Das einzige wo ich im ganzen homematic (mal abgesehen von so Sachen wie Triac-Ansteuerung in Dimmern etc) was Zeitkritisches sehen kann ist die Steuerung der beiden MCU-GPIOs die auf die TX/RX-lines zum CC1101 gehen. Und da das FLGW offenbar seinen eigenen MCU Gueteklasse CCU2 eingebaut hat sollte es ein leichtes sein diese Steuerung lokal in realtime abzuwickeln ohne sich von zu hoehen oder schwankenden RTTs auf dem LAN stoeren zu lassen

Von PowerLine kann ich nur dringend abraten

[Xel66]

Im Ernst, wieso solte das "allgemein bekannt" sein? Wo steht das in irgendeinem FAQ oder Anleitung oder so?

Nun ja, das ergibt sich m.E. einfach aus dem vorgesehenen Einsatzbereich und der darin im Normalfall anzutreffenden Infrastruktur. Und das ist im Falle Homematic eben der Einzelhaushalt mit einem Router als zentrale Netzwerkverwaltungskomponente. Hier ist iP-Range-übergreifendes Routing mehrere Subnetze eher nicht der Standardanwendungsfall. Ich glaube auch nicht, dass in der Produktbeschreibung eines Sportwagens der Hinweis steht, dass der Einsatz im schweren Gelände oder als (von der Motorleistung durchaus geeignete) Zugmaschine für landwirtschaftliche Geräte ungeeignet ist.

Von PowerLine kann ich nur dringend abraten

Dem kann ich mich nur anschließen.

Gruß Xel66

[jp112sdl]

Und da das FLGW offenbar seinen eigenen MCU Gueteklasse CCU2 eingebaut hat sollte es ein leichtes sein diese Steuerung lokal in realtime abzuwickeln ohne sich von zu hoehen oder schwankenden RTTs auf dem LAN stoeren zu lassen

Das GW macht aber nix lokal. Es leitet nur die Funk-Pakete weiter an den RF-Daemon der Zentrale.
Wie sollte es auch anders gehen... sonst müsste auf dem GW die komplette Logik der "Hauptzentrale" parallel laufen, um Programme abzuarbeiten, etc?

Zeitkritisches

ist HM Funk nun generell, da der Sender bei bidirektionaler Kommunikation innerhalb von 250ms die Quittung erwartet.

aber an sich scheint mir dass da am Design des Protokolls was nicht stimmt wenn das sogar derart timing-empfindlich ist.

BidCos halte ich da schon für sehr umgänglich.
Normalerweise ist die Quittung in ~125ms durch. Da ist ein Timeout von knapp 250ms schon recht großzügig.

[roe1974]

Also ich betreibe ein LGW über einen LTE Router - OVPN Tunnel (Site to Site) zu meinem Home Router - seit 2 Jahren ohne Probleme.
Ich merke den Watchdog nur, wenn der LTE Router einen "link down" oder "reconnect" macht ... ab und zu halt ...
Am LGW hängen 8 Geräte. IP/Subnet ist unterschiedlich zum Home Network.

lg Richard

[joerg_rw]

Das GW macht aber nix lokal. Es leitet nur die Funk-Pakete weiter an den RF-Daemon der Zentrale.
[...]

Zeitkritisches

ist HM Funk nun generell, da der Sender bei bidirektionaler Kommunikation innerhalb von 250ms die Quittung erwartet.

Klasse Info, tausend Dank. Ich wuenschte eQ-3 wuerde sich so spezifisch aeussern

Bezueglich "Nur Funk-Pakete weiterleiten" waere das ja nicht im engeren Sinne zeitkritisch solange man nicht entweder a) Bit fuer Bit sendet anstatt sie erstmal mit lokal erzeugten 9600bd(oderso) zu bytes und packets zu aggregieren, oder b) eben wie von dir oben beschrieben ein timeout fuer die Quittung existiert. 250ms ist schon eng, bei schlechter Netzwerk-Verbindung (auch sowas wie wireless-Internet) kann man da in Probleme geraten, irgendwie hab ich das ungute Gefuehl sogar die Zentrale selbst hat gelegentlich ne Reaktionszeit auf Signals die durchaus in diese Groessenordnung kommt.
Was mag wohl degegen gesprochen haben dass das sendende device seinen RX nach dem Senden irgendwas 2 oder 5s statt 0.25s anlaesst um die quittung zu empfangen? Klar kostet das ein klein Bisschen Strom im Sonderfall dass die Quittung mal laenger braucht (sonst schaltet man den Receiver natuerlich sofort nach Empfang der Quittung ab), aber manche Geraete haben ihren Empfaenger doch "staendig" (evtl mit 20:1 dutycycle) in Betrieb. Wandthermostat z.B explizit sobald man Fensterkontakte anlernt

Gruss
jOERG