I’d like to propose two extensions to the rules:
Allow matching Item by regexp to allow rules for multiple (similar) items
Best explained with an example:
Item "MS_.*" received update
if (S_AlarmLevel.state == "READY") sendCommand(S_AlarmLevel, "HIGH")
Here, “MS_.*” will match all items having MS_ as prefix. The idea to treat in Item … as a regexp.
Provide matched item in the scope of the execution blog.
For this, I would just introduce triggerItem variable in the scope of the execution block.
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:
Item gMS received update
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")
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.
What about also adding an
Item in gMS received update
That links the rule to any item in gMS that received an update?
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.
I am already getting my hands dirty on the openhab code… I’ll let you know once it’s done…
Any ideas beyond what we discussed?
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 know what your mean…
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…
So, it’s done and works…
I rewrote the whole handling of triggers and also fixed a few bugs along…
Here’s the commit in my fork: https://github.com/derolf/openhab/commit/535c37505236de8fd8e96389a6ded36d19c4dfac
This really sounds lovely!