Is it possible to have a python rule be triggered by changes to member of two or more groups? Something like:
@rule("Boiler flow temperature boost mode auto switch rule", description="This rule calculates whether boost mode for the heating flow temperature should be engaged", tags=["Example"])
@when("Member of gRoomThermostat received update ||
Member of gRoomSetPoint received update ")
def flow_temp_auto_boost_mode(event):
I’ve looked in the documentation here but couldn’t see a way to specify multiple groups. I could use the Descendent of if I make the two groups in my example above a descendent of a higher level group but wondered if there was another way.
To define multiple triggers use multiple @when statements.
@rule("Boiler flow temperature boost mode auto switch rule",
description="This rule calculates whether boost mode for the heating flow temperature should be engaged",
tags=["Example"])
@when("Member of gRoomThermostat received update")
@when("Member of gRoomSetPoint received update ")
def flow_temp_auto_boost_mode(event):
NOTE: changes the to the membership of the Groups will require reloading this rule.
@rule("Boiler flow temperature boost mode auto switch rule", description="This rule calculates whether boost mode for the heating flow temperature should be engaged", tags=["Example"])
@when("Member of gRoomThermostat received update")
@when("Member of gRoomSetPoint received update")
def flow_temp_auto_boost_mode(event):
BTW, I’m subscribed to posts tagged with jython or jsr223!
I don’t like to bug you with dumb questions. It’s very kind of you to point that out and you may come to regret letting me know. Thanks for all your help. And you too @rlkoshak, and @Bruce_Osborne. I really appreciate all your help!
Then, as you’ve said, those questions belong on their forum and we are not responsible for supporting them here.
But it’s worth saying that the OH REST API is not complete enough to complete replace Rules DSL or JSR223 or NGRE Rules. In particular, you can’t call Actions.
The forum rules on things like this need to be enforced, IMHO. Many parts of OH started as unofficial pieces though, I think things like this that have no chance to become official need to be supported elsewhere, though.
If he’s supporting them here then it’s not adding work on us so there’s no real problems. I’m of the opinion that it can become much more work to enforce some rules than the amount of trouble the rule is trying to prevent. It makes no sense spending time to “fix” a problem that isn’t taking away from our time. And being over zealous in enforcing rules comes across as unfriendly and unwelcoming to new users who invariably violate some rule. Finally, I don’t think there is any rule against this sort of thing in the first place.
Indeed, may parts of OH started as unofficial pieces. But they’ve only become part of OH when they’ve become part of OH, meaning they are packaged up into an OSGI bundle and run inside the Karaf Console. The above and HABApp have no chance of every becoming a part of OH in that way. They necessarily require being installed and run as external services to OH. And since the REST API is not complete enough to do everything in these external services that can be done in “native” OH Rules, they cannot even be feature complete.
HAPApp and the above tool run Rule external to OH and cause OH to do things (sendCommand, etc) through the REST API.
When you use “native” Rules (any one of the three) the Rules are running inside OH and have direct access to parts of OH that are not exposed through the REST API. Yes, you submit new Rules through the REST API for NGRE, but the Rule itself is running in OH and therefore has access to stuff like Actions. Unless and until Actions are exposed through the REST API, HABApp and the above will never be able to call executeCommandLine or sendHttpGetRequest or publishMQTT, et al.
For NGRE you use the UI to write your Rule.
The UI uses the REST API to add the Rule to your OH.
The Rule runs inside OH.
For HABApp and the above, you write your Rules external to OH using some IDE.
You run your your Rules in a service external to OH.
The Rules are only capable of doing things that are directly exposed by the REST API. Actions are not exposed so they cannot call Actions.
Technically, this is not writing OH rules in Python3, but using Python3 to send calls to the REST API. From the looks of it, this is not intended for use with the new rule engine, but since you can create rules through the REST API, it could be. There is also HABApp, which uses Python3 and interacts with OH through the REST API. It is also a third party rule engine (not the new OH rule engine). Scripted automation interacts directly with the new rule engine through the Java/automation API.
Not to nitpick but to avoid confusion, the NGRE is not synonymous with UI rules. Scripted automation, the REST API, JSON resource bundles, and the console all use the NGRE.
We need a name. There is a real distinction between JSONDB Rules and JSR223 Rules and there needs to be a name we can use to distinguish between the two. Frankly, neither JSONDB Rules nor JSR223 are meaningful and descriptive to people who are not steeped in the technical aspects of how they work. From a plain old user’s perspective, and especially from a non-technical user’s perspective, they are complete different. How the rules are created, where they are stored, what you can do to them through the UI, etc. are all different. When you look at a lot of the old talks that Kai has given he used NGRE synonymously with the JSONDB Rules.
It’s all well and good to be specific about what NGRE refers to, but it leaves me left without an alternative name to use for the JSONDB Rules. I really don’t want that to be the name. UI Generated Rules doesn’t flow off the tongue either. I don’t care if we call one “Fred” and the other one “Martin”, but I do think we need a name. It’s just too hard to talk about otherwise.
This really distills down to managed vs unmanaged, and the rule editor used. OH “sees” managed rules in the NGRE as JSON resource bundles, similar to managed Items, Things, etc. The UI can be used to add/change/remove “managed rules”, but you could also use a text editor. Paper UI currently displays managed and unmanaged rules the same, until you drill down into them, just like Items and Things. Hopefully, the new UI will visually highlight or filter out the different types.
I’ve been using “UI rule”, but that really isn’t very accurate, since the UI is just an editor for managed rules.
I do my best to use the term scripted automation instead of JSR223, but it’s pretty well ingrained into OH. The next OH doc update I do will replace all references to JSR223 with scripted automation. For OH3, I plan to remove the /automation/jsr223/ directory. Scripted automation is the unmanaged flavor of rules for the new rule engine.
In your posts about migrating to managed Items, I’ve wanted to ping you about the possibility of creating a script for it. You can even create the Links. Check the OWM community script for examples. Recently I switched to ManagedProviders in core.items and core.links, so that the Items and Links would persist, but I need to change this again so that the user can decide if they want managed or unmanaged Items and Links. I also have a core.things library that I’m testing, with a Simple Mode-like option, but for a specified Thing. There is/was a PR in OHC for something similar, but it seems to have fizzled (probably will be addressed in OH3).
It should also be possible to create managed rules with scripted automation. The scripts would end up like templates that spawn rules every time they are executed, and those rules could be managed through a UI. You’d need to code for the eventual second running of the script, if you wanted to prevent the creation of multiple instances of the rule. But it would be similar to what you would do for managed Items… if don’t create it if it already exists.
Do you think managed and unmanaged is clear enough for the average user to differentiate between the rules they edit in a UI and the rules they edit in script files?
Thanks for all your help. And you too 
instead.
