[gelöst]Zustandsproblem mit automatischen Auschalten in Direktverknüpfung

[nseith]

Abend Gerti,
Abend Robbi,

nachdem Ihr ja versichert habt dass es bei Euch, wenn auch mit unterschiedlichen Einstellungen laeuft habe ich jetzt gerade nochmals probiert.

Ich habe einen SW12/7 mit Automatisch aus nach 5s hier in meinem Buero UM-programmiert und siehe da - Webseite stimmt.
Jetzt mal schnell die Gartenpumpe auch auf einen anderen Wert gestellt und siehe da Webseite stimmt.

Dabei festgestellt das beim Kellerlicht auf der Webseite noch das Zahnrad fuer laufende Verzoegerung zu sehen war (seit heute morgen 6.35!), wo das Licht eigentlich im Keller nach 20 min spaetestens ausgeht. Ergebnis - LIcht ist tatsaechlich aus, aber Webseite und auch Home24 APP sagen an.

Jetzt noch meinen Dimmer hier im Buero auf Nachlicht mit 5s auf 50% dann über 5s auf aus programmiert und siehe da - Zustand stimmt.

Gerade die Kinderzimmer kontrolliert - beide Dimmer stehen per Weboberflaeche mit dem Zahnrad auf dem Startdimmwert.
Die Dimmer haben alle die gleich Firmware und sitzen im gleichen Schaltschrank (Buslaenge bei mir hier sicher an der Grenze mit 150m und Sternverkabelung samt diverser UVs)

Ich programmiere die Dimmer jetzt einfach mal neu - kann ich aber erst morgen frueh testen.

Werde wieder berichten.
Danke Euch
N

[nseith]

Guten Morgen,

habe gestern wie geschrieben bei beiden Dimmern die Werte fuer die Auszeit von 5 auf 6 Minuten geaendert und gespeichert.
Heute morgen 7.41 in beiden Zimmer die Taste gedrueckt und beide Licht sind angegangen.

Das erste Zimmer stand jetzt kurz vor 8 Uhr wie immer - auf dem Startwert der Nachtlichtfunktion

Das zweite Zimmer hatte noch den Wert von gestern Abend als die Kidz ins Bett sind?!

Zyklische Statusabfrage ist an und beide Dimmer sitzen nebeneinander.
Super strange das alles

[Bembi]

Hallo Zusammen,

nur mal so ein paar Denkansätze.
Vom Grundsatz melden die Geräte ihren Zustand ja zyklisch und ggf. bei Änderung. Das bei einzelnen Geräten (insbesondere klassische HM) das nicht immer so ganz wie erwartet funktioniert, das habe ich bei einigen Scripten festgestellt. Die lösten erst gar nicht aus, wenn sie eigentlich auslösen sollten.

Bei einzelnen Geräte funktionierte das nur, wenn für die Geräte oder Kanäle die Protokollierung in der CCU aktiviert war. Wenn die Protokollierung aktiv war, wurden die Scripte getriggert, wenn sie aus war eben nicht. Also einfach mal versuchen, ob das etwas ändert.

Ich würde mich auch nicht darauf verlassen, dass eine durch eine Direktverknüpfung ausgelöste Änderung als solche auch in der CCU ankommt. Wenn es das Gerät aber nicht tut, dann bekommt die CCU das erst mit der nächsten zyklischen Meldung mit. Und wenn die CCU den Status des Gerätes nicht kennt, könnte es zu logischen Fehlern kommen (z.B. dass man doppelt triggern muss).
Und wenn sie dann ankommt, muss die Oberfläche der CCU ja noch aktualisieren, damit sie dann auch sichtbar werden.

Dass die Kommunikation an sich einwandfrei funktioniert ist natürlich immer Grund-Voraussetzung. Deshalb sollte man alles kontrollieren, was dazwischen liegt.
Im Netzwerkbereich muss erst einmal die Verkabelung einwandfrei sein. Also ggf. mal alle Kabel und Kabelstrecken (Patchfelder etc.) mit einem Kabeltester durchprüfen. Hatte gerade den Fall, in welchem ein Draht im Patchfeld schlecht verkrimpt war und deshalb zu Störungen führte. Aufgefallen ist das eigentlich deswegen, weil der Switch auf dem Port viele Fehler gemeldet hatte. Das Fehlerprotokoll von (managebaren) Switchen ist übrigens grundsätzlich eine guter Ausgangspunkt, Fehler im Netzwerk zu finden, weil da eigentlich keine Fehler sein sollten.

DHCP ist eine Ursache, aber eher temporär. Wichtig ist final, dass alle Geräte die richtige IP bekommen und diese zur MAC Adresse paßt. Ideal ist eine IP - MAC Bindung, so dass die Geräte immer die gleiche IP bekommen. Die IP - MAC Bindung verhindert auch, dass irgendein anderes Gerät diese IP Adresse jemals bekommen kann. Die IP kann man dann auch nochmal im Gerät als Default fest hinterlegen.
Die werksseitig voreingestellte Default IP-Adresse ist bei gleichen Gerätetypen oft identisch. Das könnte beim Neustart der Geräte temporär zu Störungen führen.
Bei einigen Geräten kann man die Voreinstellung nur mit NetFinder sehen bzw. ändern.

Grund für temporäre Verwirrung sind die von den meisten Geräten gehosten ARP Tabellen, mit welchen sich diese IP-Adressen und MAC Adressen merken. Ändern sich die IP-Adressen, müssen erst alle (beteiligten) Geräte diese Änderung mitbekommen, damit eine einwandfreie Funktion gewährleistet ist. In der Praxis merkt man dieses Procedere eher selten, es kommt vor, allerdings behebt sich das nach kurzer Zeit von selbst.
Ich habe nur festgestellt, dass eQ-3 Komponenten da manchmal etwas eigenwillig sind. Aber auch Switche können die Ursache sein, wenn sie eigene ARP Tabellen hosten. Zu einer dauerhaften Störung sollte das aber nicht führen.

Vergessen darf man auch nicht, dass die eQ3 Geräte viel über Broadcasts und Multicast kommunizieren. Diese dürfen nicht geblockt sein. Managebare Switche erlauben da ein Menge an Einstellungen, die sich auf Broadcasts auswirken. So sollte man IGMP Snooping unbedingt ausschalten oder wenn dann doch notwendig korrekt konfigurieren. Ansonsten kommen bestimmte Datenpakete einfach nicht an, was dann manchmal zu merkwürdigen Verhalten führt.

[nseith]

Hi Bembi,

vielen Dank fuer die super aufwendige Erklaerung und Deinen Ansatz.
Ich habe bereits das loggin aktiviert und getestet leider keinen Unterschied zu sehen, status bleibt beim Startwert.
Und bei dem Dimmer mit dem es beim Test oben dann funktioniert hat - hatte es auch aus.

Was die Switche im Haus angeht sind soweit konfiguriert sind L2+ Switche da ich manchmal Berufsbedingt etwas Multicasttraffic durchs Haus routen muss, die Homematic Sachen laufen mittlerweile im eigenen VLan. Beim ARP vermute ich auch keinen Fehler, da die IPs ja seit 10 Jahren gleich sind und die MACs sich ja natuerlich auch nicht aendern. Ist bei Homematic legacy auch die Multicast die Verbindung? Habe hier noch keinen Wireshark trace gemacht um das zu untersuchen. Verkabelung wuerde ich auch ausschliessen weil es wirklich nur diese Rueckmeldungen sind - trotz der Buslaenge von guten 100m.

Meine Installation ist wie geschrieben recht gross mit 100 Geraeten und 700+ Kanaelen, wovon alles soweit laeuft eben nur diese Timerrueckmeldungen beim Dimmer wohl etwas zickig sind. Sonst keine wirklichen Fehler zu beanstanden, auch nach fast 10 Jahren betrieb.

Ich will am WE mal meine Backup CCU und das Backup Gateway mit einem Dimmer in eine Insel packen und mal testen.

Vielen Dank fuer Eure Zeit soweit
Ich werde berichten

[nseith]

Abend Zusammen,

um es kurz zu machen - mit dem Testsystem (CCU2, Gateway, 1x wired Dimmer) hat das perfekte Ergebnis geliefert.

Dimmer auf Nachtlichtfunktion, mit 5min auf 50% ein, dann ueber 5min auf 0%.

Nach 5min - ist der Status von 50 auf 49,5% gefallen und dann dort geblieben bis er nach weiteren 5Min auf 0% ankam und die WebUI aktualisierte.

Scheint also dass ich wohl doch ein BUS Topologie Problem habe

Das wird wohl eher schwierig einzugrenzen, sobald ich mal einen Systemplan erstellt habe, werde ich einen neuen Thread aufmachen.

Danke Euch allen fuer´s mitlesen und helfen!

Werde das Thema schliessen und so erstmal Kennzeichnen.
Gruss
N