Hello,
as there don’t seem to be many LCN users in the german openhabforum.de where I have already asked for help on this topic ([LCN] OH3 empfängt nach einiger Zeit keine Statusmeldungen mehr? - openhabforum.de), I am looking for assistance here now.
OH3 runs on a Raspberry 4B. In addition to the LCN binding I have a deCONZ/conbee to manage some motion sensors, lamps and humidity sensors.
Generally the LCN binding works: modules have been auto discovered, outputs can be set via OH, binary sensor states appear in the OH logs and rules react on those state changes.
But after a certain time (sometimes a few minutes, sometimes hours, sometimes a few days) the following warnings appear in the logs and no status messages of the modules come in any more.
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 triesIn this state it is still possible e. g. to set the outputs of a module, but lacking the status feedback.
On the LCN side, i. e. in the bus log (LCN-Pro and LinHK), the said modules are still sending status messages – only OH has ceased to receive them.
I can remedy this state by disabling/enabling the PCK gateway Thing – until, after some time, the said warnings reappear.
Increasing the ‘connection timeout’ from 3s to 5s or 15s in the PCK gateway Thing doesn’t change the behaviour.
In the original post in the german forum I wondered about one module sending status messages containing a ‘4’ in the module name, which I suspected to be a possible reason for the LCN binding to not correctly interpret the status message.
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'This was due to setting status messages to ‘global’ in the property settings of this very module (LCN-Pro); ‘global’ messages are sent to the special segment ‘4’.
But resetting this setting back to ‘local’ didn’t change the issue.
My LCN modules are older ones with firmware versions 13 and 14.
In the german bus-profi forum I found a discussion (Feb. 2016, OH1 or OH2?) about delayed forwarding of (dimming) commands to the LCN bus.
The LCN binding was suspected (and criticised) to work based on acknowledge messages (Quittungsmeldungen), i. e. every command sent to the bus requesting an acknowledgement.
The problem being that these acknowledge (ack) messages cannot be ascribed to a specific command (as they do not contain any reference to the command that caused the ack message).
Furthermore the loss of such ack messages (e. g. due to bus collisions) or the fact(?) that no ack and status messages are sent, if a command does not cause a change of a module’s state (e. g. output or relay state) – if not adequately handled in the binding – could lead to unnecessary resending of commands or being caught in timeouts (waiting for ack messages).
In the case of missing ack messages the binding repeatedly sends the same commands to the bus, while increasing the timeouts between two commands.
Subsequent commands being queued during these timeouts, the user has the impression of a blocked/irresponsive system. (This could e. g. happen when slowly moving a dimming slider and the binding repeatedly sending identical commands, that are not acknowledged, as no state changes…).
It was suggested to rather rely on status messages (and track intended changes of an output or relay) instead of waiting for unspecific ack messages.
I don’t know if these assumptions of working principles (still) hold true for the current LCN binding, but there might be a relation to the issue of missing status messages described above?
Could it be that a module is ‘switched off’ in a certain way by the binding, after a number of timeouts?
(NB: the module is still sending status messages (cf. LCN bus log); after disable/enable of the gateway Thing the module’s status messages are ‘live’ again.)
Best,
Jo.
