Supposedly when two devices triggered at the same time by Rule A, Rule B which is listening to both devices as a trigger and a condition script to check that both status are turned “ON” to run should only run once.
But when I run this happens, it is triggering Rule B twice. I think that the updates done by Rule A is happening faster then Rule B could listen to the triggers, thus even though I have a script to check if both devices are “ON”, on the first trigger both devices are already “ON”.
If I understand your intent correctly, the first rule sets both items to ON. You only want the second rule to actually execute its action once both items are actually ON, so if the second rule is running in that small time between the first item actually updating its state to ON and the second one doing the same, you want the condition to cancel that run of rule #2.
As you guessed, the timings of all of these various events are rapid, but they are also indeterminate. Although it is likely that the second item’s state is changed to ON by the time to rule’s condition runs, there’s just no guarantee and this rule is going to be inconsistent in its action. It takes a lot of extra logic and script timing hacks to account for all the possible event sequences in a situation like this.
I would recommend that you avoid the condition problem altogether and off-load the comparison of the item states to a different system: a group. I would put both those items into a group and set that group to have a Switch base type and aggregation function of “All ON then ON, else OFF” (or if you’re using text based items - Group:Switch:AND(ON,OFF)). Then I would set the group state updated to ON as the trigger of the rule. Now your rule will only run once and only when both base items have become ON.
@JustinG has the best solution to this. But I also have a few more suggestions.
Change the trigger to “changed” instead of update. That will make this rule work as written I think. I would have to see the events.log to be sure but I suspect that it’s triggering twice because I’ve if the Items is getting an update after it’s already ON.
The “toUppercase()” calls are redundant and not needed. The state of Switch Item will always and forever be “ON” or “OFF” or “NULL” or “UNDEF”. It will always be upper case.
And “ON” will forever and always be uppercase.
I’m not sure your Script action is meaningful. Are you sure it works? To call processFunction you need to give it parens. processFunction().
Yes, I think @JustinG 's solution seems to be the best way for this case. But in another case that I set a rule to listen to devices with different states other than “ON”.
For example, two light switches with color and state, how do I check both are at a specific color and turned on? Because in the UI I can only see that the rule can only listen to one type of command?
Oh and seems that the same problematic behavior is happening when I set the trigger method to “changed to ON”. So could it be due to how the rules are implemented? To run for each time a trigger condition happens?
Trigger the rule on any change or command to any of the the items in question. All the conditions must be true for the actions to be executed so either add a separate Item condition for each state of each Item or use a script condition to test everything in one condition.
As written, assuming the triggered are set to changed, the rule will trigger any time either Item changes to ON and the Action will run off both Items are ON. If one Item changes to OFF and then ON again while the other remains ON, the rule’s action will run again.
Well the problem in question here is that, while the conditions (including using scripts) are working. They are fetching the states of the devices way too fast. Here are the logs provided below showing the problem that I found while testing.
2025-01-20 13:20:45.091 [INFO ] [b2172900-0e79-4af9-a054-94fef604ea04] - ============start==============
2025-01-20 13:20:45.092 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - +==== start
2025-01-20 13:20:45.095 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - zs_eub_2gang_state_left_a4c1387ed8d9ef75
2025-01-20 13:20:45.101 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - test new State undefined
2025-01-20 13:20:45.102 [INFO ] [b2172900-0e79-4af9-a054-94fef604ea04] - script running
2025-01-20 13:20:45.105 [INFO ] [b2172900-0e79-4af9-a054-94fef604ea04] - =========++++end++++==========
2025-01-20 13:20:45.113 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - event state ON
2025-01-20 13:20:45.116 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - ON
2025-01-20 13:20:45.124 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - ON
2025-01-20 13:20:45.125 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - +==== end
2025-01-20 13:20:45.130 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - function running--------
2025-01-20 13:20:45.136 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - +==== start
2025-01-20 13:20:45.143 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - zs_eub_2gang_state_right_a4c1387ed8d9ef75
2025-01-20 13:20:45.146 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - test new State undefined
2025-01-20 13:20:45.149 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - event state ON
2025-01-20 13:20:45.152 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - ON
2025-01-20 13:20:45.156 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - ON
2025-01-20 13:20:45.158 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - +==== end
2025-01-20 13:20:45.169 [INFO ] [144074d6-778b-42b0-a310-0c66abf3dc4a] - function running--------
==> /var/log/openhab/events.log <==
2025-01-20 13:20:45.080 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'aqara_fp2_aqara_fp2_sensor' changed from off to on
2025-01-20 13:20:45.081 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'zs_eub_2gang_state_left_a4c1387ed8d9ef75' received command ON
2025-01-20 13:20:45.083 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'zs_eub_2gang_state_right_a4c1387ed8d9ef75' received command ON
2025-01-20 13:20:45.086 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'zs_eub_2gang_state_left_a4c1387ed8d9ef75' predicted to become ON
2025-01-20 13:20:45.087 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'zs_eub_2gang_state_right_a4c1387ed8d9ef75' predicted to become ON
2025-01-20 13:20:45.093 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'zs_eub_2gang_state_left_a4c1387ed8d9ef75' changed from OFF to ON
2025-01-20 13:20:45.095 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'zs_eub_2gang_state_right_a4c1387ed8d9ef75' changed from OFF to ON
As you can see the condition and action scripts overlapped each other and ran multiple times per “trigger item”, and that all of them fetched the states in an somewhat “illogical” manner where they all have their states finalized and changed for each of the trigger of the “trigger items”. Even stranger is that the condition and action scripts are running before the logs for the device states even came up.
So this problem is hard to tackle regardless of how “condition” is setup.
The alternative is to just use the same “trigger” items from the other rule, but I want this to trigger not just from the other rule, but also from normal usage. e.g. I turn on both light switches at the same time (easy to do with 2 fingers for 2 gang switches).
What I can say is there are two rules in those logs: b2172900-0e79-4af9-a054-94fef604ea04 and 144074d6-778b-42b0-a310-0c66abf3dc4a (note, it’s really helpful to use meaningful ID for rules, Things and Items, 144074d6-778b-42b0-a310-0c66abf3dc4a and zs_eub_2gang_state_left_a4c1387ed8d9ef75 are not meaningful but syncLightSwitches and “Hall_Light” would be meaningful names.
If I just look at the logs from “…0c66abf3dc4a” I see the rule triggered from left so the condition is running and then the action being called which makes sense because by the time the condition runs both Items are ON based on the logs.
Then I see the rule trigger again because right changed to on and the condition starts up again and everything is ON so the action runs again.
I see no overlap.
This is not a linear sequential system. Items change their state ion response to updates in parallel with everything else that is going on in the system. Just because a rule started running when left changed to ON doesn’t mean that right has to wait for that rule to finish before it can change to ON too. Right will change to ON as soon as it gets that update which means it’s already changed to ON when the rule gets to run the rule condition.
All this stuff happens in parallel and you cannot reliy on the order of the events when you design your system
That just might be a side effect of using Frontail and delays in the logger. :shrugging. Looking at the timestamps, the Item change events happened at 13:20:45.093 and .095. The rule first started running (or at least the first log from the rule) happened at .092. Logging to the event bus’s log (i.e. events.log) happen in parallel too. So the fact that the rule started running one millisecond before the events.log shows the changed event is not wholly unexpected, though I’ve never seen that before.
However, I wonder if you are still using received update triggers. Updates do not appear in events.log by default and they happen before the changed event. The timing of the timestamps will make more sense if you are indeed still triggering on updates.
There is no such thing as “at the same time” in OH. There’s really close together (as you can see above) but “at the same time” does not exist. You must make your rule accordingly. You’ll have to create your rule in a way to take that into account. There are lots of ways to do that and not enough information to give you the best approach. Some include:
make it so only one Item triggers the rule (e.g. a Group with aggregation function)
add additional checks to the rule condition to determine whether anything needs to change in response to the event (e.g. are all the Items already in the expected states once the rule does run
make it so it doesn’t matter if the rule action runs more than once