Serial bridge stops processing messages

I have a RPi4, 4GB, with OH 3.02. Several bindings are installed with no serious issues so far (one minor with the OpenTherm, but still need to test the new release).

On the roof of my house I have a Hydreon RG-9 optical rain sensor installed and wired it to the serial port of a nodeMCU. On the RPi running Raspberry OS, socat communicates with the NodeMCU. Openhab connects to the “virtual” serial port ttySER1. So far so good.

But every few weeks communication just stops (not receiving messages). Openhab is showing the serial bridge as online, but no data is showing as being received. When I disable the bridge and enable it again (after 10 seconds or more) data is being received again, but the first data received is all the data of the period during which no data was shown in Openhab. So when the data stopped for 2 hours, the first data received at once is the data of about two hours… Which is a bummer when that data contains information if it is raining or not and the sun shades should be commanded to retract due to rain.

When all missed data comes in at once suggests that it is still buffering/caching in Openhab but the bridge does not receive it. Anyone that can direct me to prevent the serial bridge posing this behavior (or that I am blaming the binding for no reason)?

It was noted in other bindings that share the serial library that some errors would not be recovered, the serial port reconnect messes up.
There was some work on this for 3.1 I believe.

I did not yet upgrade to 3.1 yet due to one of the most important bindings for me (not official eBus binding) not being compatible yet with it. However that changed last week, so it is time to install 3.1 in a test environment to do some testing :slight_smile:

In the mean time I am trying to take a new approach towards the serial device by requesting the rain value every minute and performing a reset of the optical rain sensor every midnight. Maybe that sending a command regularly will keep the receipt of messages going.

A few weeks ago finally upgraded my system from 3.0.2 to 3.1. The eBus binding is compatible in the mean time, and opentherm no longer gives me faults (showing offline, but still being online) as it did in 3.0.2. So far I am happy. Unfortunately the serial binding still stops processing messages every few days. Sending messages from openhab with the serial binding does not help. The behavior is still the same as in the first post.

Getting back on this one (after more than three years) as it was not the serial binding or openHab causing the problem: it was just socat.

It has taken me quite a bit of trickery to get it working reasonably reliable for the rain sensor….

First I was convinced it was openHab and I even created an own binding. That seemed to work for a while, but after some time it gave me the same issues. At least I learned a bit more programming :wink:

Finally I discovered from the socat log that it sometimes ended and restarted the connection. So it was time to install the logreader binding with a channel that triggered upon detection of the connection failing. That triggers a rule to disable and reenable the Thing reading the socat port.

Unfortunately that still did not solve it fully. The rain sensor is on the roof connected to a Lolin D1 mini and espeasy installed. And being outdoor on the roof makes for some unexpected ESP reboots every now and than.

For some reason it’s not possible to forward the serial messages to mqtt with espeasy (or at least not in that older version). However the same board also has an i2c light sensor reporting to mqtt, so the ESP board is connected to my mqtt broker as well. That gave me the idea to use the last-will messages to trigger a socat restart and the disable-enable of my Thing upon receiving a LWT connect message.

Result: a reliable wireless socat information stream.

Apologies for blaming the serial binding in the first place :wink: