I didn’t see that he was on 2.5. I should have looked more closely. I wonder if it makes sense to have a “Legacy” category in the forum where anyone running a version of OH older than say two years or four years can post and perhaps find people able to help. I can usually help with generic stuff that is still the same today as it was back in 2.5 but I do not trust my ability to support most of the stuff that has changed since 2.5 any more.
And it may not be fair, but it’s hard to not have the feeling that if you want to keep running unsupported versions of software years and years after it’s no longer supported, you shouldn’t be changing anything: no new rules, no new bindings and things and Items, no updates to the OS. It should be a time capsule humming along until something outside the system breaks it and you are forced to upgrade, which is going to be a whole lot more work all at once than keeping up with the upgrades would have been.
Anyway, I was mainly posting for future readers of this thread who balk at how awkward the timer approach in Rules DSL is to show there are better ways. I don’t expect @Javad_Effat_doost to change their rules over to some other language, if for no other reason than for the most part those users who are willing to change have done so already. Anyone left using Rules DSL is likely unwilling to change.
But there is a version of OHRT written in Python that could be used in 2.5 which provides both deferred and gatekeeper. GitHub - rkoshak/openhab-rules-tools at before-npm. I originally wrote OHRT for 2.5 in Jython way back in the OH 2.x days. I converted it to JS Scripting in OH 3.0 because it took some time for Jython support to come to OH 3 and at the time the JS Scripting devs were the only ones willing to help address the needs of managed rules users.
Two different problems. The Thread::sleep problem is a potential problem unrelated to the arraylist index.
Why both a command and an update? Unless you’ve disabled autoupdate, the command will result in an update meaning statge2 receives two updates and the rule runs twice.
How do you know the index is stuck? Log out what you postUpdate and sendCommand in the one rule and log out what is it in the rule that triggers based on the updates. Also log out what’s in the ArrayList. Maybe it’s not what you assume. When code doesn’t work you cannot assume anything. You must verify everything.
It’s less of a problem to use Thread::sleep on OH 3.0+ than it was to use it in Rules DSL in 2.5 and before.
In OH 2.5 there were only five threads (IIRC) available to run rules and there was no lock to prevent the same rule from being triggered again and running in more than one thread at the same time. Since the one rule can take up more than one thread and there are only five threads a long running rule can consume all the available threads and starve out all the rest of your rules, forcing them to wait until one of those long running rules exits before any other rule can run. (OH 1.x and OH 2.x Rules DSL only] Why have my Rules stopped running? Why Thread::sleep is a bad idea
Additional problems includes that each thread running the rule is running the same rule meaning that one thread can modify variables that impact all the other threads running that same rule.
In OH 3.0+ each rule gets it’s very own thread and that thread is locked so you can never have more than one copy of a rule running at a time. So at worst you would starve out that one rule’s ability to run as triggeres queue up and are worked off in sequence instead of starving out all your rules.
But because this is a system started triggered rule, it’s only ever going to be triggered the one time so the risks that come with long running rules is reduced.