Problem beim HmIP-WRC2 mit neuer Firmware 1.18.2

[Baxxy]

Ja, das ist default.
Hatte ich gestern extra nochmal geprüft indem ich den WRC2 mit FW: 1.18.2 frisch angelernt hatte.

Advance-Routing (HAP's als LAN-Router im System) aktiv?
DV's mit dem WRC2 aktiv?
WRC2 als Programmtrigger aktiv? ("ReportValueUsage")

Mich wundert halt das ich das hier nicht sehe und es laut Meldungen nur "bei einigen WRC2" auftritt.

[deimos]

Hi,

nein, nein, ja

Ich werde übers lange Wochenende mal probieren, ob ein Neustart oder ein aktivieren und deaktivieren der zyklischen Nachrichten etwas bringt, vorher komme ich leider nicht dazu und in meiner Installation ist das Problem im Moment eher kosmetischer Natur.

Viele Grüße
Alex

[jp112sdl]

Vielleicht "Sehr wahrscheinlich" bis "relativ sicher" haben die beiden neuen MAINTENANCE Parameter was damit zu tun.

[Baxxy]

Ich würde ja dran rumfummeln, nur habe ich (bisher) kein "UNREACH" - Problem.

[Stefan_Kunze]

...und in meiner Installation ist das Problem im Moment eher kosmetischer Natur...

Diesbezüglich kann ich deimos zustimmen. Es ist, um ehrlich zu sein, im Moment nur ein kosmetisches Problem. Der Schalter schaltet die Rollläden bzw. das Deckenlicht ohne Probleme. Es blinkt am Charly halt nur die gelbe Lampe und in der WebUI gibt's zwei Servicemeldungen.

[Bembi]

Mir ist immer noch nicht klar was Direktverknüpfungen (vom/zum WRC2) mit der "Gerätekommunikation gestört" - Meldung der Zentrale zu tun haben sollen.
M.E. absolut nichts.

Also in der Zwischenzeit habe ich aufgegeben, die eQ3 Logik bis ins Detail verstehen zu wollen. Orientiere mich da weitgehend an den Methoden, die üblicherweise zum Ziel führen. In der Vergangenheit ist mir aber schon mal aufgefallen, dass bei einzelnen Sensoren neu hinzugefügte Kanäle dazu führten, das diese nicht mehr sauber kommunizierten. Meist blieben die dann aber mit einem config_pending hängen.

Die Updates führen natürlich erst einmal zu einem hohen Duty Cycle. Das kann natürlich nach dem Update erst mal zu Kommunikationsproblemen führen. In der Vergangenheit ist mir das bei den Fenstersensoren schon mal aufgefallen. Da reichte aber ein Fenster auf / Fenster zu, damit die Sensoren einfach eine Rückmeldung geben. Da die WRC2 ja nicht zyklisch zurückmelden, kann es durchaus sein, dass es recht lange dauert, bis die CCU den Geräte-Status bekommt. Und die CCU speichert ja wohl eine Kopie der Konfig.

Ich hab nun mal über devconfig geguckt, was die WRC2 sagen. Da habe ich auch ein Unreach gesehen, aber auch config_pending. Das war nicht immer identisch mit der Statusanzeige. Interessanterweise konnte ich aber die Konfiguration ändern, trotz gesetzten config_pending. In anderen Fällen hatte ich heute auch die Situation, dass es gut 10-15 Minuten gedauert hat, bis eine Konfig-Änderung an den WRC2 übermittelt wurde.

Die gute Nachricht: Direktverbindungen konnte ich setzten. Funktionieren auch. Zumindest wenn der Duty-Cycle niedrig war.
Die schlechte Nachricht: Da ad hoc läßt sich das Problem im Moment mit den Standard-Procedere nicht lösen. Die unreach Meldungen verschwinden offenbar nach einer Zeit von allein, wenn man das System in Ruhe läßt. Bei meiner Herumklickerei tauchten sie aber schnell wieder auf.
Ein generelles Kommunikationsproblem schließe ich aus, alle meine WRC2 zusammen mit WTH2 verbaut sind, und keiner meiner WTH2 zeigt irgendein Problem.
Das deutet irgendwie darauf hin, das die Firmware ein Kommunikationsproblem hat. Da die Meldungen mit höherem Duty-Cycle zunehmen, vermute ich in dieser Ecke ein Problem.

[andrzejgilas]

Ich habe zwei HmIP-WRC2-Geräte, das Update war erfolgreich (ich musste nur ein paar Mal auf den Button in wrc2 klicken)
Nach dem Update gab es keine Meldungen über gestörte Kommunikation


Einstellungen:

[Stefan_Kunze]

Meine beiden "Problembären" sind wieder da, d.h. auf Gelb ("Gerätekommunikation gestört")

Vielen Dank Bembi für die detailreiche Analyse und Beschreibung.

...Bei meiner Herumklickerei tauchten sie aber schnell wieder auf....

Also wenn ich den letzten Tag nehme, passiert auf den Schaltern nicht wirklich viel. Rollläden früh hoch und abends runter. Der Lichtschalter wurde gestern überhaupt nicht betätigt, wenn ich mich recht entsinne.

[Xel66]

Also in der Zwischenzeit habe ich aufgegeben, die eQ3 Logik bis ins Detail verstehen zu wollen.

Wenn man aber erfolgreich Automationen damit anlegen will, dann ist das aber zwingend notwendig. Ansonsten wird das Ergebnis häufiger überraschend ausfallen.

Meist blieben die dann aber mit einem config_pending hängen.

Logisch. Die Konfiguration muss erst mal an den Sensor übertragen werden. Gerade batteriebetriebene Sensoren holen ggf. ihre Daten nur nach zylischen Meldungen, nach Betätigung des Anlernbuttons oder nach erkannten Ereignissen ab. Manchmal ist die Betätigung des Anlernknopfes auch zwingend notwendig (gerade bei älteren Geräten).

Die Updates führen natürlich erst einmal zu einem hohen Duty Cycle.

Logisch, wenn Updates über die Funkschnittstelle verteilt werden, zählt das zur "verbrauchten" Funkzeit. Alles andere wäre unlogisch und nicht gemäß der Grundlagen, die für die Nutzung dieser Funkfrequenz gelten.

Und die CCU speichert ja wohl eine Kopie der Konfig.

Ja, und die lässt sich (z.B. nach einem lokalen Werksreset) auch wieder auf das Gerät zurückspielen.

Interessanterweise konnte ich aber die Konfiguration ändern, trotz gesetzten config_pending.

Du änderst ja auch nur die auf der CCU gespeicherten Einstellungen, die dann bei Gelegenheit an das jeweilige Gerät übertragen werden.

Direktverbindungen konnte ich setzten. Funktionieren auch. Zumindest wenn der Duty-Cycle niedrig war.

DVs habe mit dem Duty Cycle der CCU rein gar nichts zu tun. Nur bei hohem CS können auch diese beeinträchtigt sein. Dann ist eben die Frequenz "gestört" (belegt) und das wirkt sich auf "alle" Geräte aus (nur HmIP-Geräte überwachen den CS).

Die unreach Meldungen verschwinden offenbar nach einer Zeit von allein, wenn man das System in Ruhe läßt.

Oder eben nach Durchführung der in den Anleitungen beschriebenen "Prozedur" (Betätigung des Anlernkopfes des jeweiligen Gerätes).

Bei meiner Herumklickerei tauchten sie aber schnell wieder auf.

Dann hast Du die Konfiguration geändert oder Sensoren erstmalig in einem Programm verwendet. Soweit Standard.

Ein generelles Kommunikationsproblem schließe ich aus...

Entsprechend Deiner Beschreibung würde ich auch eher auf PEBKAC tippen.

Da die Meldungen mit höherem Duty-Cycle zunehmen, vermute ich in dieser Ecke ein Problem.

Ist eher ein Problem mit dem Verständnis der Funktionsweise der Kommunikation und der Eigenheiten des Systems.

Gruß Xel66

[dtp]

Ich habe das Problem der Servicemeldungen nach erfolgreich durchgeführtem Update auch. Sie kommen auch immer wieder, wenn man die Kommunikationsstörungen durch Drücken der Anlerntaste am Taster beseitigt hat.