Note for you and future readers. That advice most definitely applies to OH 2.5. However, it does not apply to OH 3.
In OH 3 there is no need for reentrant locks because only one instance of a given rule can run at a time. So that’s already done for you be default. And there is no longer a thread pool that rules run out of. Reach rule gets it’s own thread so long running rules will not starve out other rules. But it will cause additional triggers of that rule to be queued up.
For that reason it’s still a good idea to avoid long running rules, but it’s not as important as it once was.
it takes some time, couple hundred msec or so, for an item to actually change it’s state in response to a postUpdate. It takes even longer (and sometimes never) for an item to change state in response to a sendCommand. By calling .state immediately after sendCommand or postUpdate, you will get the previous Item’s state since it hasn’t had a chance to change yet. This all happens asynchronously.
The items are configured with autoupdate=true. This is configured by default. When you send a command to such an item, the autoupdate mechanism predicts what state the item should become in response to the command. Remember that but all commands are states (e.g. INCREASE). If the binding doesn’t override autoupdate, the item will become updated to that predicted state independent of start the actually device does.
There is a design pattern called Gatekeeper for just this use case. It involves proxy items that receive the commands that triggers a rule that prevents them from being issued to the items linked to the devices too fast. Design Pattern: Gate Keeper - #17 by anfaenger
Another approach would be to use a proxy item instead of a Group. In a rule send a command to one and then schedule a timer to send command to the other one after a suitable amount of time.
In GitHub - rkoshak/openhab-rules-tools: Library functions, classes, and examples to reuse in the development of new Rules. I have a number of utilities that can be used with Jython and I’m starting to add OH 3 JavaScript versions that implement most of this stuff for you.
No, it will be easiest to have your script output something that identifies which valve it controlled.
I’m on my phone so can’t do a proper analysis. If I remember I’ll come back and have a go at a review.
What ever makes sense for you. I tend to define everything at the item but override that at the sitemap sometimes where necessary.
Because of the rule triggers again while it’s already running you will have two copies of the rule running at the same time. The reentrant lock prevents the second one from continuing until the first one released the lock. It’s dangerous because the instance that us waiting for the lock consumes a rule thread from the pool. If you have more than 5 such rule instances waiting around no other errors can run. As I said above, the behavior in OH 3 is different. Only one instance if the rule can run at a time so there is no need for the reentrant lock.
The original code needed the lock to prevent that second insurance if the rule for sending it’s command too soon after the first by blocking it from running until a certain amount of time after the first instance sent it’s command.