I think I’m missing something trivial: I wanted to clean up my setup and work with proper groups instead of hacking. The issue: I can’t get my rules working with groups!
Group gHouse "House"
Group gGroundfloor "ground floor" (gHouse)
And a rule:
rule "testrule"
when
Member of gHouse received command
then
logInfo("Testrule", "received command")
end
According to the docs the item Testlight should be a member of gHouse - but the rule doesnt trigger. When I change the rule to gGroundfloor the log is written as expected.
The actual goal of this is to iterate over all items within the house, turning everything off. Basically:
gHouse.allMembers.forEach[ member | member.sendCommand("OFF")]
plus a check that member is an actual switch element.
I’d be very grateful for any pointers in regards to documentation, errors in my train of thought and so on
That wording probably needs to be changed because it gives the wrong idea. In your case Testlight is a decendent of gHouse but it is not directly a member of gHouse. Only gGroundfloor is a direct member of gHouse.
The Member of trigger only goes one layer deep in the hierarchy. So it will only trigger for direct members of gHouse, not decedents lower down than that.
If that’s the case it doesn’t really matter how the Member of trigger works. Calling allMembers traverses the subgroups and returns all the members of the Group and all the members of the subgroups (but not the subgroups themselves). So, assuming that the all the non-Group Items under gHouse and gGroundfloor were Switch Items, your forEach will work as written.
Now to address the real problem, turning off everything in the house. There are several approaches.
Forget using the “location” based Groups for this. Create an AllSwitches Group defined as Group:Switch:OR(ON, OFF) AllSwitches. To turn off all the switches at once use AllSwitches.sendCommand(OFF).
gHouse.allMembers.filter[ i | i instanceof SwitchItem || i instanceof DimmerItem || i instanceof ColorItem ].forEach[ i | i.sendCommand(OFF) ]
Import the image registry (see Design Pattern: Associated Items) and you can get all Items with a given tag. If you use the semantic tagging (you really should) you can grab every Item with a Switch tag using getItemsByTag("Switch").
Haha ok, I went not far enough in my experiments. Thanks a lot @rlkoshak !
I’ll go for the tagging solution then, it looks the most clean one in regards to what I’m planning. The groups are still good-to-know in cases if i want ot air the house out or something!
One last follow-up question: Is there some kind of coding reference for DSL? The Item Registry is awesome but I would’ve never found it without you as the Design Pattern didnt look like something I’d want for now.
I havent found something like “an introduction into data models in DSL” or a reference or something similar.
That’s not really part of the language. The ItemRegistry (and a lot of other stuff you call like createTimer, sendCommand, etc) are all Java Objects defined and created by openHAB’s core software. We use those Java Objects to interact with openHAB itself from Rules. You can find all the Classes at https://openhab.org/javadoc/latest/, but that’s not necessarily as useful to you as you might expect. The stuff in org.openhab.core.model.script.actions (openHAB Core 4.2.0-SNAPSHOT API) is going to be the most useful, but you will find almost all of that is documented in the Actions section of the docs.
When you access any of these functions and Objects, whether it’s from Rules DSL or from JavaScript or Python or anything else, you are interacting with a Java Object and the methods and arguments required and how it works is going to be the same.
In the case of the ItemRegistry, that is made available by default in Python and JavaScript as ir. In Rules DSL you have to import it.
