File Include


i have a little question regarding rules. Is it posible to include files into rules?

In some rules i use notifications and i don’t want to write this notification in every rule file. It is much to do if there are any changes.

Thanks for help,

Best regards,

Create a script and run that. But then the message needs to be the same for every rule.

Another possibility could be to use lambda functions.

One other option is to create a Notification Item that you sendCommand your message to and a rule to actually implemented the notification.

This is the approach I use and it works great, let’s you avoid repeating code all over the place, and let’s you do additional logic like sending notifications different ways based on time of day.

1 Like

Thanks for your help. A notification Item is a good Idea.

And you would be able to easily send notifications through multiple channels at once: pushover, myopenhab, mail, telegram, jabber etc.

That is exactly what I do actually. If it is during the day and an Alert it gets sent out to via my.openhab so it goes to all users. But at night they only get sent to me over PushBullet.

1 Like

Hi all,

Unfortunately the original question

hasn’t been answered, although it seems to be a ‘no’.

I’ve created some complex lambda functions which I want to use in several rules.
But I also want to not have one huge monolithic rule file, but use compact rule files addressing one functional objective per file.

So I’m very interested in the answer to the original question:
Is it possible to include another Xtend rule file into a rule file?

If yes, how?
What happens with the scope?
And, if possible, what about any variables declared in the include file?


The answer isn’t no, it’s just that there are lots of better ways for op too accomplish what he wanted.

You can lead the file using Java File IO libraries.

You can use execute command line and cat the file into a String.

You can use a Java Properties Object and lead the file into a Properties Object which behaves like a Map.

You can use a map file and the transform Action.

But none of these are better than the suggested solutions for op’s actual problem.

This is a completely different problem entirely from what op asked. Her wants so Strings he can reuse. You want to include code.

This is warning flag one. If you’ve gone down this route you will probably be better off using JSR223 instead of Rules DSL.

This is a good standard approach and the approach I recommend. However, it sounds like you might be taking it a bit too far for what the Rules DSL can support. You can and should separate rules into files based on function, such as lighting, weather, HVAC, etc. But if you go more fine grained then lambdas will not be much use to you. If you have lambdas that need to be used across functions, you should use Design Pattern: Separation of Behaviors instead.


Lambdas are stored in a global var/val. Global var/vals are scoped to the file in which they are defined.

OK, so that is all out of the way.

The Rules DSL is purposefully restricted. It limits certain options and features to provide a less complex programming environment for non-developers to learn and become productive. Among these restrictions are:

  • no classes
  • no data structures
  • no libraries/reusable code outside of lambdas which can be used within a single .rules file

These restrictions are incredible difficult for some types of OH users to adapt to. Thankfully, through the JSR223 add-on, it is possible to write Rules using “real” programming languages including Jython, JavaScript, and Groovy. If you are unable or unwilling to adapt to the Rules DSL, you really should consider switching to one of these options.

If you want to stick with the Rules DSL, here are some Rules of Thumb you can use to apply.

  • Organize your Rules by function (e.g. lighting, HVAC, etc). This will increase the likelihood that and global var/vals and lambdas will be applicable. Put another way, your lambdas and global var/vals will most likely apply to only one set of functionality. Don’t go too fine grained though as that will force you to reproduce your global var/vals in multiple files, a violation of DRY.
  • Save state in Items. That is what Items are for. If you have the same if statement in lots of Rules (e.g. to calculate whether it is between certain hours of the day or day of the week), centralize that calculation into one Rule and update an Item as necessary
  • Don’t be afraid to split out certain calculations and behaviors into separate Rules. For example, Design Pattern: Time Of Day and Design Pattern: Separation of Behaviors. This is particularly useful to calculate state (e.g. time of day, type of day, home/away, etc) and to centralize cross cutting concerns (e.g. alerting).
  • If you find yourself defining Procedures without arguments (i.e. a lambda that doesn’t return a value), consider using Rules DSL Scripts instead.
  • Instead of data structures, use Groups and Items to store and organize the data.
  • Use the Member of Rule trigger and the triggeringItem implicit variable to consolidate a collection of Rules that all do the same thing into a single Rule as an alternative to lambdas.

By applying these rules of thumb and design patterns, the number of cases where one needs to write a lambda should be relatively rare, which is why I said it is a red flag above.

Hi Rich,

Thanks for your pointers towards a better solution.
Since working with OH I’ve developed a real hate for Xtend, so your hint to use JSR223 is something I’m certainly going to look into.
Basically I’ve implemented my own HTML5 user interface, not just to control devices, but also to configure much of the automation in my home. So programming once (which has grow rather complex by now) and from then conveniently configuration via a dedicated UI which I’ve tested on Android, iOS, and several Windows browsers.
When changing the rules configuration, my PHP API layer pushes an update to an OH item, so that the rules are actually executed within OH.

My problem is that I made a kind of library of functions that I use to execute these rules. I use those definitions in multiple rules. And just to keep maintainable code I’d like to split the stuff into multiple files.
My knowledge of Xtend is rather limited compared to other languages, so I wasting a lot of time with trial and error-style debugging.

Therefore your hint to try a plug-in to switch to another language sound like a very good idea, albeit a bit like giving in. :wink:
I was already thinking of implementing my whole logic in PHP and just keep the interaction with OH to a minimum by updating statuses and post commands via the REST interface.
Benefit: it limits the number of languages and I don’t rely on another OH plug-in.
Drawback: more and more moving away from OH, which I prefer not to do. I like to use the power of OH as much as possible.

Thanks for your help! :+1:


It’s a little difficult to tell what you are doing so I’m not sure I fully understand how you have this configured and why you have these lambdas. Were I to build something like this I’d have the UI interacting with OH through the REST API, the “configuration” represented via Items, and Rules that trigger when the configuration to update other Items as necessary so represent the updated configuration. the Rules that care about the configuration then just check the relevant config Items and do the appropriate thing based on those instead of calling a lambda to recalculate the config to see what they need to do.

I don’t see the purpose for the lambdas, but I’m also not seeing your code.

If you want to get deeper into the language look at:

I don’t think Xtend is incapable of supporting your overall goal of having your own UI. But you may need to rethink how this UI integrates with an interacts with OH.