Kai Kreuzer

Using Xbase for Home Automation Rules

Posted on September 29, 2011

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:

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

say IncomingCall.newState + " is calling";
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!

Building p2-enabled products with Tycho

Posted on December 1, 2010

Working on the build and the packaging of openHAB, I had to undergo quite some efforts to get it done with Maven3/Tycho.

My special challenge was to package a product which is p2-enabled and includes root files. If you just want to do the one or the other, it works quite straight forward: You can use the "eclipse-application" Tycho packaging type to build Eclipse RCP products, which will also nicely include any root files that you have defined on your features.

Since version 0.10.0, Tycho also supports building p2-enabled products (TYCHO-188), but you will have to use the "eclipse-repository" packaging type to do so. Unfortunately, root file inclusion does not work with this packaging type (due to very complex reasons, see TYCHO-513 and TYCHO-465).

So what is the workaround to have both at the same time? I have chosen a combination of the "eclipse-repository" packaging and the "classic" Maven assembly plugin to do this job.

The "eclipse-repository" packaging is used in a Maven project that contains the RCP product definition. Using the "materialize-products" and "archive-products execution, makes sure that the p2 director is used to install and package a product from the repository (for all platforms that are listed in the configuration of the target-platform-configuration Maven plugin). Note that choosing Mac as a platform does not seem to be an option right now, at least I could not get it working...

If you now run a "mvn clean install" on this project, you will find the resulting zip files in the target folder. But how to add additional files (such as readmes, licenses, start scripts, additional libraries and folders, etc.) to it to make it your final distribution? That's where the Maven assembly plugin comes into play:

You need to create a Maven project that contains the files you want to add. The assembly plugin allows the inclusion of project dependencies in the assembly, so we need to define a dependency on our product project in our pom.xml. The problem here is that if you do this as usual, you will end up with the packaged p2 repository to be included in your assembly as this is the primary artifact built by the "eclipse-repository" packaging. Luckily, the product zips are attached as additional artifacts to the build result, so we can define a dependency like:

<dependency>
  <groupId>com.acme</groupId>
  <artifactId>com.acme.rcp.product</artifactId>
  <version>${project.version}</version>
  <type>zip</type>
  <classifier>win32.win32.x86</classifier>
</dependency>

In the assembly descriptor, you then need to say that you want to unpack this dependency into your assembly. As Tycho often packages a bit to much into the zips, you can also take this opportunity to remove a few contents that you do not want in your final distribution:


<dependencySets>
  <dependencySet>
    <useStrictFiltering>true</useStrictFiltering>
    <useProjectArtifact>false</useProjectArtifact>
    <useTransitiveDependencies>false</useTransitiveDependencies>
    <outputDirectory>/</outputDirectory>
    <unpack>true</unpack>
    <unpackOptions>
      <excludes>
        <exclude>**/org.eclipse.platform.doc*.jar</exclude>
        <exclude>**/org.eclipse.jdt.doc*.jar</exclude>
      </excludes>
    </unpackOptions>      
    <includes>
      <include>*:org.openhab.designer.product:*:win32.win32.x86</include>
    </includes>
  </dependencySet>
</dependencySets>

Note the reference to include (only) the dependency to the zip for the Windows platform; this is necessary as you might have many dependencies for different platforms defined in your assembly pom.xml. This include tag makes sure that this assembly descriptor picks up the right dependency (you can have other assembly descriptors for other platforms in the same assembly project).

This solution might not be the most elegant, especially if you are building packages for many different platforms (you need a separate assembly descriptor for each). But it works for me and I thought it could be helpful to others as well. If anybody knows a smarter solution or has a suggestion how to improve mine, I'll be more than happy to listen :-)

Binary builds for openHAB available!

Posted on November 29, 2010

As promised during my talks at the Eclipse Summit Europe and the OSGi Users' Forum Germany, I have finally fully automated the build of openHAB with Maven3/Tycho and uploaded the result to the openHAB homepage.
You will find there a platform-independent runtime zip that should work out of the box on Windows, Linux and Mac. This is all you need to get started. If you prefer IDE support for the configuration and rule files, get the openHAB designer zip file as well.
Besides these components, there are also optional bundles available in the download section, which you can add to your runtime if required for your setup. For all of this, simply follow these simple installation instructions.
Please excuse that the documentation about the configuration files, formats and options is still very limited - please visit the discussion group if you are in any doubt of what you need to do. I'll take care to update the documentation on the website subsequently.

openHAB @ Eclipse DemoCamp in Darmstadt

Posted on July 27, 2010

I had the pleasure to present my openHAB project at the Eclipse Helios DemoCamp in Darmstadt on July 14, 2010. First of all, a big "thank you!" to Jochen Hiller and Marcel Bruch who have organized this great event and gave me the opportunity to do a short demo.

Altough most of my presentation was a live demo, I also had some slides that I have now made available on SlideShare for anyone who is interested.

Tycho Entering the Eclipse Space

Posted on April 9, 2010

Almost two years have passed since my blog post about the the discrepancy of OSGi/p2 on the one side and Maven on the other. At that time I was pessimistic that the two worlds would ever come together and the creation of the B3 project even reinforced that impression.

Nonetheless I followed Sonatypes efforts on the Tycho front during the last year, which looked very promising. It actually already works so well that I recently changed the build of openHAB from Maven2/PaxConstruct to Maven3/Tycho - it's really cool (a blog post with details will follow soon).

Seeing that Chris Aniszczyk has now also embraced Tycho for the JGit/EGit builds is a clear sign that Tycho (and thus Maven) is slowly being picked up in the Eclipse space.

And the best news: Tycho has just been proposed as an Eclipse project! As the proposal states, it "competes with these [Buckminster, B3, PDE Build and Athena] projects". But seeing its current stability, its ease-of-use and all its possible synergies with the existing Maven tooling, I am pretty sure that it will win the race for being the preferred future build infrastructure for Eclipse/OSGi projects.

Kudos to Sonatype, who really put a lot of effort into this and who has torn down the barriers between the two worlds!