I can see a lot of utility for this and I know a lot of people would like to have this feature.
In the mean time you can get something almost functionally equivalent using groups.
Put all of your MS items into the same Group (I’ll call it gMS for this example). Then your rule will look like to following:
rule "AlarmOnMotion"
when
Item gMS received update
then
Thread::sleep(100) // give lastUpdate time to be populated, you need to experiment with how long the sleep must be on your system
val triggerItem = gMS?.members.sortBy[lastUpdate].last as SwitchItem // or whatever type of item MS_* is
if(S_AlarmLevel.state == "READY") sendCommand(S_AlarmLevel, "HIGH")
end
The above is assuming that your rule as written is incomplete since you don’t actually use your MS_* item. If indeed you don’t actually care which item triggered the rule, you can remove the “Thread::sleep(100)” and “val triggerItem …” lines.
The major limitation with this is for each Item update in gMS the rule may trigger multiple times. I’ve so far found no way around that short of listing each item in the group as a trigger, which kind of defeats the point. However, this may not be a problem for you or “received command” may work better.
But at least this gets you closer to what you want to achieve until such time as your idea gets implemented. Since this touches the core openHAB code, I would not expect to see this sort of thing implemented in 1.x so at a minimum you will have to wait for openHAB 2. You should post this with an openHAB 2 tag as a feature request and see what Kai and everyone else thinks about getting it on the roadmap.
Having a way to figure out which item in the Group triggered the update is something that has been asked for before and it might be on the roadmap for openHAB 2 (I don’t keep up with 2 right now) if not already implemented. But for 1.x we are stuck with the hack I have in my example. There will be no new functional updates to the openHAB 1.x version’s core so the development team can focus on getting version 2 implemented and tested. Even though it is a hack, it is far better than nothing, and at least it is only two lines of rule code as opposed to resorting to lambdas and proxy items which is another way to get around this problem.
Before you get too far along, make sure that you review previous conversations about getting the Item that triggered an update to a group at the old Google Groups forum. It has been talked about for well over a year. Also, I doubt Kai would accept any changes to the 1.x baseline that adds new features to the core. I remember seeing in a different thread that the core is frozen for 1.x so they could focus on openhb 2. You might consider looking into applying this to the 2 baseline.
This is the feature request in GitHub asking for this capability. It has been open for over a year but that is where I would start the conversation to find out if it would be accepted. I could not find a similar issue open in the openhab2 github.
As for my needs, I’m actually very happy with my current approach. Having access to the item that triggered the group would save me two lines of code in my rules, not enough to make we want to change.
The biggest thing that would help me is to have a rule triggered on “Item group received update” only trigger once per change of an Item in the group. For now it actually triggers multiple times for one change which is a side effect of how openHAB calculates whether to update a Group’s state. But even there, I only have one case where that causes problems. The rest just get triggered multiple times and it doesn’t matter.
I just checked the master of openhab2. Looks like it’s a 1:1 copy of the openhab1 rule engine. So, whatever I do for oh1 and if Kai wants to accept it, he could just cherry-pick it from my github fork and port to oh2.
I extended the grammar to also capture “item in …” and have completely rewritten the RuleTriggerManager… I am very close…
Regarding the feature request: there is a difference between “item changed” and “item in changed”. The first one reflects a group’s aggregated state being update where the seconds captures ANY change of ANY item in the group…
