# Roadmap to Happiness - What is missing in the core framework

**URL:** <https://community.openhab.org/t/roadmap-to-happiness-what-is-missing-in-the-core-framework/54522>\
**Category:** Runtime\
**Tags:** development, eclipse\_smarthome, core\
**Created:** [October 23, 2018, 1:09pm UTC](https://community.openhab.org/t/roadmap-to-happiness-what-is-missing-in-the-core-framework/54522 "2018-10-23T13:09:36Z")\
**Posts on this page:** 1\
**Showing post:** 60

<div class="post-metadata">

**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\
**Post date:** [October 25, 2018, 2:56pm UTC](https://community.openhab.org/t/roadmap-to-happiness-what-is-missing-in-the-core-framework/54522/60 "2018-10-25T14:56:04Z")

</div>

> [@SteveDowling](#):
>
> I’d like global functions that can be called from any rule or a way to include a file with a lambda in a rule file. Lambda’s work pretty well for me at the moment but they force me to include everything that uses them in the same rule file and I’d like to break out my rule files in a different way.

There are currently several approaches to solve this.

1. Use [Design Pattern: Separation of Behaviors](https://community.openhab.org/t/design-pattern-separation-of-behaviors/15886) to have a Rule “call” another Rule. This is great for cross cutting concerns like sending alerts that get called from all over the home automation.

2. Use Scripts like discussed in [A simple scene management: finally a good use of scripts](https://community.openhab.org/t/a-simple-scene-management-finally-a-good-use-of-scripts/48625). This is less generically useful because of limitations in Scripts (can’t pass in arguments or receive a return value) but can be useful in some situations.

3. Organize your Rules according to function, not location or some other organization approach. If you put all your lighting Rules in the same file, there is less chance that it will need to call a lambda defined outside of the same .rules file. And if it does, see 1.

4. Write Rules in a more generic way taking advantage of Member of triggers, triggeringItem implicit variable, and [Design Pattern: Associated Items](https://community.openhab.org/t/design-pattern-associated-items/15790). When all the processing takes place in one Rule there is no need for lambdas in the first place.

If you apply all 4 of the above I think you will find that this particular problem will go away.

> [@SteveDowling](#):
>
> Ah, so I need to change my existing rules? I must have missed that, sorry.

So the new Rule Engine does all Rules to call each other directly. But I can’t recommend moving to the new Rule engine just yet until some more documentation gets written.

But the larger point is we will be unlikely to see any new major additions to the capabilities of Rules DSL. Eventually (soon?) there will be a way to convert Rules DSL Rules to the new Rules Engine and the old Rules Engine will be deprecated.

I’m starting to gather the information to document the new Rules Engine at: [Experimental Next-Gen Rules Engine Documentation 1 of : Introduction](https://community.openhab.org/t/working-with-paperui-rules-experiments/54669)

It’s more just random notes at the moment but I intend to build it into a first draft for the docs that will go into the official docs. So stay tuned.

---

_[View the full topic](https://community.openhab.org/t/roadmap-to-happiness-what-is-missing-in-the-core-framework/54522)._