Roadmap to Happiness - What is missing in the core framework

There are currently several approaches to solve this.

  1. Use Design Pattern: Separation of Behaviors 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. 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. 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.

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

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.

2 Likes