rfxcom - No response received from transceiver

After reading that the release for 2.0 is scheduled for January (yay!) I thought I should report this again even though it looks like a duplicate #1239, but the title in that issue is misleading. This happens for me after that I turn on/off ~10 lights directly after a reboot of the server, no files changed.

2016-12-25 22:08:56.831 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@335dfdc' takes more than 5000ms.
2016-12-25 22:08:56.831 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'rfxcom:lighting2:rfxtrx433:817630462_1' takes more than 5000ms for processing event
2016-12-25 22:08:57.265 [WARN ] [g.rfxcom.handler.RFXComBridgeHandler] - No response received from transceiver
2016-12-25 22:09:02.273 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@335dfdc' takes more than 5000ms.
2016-12-25 22:09:02.274 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'rfxcom:lighting2:rfxtrx433:79432958_0' takes more than 5000ms for processing event
2016-12-25 22:09:03.053 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@335dfdc' takes more than 5000ms.
2016-12-25 22:09:03.053 [WARN ] [ome.core.thing.internal.ThingManager] - Handler for thing 'rfxcom:lighting2:rfxtrx433:1690045694_9' takes more than 5000ms for processing event
2016-12-25 22:09:03.057 [WARN ] [g.rfxcom.handler.RFXComBridgeHandler] - No response received from transceiver

[mjagdis]

Ah. I see, I think. The time from transmit to ACK is normally reasonable but strictly speaking unbounded because we may be dealing with incoming messages at the same time (single freq RF isn’t full duplex). In this case we saw at least one incoming message the first time we took a TX timeout. That doesn’t account for the full delay but there may be more going on at RF than we see - a lot of these protocols like to repeat messages several times for redundancy. Anyway we took a timeout in the binding. That caused the bridge to go offline which sends all the connected things offline which stalls the core nicely. Subsequent transmits, or the reading of their ACks, are then delayed leading to more timeouts, now from the core. When we do receive a message we take it as a sign the bridge is ok and set everything back online making a bad situation even worse. Because we’re synchronized on the send method the core is effectively queuing requests, but inside its timeout-checked safe method caller so the wait time counts towards timeout too. A send timeout before we’ve really tried causes the seqno to get out of step and then we’re really dead. Yuck.

The practical upshot is that when the core gives us a message we need to just accept and queue it because we can’t guarantee to be able to handle it inside the core’s timeout. The queue has to be in the binding. We don’t even need seqnos at all since we only ever have one message in progress at once on the rfxcom.

Try this version (there’ll be a PR along shortly too):

org.openhab.binding.rfxcom-2.1.0-SNAPSHOT.zip

[AutonomousMarvin]

Thank you!!! That snapshot resolves my issues completely!

Quite often it happened to me exactly as mjagdis described, and when the commands were sent to 9 different lamps while receiving temperature info it usually takes a minute or two for it to resolve itself, while producing about 900 log entries.

Side note. I needed to do “feature:install openhab-transport-serial” in Karaf to get your snapshot to work, but as I’m very new to programming (and Linux) this might just be something my system was lacking since earlier.