Up to now openHAB has embedded JBoss Drools as a rule engine for automation rules. Although Drools is very powerful, this solution also has a few problems: The Drools IDE is not completely working in the openHAB Designer, so that no code completion and syntax checks are available for the rules. This makes the creation and debugging unnecessarily difficult, especially as the Java syntax of the rules is not very intuitive.
Although Drools offers an option to define tailored DSLs for rules, which could lower the syntax complexity, I personally feel that Xbase might be a better match for openHAB on the long run. This is why I have started with the development of an alternative rule engine for openHAB, which is fully based on Xbase. I would like to give you a brief summary of what exactly I have in mind:
Being a part of Xtext, Xbase perfectly integrates with the item and sitemap definitions of openHAB (which are already based on Xtext). It will therefore be easy to reference items from within rules and to have full IDE support on them. The "execution" part of a rule would be basically an list of Xbase expressions, which leaves a lot of power to the user as he can do all actions he was able to do in a Java-syntax Drools rule.
The main challenge is the "when" part of a rule, i.e. the triggering condition. Here lies the full power of Drools: Using a sophisticated RETE-algorithm it is possible to have relations between rules, where the triggering of one rule means the deactivation of others etc. This is indeed very powerful and necessary for expert systems and alike. For home automation use, my impression is that this rather confuses the normal user who still wants to be clear on what is executed when (and hence the defined rules usually use quite simple trigger statements).
The idea is to provide different kind of triggers (of different categories) for the new engine:
Although Drools offers an option to define tailored DSLs for rules, which could lower the syntax complexity, I personally feel that Xbase might be a better match for openHAB on the long run. This is why I have started with the development of an alternative rule engine for openHAB, which is fully based on Xbase. I would like to give you a brief summary of what exactly I have in mind:
Being a part of Xtext, Xbase perfectly integrates with the item and sitemap definitions of openHAB (which are already based on Xtext). It will therefore be easy to reference items from within rules and to have full IDE support on them. The "execution" part of a rule would be basically an list of Xbase expressions, which leaves a lot of power to the user as he can do all actions he was able to do in a Java-syntax Drools rule.
The main challenge is the "when" part of a rule, i.e. the triggering condition. Here lies the full power of Drools: Using a sophisticated RETE-algorithm it is possible to have relations between rules, where the triggering of one rule means the deactivation of others etc. This is indeed very powerful and necessary for expert systems and alike. For home automation use, my impression is that this rather confuses the normal user who still wants to be clear on what is executed when (and hence the defined rules usually use quite simple trigger statements).
The idea is to provide different kind of triggers (of different categories) for the new engine:
- Event-related triggers: "Item X was updated", "Item X changed to OFF" or "Item X received command UP"
- State-related triggers: "State X == ON", "State X != 0" or "State X > 20"
- System-related triggers: "System has started" or "System is shutting down"
- Timer-related triggers: "Time is midnight" or "Timer cron(0 * * * *)"
Obviously, one can think of many other trigger possibilities, but the list above should imho do for a start. Keep in mind that you can still do additional if-statements inside the "execution" part of your rule if these triggers do not suffice.
An example rule could hence look like this:
rule "Announce caller"
when
Item IncomingCall was updated,
State Presence == ON
then
send MusicPlayer OFF
send MusicPlayer OFF
say IncomingCall.newState + " is calling";
end
end
If you compare this example to the current Drools syntax you will see that it is much more natural to read. Having full IDE support with code completion etc. also makes writing such rules much simpler than it is today.
I am planning to show this new rule engine in action in my talk at EclipseCon Europe on November 3 in Ludwigsburg, so make sure you are there if you are interested in it!
I am planning to show this new rule engine in action in my talk at EclipseCon Europe on November 3 in Ludwigsburg, so make sure you are there if you are interested in it!