[SOLVED] Can the same Item trigger different 2 rules?

I have 2 following rules in 2 different files:

rule "Entrace Door Opened"
	Item Entrace_Door_Sensor received update OPEN
	logInfo("lighting.rules","Door Sensor = " + Entrace_Door_Sensor.state.toString)
	if ((Color_Bulb.state == 0) && (Openhab_Theme.state < NA_WAKACJACH)) {


rule "Entrace Door Opened"
	Item Entrace_Door_Sensor received update OPEN
	logInfo("theme.rules","Door Sensor = " + Entrace_Door_Sensor.state.toString)
	if (Openhab_Theme.state == POZA_DOMEM) { updateTheme.apply(now) }

Though only the theme.rules seem to work:

==> /var/log/openhab2/openhab.log <==
2019-12-09 19:09:02.054 [INFO ] [e.smarthome.model.script.theme.rules] - Door Sensor = OPEN

==> /var/log/openhab2/events.log <==
2019-12-09 19:09:02.062 [vent.ItemStateChangedEvent] - Entrace_Door_Sensor changed from CLOSED to OPEN
2019-12-09 19:09:02.072 [vent.ItemStateChangedEvent] - Last_Activity changed from 2019-12-09T19:08:38.132+0100 to 2019-12-09T19:09:02.040+0100
2019-12-09 19:09:02.083 [ome.event.ItemCommandEvent] - Item 'Openhab_Theme' received command 1
2019-12-09 19:09:02.105 [vent.ItemStateChangedEvent] - Openhab_Theme changed from 8 to 1
2019-12-09 19:09:02.139 [vent.ItemStateChangedEvent] - Openhab_Last_Theme changed from 8 to 1

There are other rules in lighting.rules, that work perfectly fine. Can I trigger 2 different rules with the same Item event?

It is that way only to organise code.

I’d try it with different names of the rule itself.


Yes, I trigger multiple rules with a single item all the time. As Jurgen says, having two rules with the same name will not

1 Like

Good point. Thanks. :slight_smile:

To sumarise:
Same event can trigger different rules, but make shure, that rule names are different.

BTW, I found a bug here. The result of “if (Openhab_Theme.state == POZA_DOMEM)” can be different depending on, which rule will be calculated first, because the “updateTheme.apply(now)” changes the Openhab_Theme state.

Yes, it’s possible, but I would not recommend it. Triggering two rules at exactly the same time can cause high load and slower execution than if you had a single rule. Just combine the bodies of both rules into one.


@5iver: Can you extrapolate a little bit about the high load and slower execution? I’m curious to know “how much load / additional execution”? Generally speaking, load / execution time are not primary considerations of mine, but maintaining code “readability” is.

In terms of the problem I’m trying to solve, I’m trying to write quite a bit of automation around maintaining room temperatures for each bedroom in my house. Each bedroom has a smart vent, a ceiling fan, a door sensor, a temperature sensor, occupancy sensor, window sensor, etc. Some bedrooms have different combinations of sensors. There is a single (ecobee3) thermostat that controls all of the rooms.

I believe (and I’ve just started) that from a “code maintenance” perspective, it will be considerably easier to write a rule (rule file) for each room, taking in all of the logic and sensors available in that room. However, each room would need to use the thermostat status change as a trigger to execute the room rules, and so, a thermostat change would trigger at least 3-5 simultaneous rules.

For perspective, I’m willing to take slight (20%-50%?) load and execution time increases in order to have easier to maintain code. I’m running openhab as a VM on a 2x Xeon x5650 w/ 128GB RAM, so I think I have plenty of horsepower to spare.

Any thoughts or experiences that you can share?

I appreciate you insights!!


It’s an old post.
If you are running OH3, you’re probably using a different rule engine to the original discussion, which manages multiple rule threads differently.

I’m on your side - this is home automation, not real time flight control. A response time of seconds for thermostat functions is no problem.
Human response time to e.g. button triggered lighting delays is generally the ruling “annoyance” factor :slight_smile: More than 200mS starts getting noticeable.

Your available horsepower should make this a non-issue. From experience, higher power boxes generally expose different concurrency issues in rules that pass Pi users by.
Reminder that rule performance is affected by other system factors - “persisting everything” is easy to do but has a cost, for an example.

1 Like

Appreciate the insights!

Thank you!!