Thanks for the explanation… it demonstrates to me that I never understood openHAB… hence. the constant problems I am facing with it.
I saw your post elsewhere:
… and read: Rules | openHAB
It does my head in… 
I always thought OH has an event bus, with items that have a state; the state changes rule-based or event-based, and if that happens the state changes to reflect that state.
Now I learn, it may or may not change its state, and more conditions when it may or may not do so. Why on earth is it designed that way? Is there even logic in this basically unpredictable behaviour?
The sleeps are in the code, because I noticed that the state is not updated in a timely fashion, hoping the sleep() would fix this issue.
The sprinkler code basically works by starting with valve 1 setting a few variables, and then cascades through the other valves incrementally. It “fails” only some 5% of the time (another inconsistency of that state business), and I may leave everything as it is.
My general issue is, I can get the hang of a programming language and then not use it for a few years, and forget all about it. E.g. I programmed a website (content system) in ASP in 2004; rewrote it in PHP in 2011; had to change to PHP7 in 2016, was forced to make at least the minimum change from mysql() to msqli() to make the site work again. I can’t remember a thing about ASP, forgot all about PHP in 2016, and today… because I do not use it in between. so with OH; OH1 worked, installed a new OH2, moved the rules; fixed what needed fixing and forgot about it. Four month later I find this problem, and literally start from scratch… and yes, I am on old fart (over 60 yo).
In essence, I am after programming principles that always work, and not this works here and this works there (insert condition here). If I say change state, I want this reflected to reuse it elsewhere; I am happy to understand what I need to do to achieve this (and never worry about options again). Am I too naive | demanding?
Or is it as simple as, replace all .state with .receivedCommand?
[later edit:] further thinking about this… so if I use receivedCommand() and change the items or rule file this would be a ‘system start’, the item has not yet received a command, hence receivedCommand() may return null, yet its state is ON. Or do I need persistence, which as I understand it only saves its state, not the last command??