OH3 Exec Binding with Serial Port - Port Locking due to overlapping item reads

Add-ons Bindings
1

So this is more of an casual observation, of a potential change in behavior in OH3 with the Exec Binding (For clarity, I am not necessarily calling it an issue/bug).

I have multiple items defined which executed a C++ & python programs to read multiple values from various device via a number of serial port.

This worked pretty well under OH 1.x and OH 2.x, and read errors were extremely infrequent (almost non-existent), and never saw the port-locked/already open issue.

Following the migration to OH 3.x, I was forever getting errors thrown by the underlying program that the serial (tty) device was locked/already open. This error itself was not surprising, as the Exec binding was now trying to fire up multiple instances of the utility, for different items, as the exact same time.

An initial work-around was to carefully choose item refresh intervals which were not a product of each other. This significantly reduced the occurrence of the errors, but obviously there would be points where the item updates would still overlap.

The real question here, is if there was a change in behavior for the Exec binding in OH 3.x which could have contributed to this. The only 2 hypothesis I can envision are that the previous OH Exec bindings versions were “single-threaded” in that I never really saw this overlap occur, or that OH3 is very very precise, and all the item updates kick-off at the same exact millisecond, when the refresh interval comes due…

I have addressed my own immediate problem, by now creating new programs that run as a Linux Daemons, and update OpenHAB items via MQTT, but perhaps some others have been running into a similar behavior with the OH3 exec binding.

I thought an understanding of whether this is ‘by design’, or possible work-around(s) that may help them avoid going down the same route (writing external services) that I did to get items reliably updating in OH.

FYI - One of the above (MQTT) programs is for a Schneider Zelio Smart Relay (Via “SLOUT”), written in Python. I’ll eventually tidy it up, and share it on here, but happy to share the quick ‘n’ dirty version I created, if someone wants to get their hands on it sooner rather than later.

Cheers

2

Rule threading has changed (which in turn would affect what your rules instruct exec to do when).

Any given rule can strictly only execute one ‘copy’ at a time in OH3. Multiple triggers coming along for one rule get queued, not forgotten, so you can get a train of rule executions. This differs from OH2 DSL rules, where multiple triggers could result in parallel execution of the same rule. (“NGRE” rules in OH2 already worked the queuing way.)

Rules are generally over quickly, but … exec behaviour can give pauses.
If you define a timeout, the rule will wait for your script to complete before continuing. Note that might make the “new” rule queuing behaviour more significant.
If you don’t define a timeout, exec operates in fire-and-forget mode and your rule immediately continues.

4

Thanks for the reponse - These were purely defined as items, and the updates (exec execution) were not triggered by any rules, but rather the Exec binding refresh interval as defined in the item file… (A change in item state could trigger a rule, but I think that is the inverse of what you are describing above).
Cheers

5

Okay, the binding is completely different.