[LCN] OH3 empfängt nach einiger Zeit keine Statusmeldungen mehr?

[cerise]

Hallo,

bin neu hier und hoffe, einige 'Exemplare' der seltenen Spezies 'OH/Lcn-Nutzer' anzutreffen, die mich ggf. auch noch in die richtige Richtung weisen können...
In der Vergangenheit hatte ich OH1 und OH2 mal getestet und wollte es jetzt ernsthaft mit OH3 und Lcn nochmals versuchen, da ich an mehreren Stellen gelesen hatte, dass das Binding problemlos funktioniert.
OH3 läuft auf Rasbberry 4B, der über deCONZ/conbee ein Zigbee-Netz verwaltet.
Jetzt wollte ich einige Lcn-BMI (Bewegungsmelder) und -Modulausgänge über das Lcn-Binding in die Automatisierung einbinden.
Prinzipiell funktioniert das; die Module werden erkannt und die entsprechenden Binärsensor- und Ausgangs-Channels sind mit Items verlinkt. Rules, die auf die Binärsensoren reagieren sollen, tun dies auch – zumindest eine gewisse Zeit lang; bis irgendwann keine Statusmeldungen der Module mehr anzukommen scheinen. Die Zeit, bis dies eintritt, variiert von einigen zehn Minuten über einige Stunden bis zu ein-zwei Tagen; länger bestand die Verbindung aber nie.
In diesem Zustand lassen sich z. B. Ausgänge der Module noch via OH schalten, allerdings ohne Statusrückmeldung.
Im Lcn-Busprotokoll (LinHK) sind die Statusmeldungen der Binärsensoren (BMI) weiterhin sichtbar und Lcn-seitig funktionieren die Bewegungsmelder.
Im OH-Log tauchen folgende Warnmeldungen auf:

Code: Alles auswählen

2022-11-15 21:40:26.397 [WARN ] [ding.lcn.internal.connection.ModInfo] - S000M008: Module did not respond to command: A1DI000000
2022-11-15 21:46:51.715 [WARN ] [ding.lcn.internal.connection.ModInfo] - S000M009: Failed to receive status message: Binary Sensors: Failed finally after 3 tries
2022-11-15 21:47:25.750 [WARN ] [ding.lcn.internal.connection.ModInfo] - S000M008: Failed to receive status message: Output 1: Failed finally after 3 tries

Beheben kann ich diesen Zustand (für eine gewisse Zeit), wenn ich das pck-Gateway-Thing kurz deaktiviere und wieder aktiviere.
Eine Erhöhung des 'Connection Timeout' von 3s auf 5s oder 15s im pck-Gateway-Thing brachte keine Aenderung.
Gewundert habe ich mich über folgende Statusmeldung:

Code: Alles auswählen

2022-11-15 22:11:18.128 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M004009Bx008'
2022-11-15 22:11:23.631 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M004009Bx000'

Ich verstehe nicht, weshalb sich das Modul 9 statt mit ':M000009Bx...' mit der ':M0004009Bx...' im Busprotokoll meldet. Könnte es sein, dass OH deshalb die Statusmeldung nicht dem richtigen Modul zuordnen kann?
Andere Module melden sich ohne diese ominöse '4', OH erhält von diesen dann aber auch keine Statusmeldungen mehr:

Code: Alles auswählen

2022-11-02 13:28:58.176 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M000014Bx008'
2022-11-02 13:28:58.536 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M000015Rx128'
2022-11-02 13:28:59.118 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M000013Bx008'
2022-11-02 13:28:59.535 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M000015Rx128'
2022-11-02 13:29:00.526 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M000013Bx000'
2022-11-02 13:29:01.067 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M004009Bx008'
2022-11-02 13:29:01.535 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M000015Rx128'
2022-11-02 13:29:05.586 [TRACE] [g.lcn.internal.connection.Connection] - Received: ':M000014Bx000'

Die Lcn-Module sind schon etwas älter und haben 13er oder 14er Firmware-Versionen.

Hat jemand vielleicht einen Hinweis, in welche Richtung ich weiter suchen, bzw. was hier das Problem sein könnte?

Danke und schöne Grüße,
Jo.

[mad-mike]

Moin.

Ich habe einen Bekannten der nützt auch LCN. Habe dort auch openhab am laufen.

Die Verbindung läuft über den PKU weiter auf PCHK (GVS Server) dann zum openhab Binding.

Die GVS wollen wir abschalten und die Verbindung nun direkt mit dem PI herstellen.

Grundsätzlich funktioniert die aktuelle Verbindung soweit ganz gut- bis die GVS eine Verbindung schließt warum auch immer.

Ich kenne dies LinHK nicht aber kann's vielleicht auch an diesem liegen ?

Ich muss aber sagen, das wir bei meinem Bekannten die Bewegungs Melder direkt mit dem LCN pro auf die jeweiligen Aktoren verknüpft haben. Und keine rule am laufen, das da was auffallen könnte

[cerise]

Danke für Deinen Beitrag.
Meine Buskopplung hier läuft noch über einen alten PK mit Seriell/USB-Adapter.
LinHK ist eine Software für Linux, läuft auf einem Raspberry und dient u. a. als PCHK-Ersatz.
Die Ursache für das o. g. Problem würde ich erst mal nicht bei der LinHK vermuten, aber man weiss ja nie…
Ich werde mal im bus-profi-Forum (da kommt die LinHK her) fragen, ob jemand weiss, weshalb die Binärsensor-Statusmeldung so komisch aussieht.

[cerise]

Zumindest das mir unbekannte Format der Statusmeldungen

Ich verstehe nicht, weshalb sich das Modul 9 statt mit ':M000009Bx...' mit der ':M0004009Bx...' im Busprotokoll meldet.

hat sich jetzt geklärt.

Ich werde mal im bus-profi-Forum (da kommt die LinHK her) fragen, ob jemand weiss, weshalb die Binärsensor-Statusmeldung so komisch aussieht.

Niko, der LinHK-Entwickler, erklärte, dass die Statusmeldungen eines Moduls die '4' beinhalten, wenn das Modul seine Meldungen nicht 'lokal' an das eigene Segment schickt, sondern 'global' an das spezielle Segment '4' – diese Meldung wird dann an alle Segmente geschickt.
Ob ein Modul statt 'lokaler ' dann 'globale' Statusmeldungen versendet, wird in den Eigenschaften des Moduls (LCN-Pro) mit einem Häkchen festgelegt (dieses hatte ich wohl aus Versehen bei einem Modul gesetzt).
LCN-seitig wird die '4' richtig interpretiert, bzw. ist bei nur einem vorhandenen Segment irrelevant; ob OH dies ebenso tut, müsste ein LCN-Binding-Insider beantworten…

Nach der 'Aufklärung' habe ich die globalen Meldungen für das betroffene Modul wieder deaktiviert – das o. g. Problem mit dem Verbindungsverlust nach einiger Zeit besteht allerdings (leider) immer noch.

Bei der Suche im bus-profi-Forum bin ich auf eine Diskussion zu OH2 und verzögerter Weiterleiterleitung von (Dimm-)Befehlen in den LCN-Bus gestoßen: Dabei wurde beschrieben (und kritisiert), dass das LCN-Binding wohl quittungsbasiert arbeite, d. h. es werde mit jedem in den Bus geschickten Befehl eine Quittung angefordert. Das Problem an Quittungsmeldungen sei, dass diese prinzipbedingt nicht einem bestimmten Befehl zugeordnet werden könnten. Ausserdem könnten bei Buskollisionen Quittungen verloren gehen, bzw. auch gar nicht geschickt werden, wenn z. B. bei zwei aufeinanderfolgenden gleichen Befehlen (langsames Bewegen des Dimm-Sliders) der Zustand des Ausgangs sich nicht ändert.
Bei ausbleibenden Quittungsmeldungen sende das LCN-Binding wiederholt, in größer werdenden Abständen, die gleichen Befehle, bis zum Erreichen eines Fehler-Levels; nachfolgende Befehle müssten solange in eine Warteschlange; für den Anwender sehe es so aus, als ob der Bus während der Retries blockiert sei.
Besser wäre es wohl statt der Quittungen die Statusmeldungen der Modulausgänge, Relais und Binärsensoren auszuwerten und entsprechend auf mehrfaches Senden (gleicher) Befehle zu verzichten.

Angesichts dieser Ausführungen frage ich mich, ob das LCN-Binding ggf. wegen mehrfach ausbleibender Quittungen (oder Statusmeldungen?) 'aufgibt' und das betreffende Modul irgendwie 'abschaltet'?
Nach einem disable/enable des PCK-Gateways sind die Module ja wieder 'sichtbar'; sie sind also nicht wirklich unerreichbar…