Best practice for .rules

[chzimm (Christoph Zimmermann)]

Hello!
whats the best way for .rules files? One big .rules with many rules inside or many little .rules files with only on or two rules?
Whats best practice for openhab?

Thanks,
Christoph

[opus (Jürgen Baginski)]

There are different topics to think about.
When you have the need to switch rules on and off ( Christmas lighting etc…) it is better to have them seperated.
The use of global variables is possible only within the scope of the file where they are created.

[rozpruwacz (Marek)]

I have a similar question, what is the best practice for multiple similar rules. When i want the same rule apply for different items ? E.g. i want to control lights in the same way in multiple rooms, the only things that will differ in those rules will be switch and light items. Now i just copy the rules and change items in them, the rules are very simple so making a function will not change anything because still i need to define rules with proper items.

[james_2_roberts (Jimbob)]

Hi @rozpruwacz,

In that case I’d suggest the Design Pattern: Associated Items which will enable you to re-use the same rule with differing trigger and actions.

Cheers
James

[rozpruwacz (Marek)]

yeah, that’s pretty neat thanks !

[rlkoshak (Rich Koshak)]

@rozpruwacz, in addition to Associated Items, I think

Design Pattern: Separation of Behaviors

Edit: Updated for OH 4. Please Design Pattern: What is a Design Pattern and How Do I Use Them for more information on what a DP is and how to use them. Problem Statement Often one will have certain cross cutting code that is used across a many diverse and varied collection of Rules. Such code can include things like calculating time of day to control the behavior of a rule, sending alerts, calculating state to drive a state machine, etc. For example, Lighting, blind/rollershutter controls and …

and

Reusable Functions: A simple lambda example with copious notes

Major Edit: Rewrote with the cleaner OH 2.3 syntax. The example lambda on the OH 1 wiki is overly complex and as written will not work in OH 2. This quick example will show a super simple lambda example with copious notes. Here is the code without comments. It takes in an Item, logs it’s state and returns a slightly modified version of the String logged. val log= [ GenericItem s | logInfo("lambda", s.state.toString) s.state.toString + " logged" ] rule "Call Lambda" when // some t…

may also be applicable to your situation.

For the lambdas, @opus’s warning applies, only rules in the same .rules file as the lambda is able to call the lambda.

The following will also be useful:

Design Pattern: Working with Groups in Rules

Edit: Updates for OH 4, inclusion of JS Scripting and Blockly examples, removed the doors example as it’s superfluous. Please see Design Pattern: What is a Design Pattern and How Do I Use Them for how to read and use DPs. Problem Statement One powerful way to consolidate code in rules is to use array/list manipulation operations on the members of a Group. For example, filter down to just those members that are ON, get a list of the labels of those Items that are NULL, etc. Concept [image] T…

@chzimm, to elaborate on @opus’s response. I usually recommend separating your .items and .rules files into separate files based on their functionality. For example, put all your lighting rules into one file and all your presence rules in another. This will naturally co-locate those rules that are most likely to need access to the same global vars and vals and lambdas. When you have cross cutting concerns (e.g. alerting), the Separation of Behaviors Design Pattern above will let you centralize that code into its own file but let all your rules access it by commanding Items.