Alternative rules implementation idea (akka / scala bundles)

Openhab experience: a few hours (I have a zwave sensor / dimmer that I am playing with).
General feeling: deep frustration
Professional experience: 10+ years software, 2 years osgi, 5 years java / scala

I understand why openhab has it’s own scripting dsl, I just hate that the cardinal sin has been committed of not documenting it in any kind of depth at all, and instead people seem to be encouraged to generally copy/pasta snippets from forums without any real understanding of what is really going on.

Akka is an actor based framework which seems very appropriate for the types of problems people want to solve with rules. Scala has a number of nice features as a DSL host, the only hurdle to overcome is making deployment a smooth experience. Obviously this won’t be for everyone, maybe it will be just for me.

What I think I am going to do:

  • Write an osgi service that is an event subscriber that pushes all events to an akka router.
  • Write some actors that can receive said events. Give them some dsl that can send commands.

If that works nicely:

  • Write an sbt or gradle (or both?) plugin that can read item definitions out of the rest service and generate code for them, so that I can have nice types rather than operate on generic events.
  • Write an sbt or gradle plugin that can push my compiled bundle to openhab with minimal friction.

This idea has been half-baked while scanning the eclipse smarthome code. It doesn’t seem like a ton of work, and osgi has all the hooks to make the dynamic loading and unloading of my akka actors as painless as it will ever be.

Can someone talk me out of it? Or tell me why this is a horrible idea?

For people with some programming experience this gives a very sensible concurrency story, relatively lightweight syntax, complete docs on how to achieve their wildest dreams (akka / scala + eclipse smarthome) with little to docs responsibility falling on me directly beyond explaining the actor registration method, plus build plugins eventually. Seamless with full compile-time guarantees.

Needs scala dev env, not really suitable for casual users. Scala compiler is a beast and so not suitable for on-the-fly compilation on something like a pi, so difficult to give something as light as current experience.


  • look at the JSR223 binding that lets you code Rules in Jython, JavaScript, or Groovy
  • contribute to the Experimental Rules Engine which will eventually someday replace the current Rules DSL
  • use NodeRed as your Rules Engine
  • contribute to the Rule documentation to address the root problem

Personally, I think what you propose is close to a horrible idea.

  • Something like this already exists for other languages (see JSR223)
  • It only solves the problem for you and a tiny percentage of the overall OH users, much better to spend the effort on a solution that will make a bigger impact
  • The deployment and compilation issues you raise makes Scala unsuitable IMHO, though the overall approach is still valid and to a large degree is how Node Red integration works (the interface is MQTT in this case)
  • I think you greatly underestimate the effort that will be required to adequately document it.

These are just my opinions but I would much rather you spent your efforts addressing the problem in a way that will have a bigger positive impact on the OH community overall.

This is more a side effect of the fact that the Rules DSL doesn’t support libraries (something being addressed in the Experimental Rules Engine (ERE)) and the majority of OH users are not coders. No amount of depth in documentation will change the fact that a huge number of OH users, if not the majority, will be doing cargo cult programming of their Rules. This is also one of the things the ERE is trying to address.

I have written non-trivial bindings for scriptable stuff for jsr-223 in the past. I just really love having a compiler prove things for free about the programs that I want.

This is very fair.

Also fair. Question: How does one assuming that one doesn’t want to just be relying on existing snippets discover what functions are in scope what what their signatures are? For instance createTimer.

I’ll have a look at the new experimental rules stuff. Maybe I can contribute there. I’ll still probably do something nutty with scala (or perhaps kotlin) and precompilation because I will always want this. A pleasant side effect of the type of api that akka would provide is the ability to write tests that I can base off sniffing the eventbus and replaying them. I get that this is uninteresting for many, but it will be interesting to me.

Thanks for your thoughts.

First post and normally I only have time to read and not to write. I have been using OH for a few months now.
In the rules department I followed a really good “how to” from the forum about how to use Node-Red with OH and never looked back. I use it with MQTT and/or the OH node-Red flows plugin.
I guess it just happened that started from there and I do understand informatics tools from other professional activities, but makes you wonder why any other effort on rules even exists in the OH ecosystem, NR is versatile, reliable, stable and lightweight. Pretty straight-forward for the novice user.
I only used a few OH rules (in the copy-paste fashion) when I needed TTS services and such that OH provides out of the box but NR doesn’t talk to easily.

If anyone has time and programming experience, PLEASE, invest it in providing a better framework/documentation for the JavaScript/angular snippets that can be used in Habpanel. OH is missing a good UI (think Apple in what I define good) which is tough for one to implement unless they are experts in JavaScript (or are exclusively invested in Android).

My $0.02.

You won’t be surprised to hear the answer is “it depends”. Being a coder this will be easier for you than a non coder.

  • All installef Actions and all Items and Groups are always in scope. The implicit variable now is always in scope. Some rules have additional implicit variables (e.g. previous state for a change triggered rule and receivedCommand for received command b triggered rules). Implicit variables are documented in the Rules docs page.

  • Naked functions like createTimer, sendCommand, say, etc will be documented in the Actions section of the Docs. The only exception is the createContainer functions (e.g. createHashMap) which I’ve only seen in the Movie Example/tutorial of the Xtext documentation. But they are just a shortcut call to the constructor and not necessary.

  • Java classes are documented in the javadocs. By default java.lang.* is in scope and anything that is part of the core Java language can be imported (java.util.* is as far as I’ll usually see).

  • For time (I.e. the implicit variable now) the Rules DSL uses Joda and imports everything in org.joda.* by default. You can find the javadocs for those in the Joda project’s website.

  • You won’t find too much OH specific. But for Items and States you will find the javadocs on the Eclipse Smarthome project website. Further info is available on the Persistence docs for persistence related functions.

  • For how the language works you have the overall structure of the files documented in the Rules documentation in the docs. For details like how to do for loops, lambdas, etc they’re is the Xtext documentation which use linked to front the Rules documentation page.

But day to day, most of us use VSCode, type the name of an object it expression and VSCode pops up a dialog with all the valid ways to complete it. For example, if I created a timer myTimer and typed in a new line “myTimer.” VSCode will have a list of all the methods available on the Timer object.

Lots of people do this using <insert favorite scripting language> and MQTT or the REST API. Personally I just use the REST API docs as I don’t have anything in my home automation that requires more than one event to test with.

Though I’ve written up a playback approach to use for presence simulation (i.e changing lights to make it look like someone is home) using a computer triggered rule and persistence.

I totally managed to miss this. Thank you! It might be nice if there was more cross-linkage between the “rules” section of the docs where I ran to try to figure this stuff out and the actions sections which is under addons, but I never thought to look there because I hadn’t installed any.

Genuinely impressed that this exists. I haven’t got an LSP integrated editor atm, but I will check it out at some point.

Yeah, I’ve seen a couple of people doing things like this, I’ll bear it in mind. Thanks.

I find flow based “visual” things to in the end always limit me in some way, so I am unlikely to be interested in using such a tool. I’d rather just write the code myself. I understand why others might prefer them.

I think this is a general difficulty with OSS stuff. People tend to be tinkerers and hackers, not designers. I couldn’t design or implement a nice UI if my life depended on it.

It would be great if you filed an issue:

Or even better a PR. :wink:


Also, @gbstoli, OH and the Rules DSL existed before NodeRed and therefore does and will continue to require support for legacy users. I’m constantly surprised by how many users steadfastly stay on OH 1.8. Finally, Rules are a core feature for any home automation. Requiring the installation of a third party server to get Rules support would greatly reduce the value that OH provides.

Definitely +1 on this. In order to have a uniform and well thought out overall design language like this you need to have someone to develop it, dictate it, and enforce it. In a OSS project most of what gets done is done by lone contributors working on a pet project to solve some problem they have. The OSS project cannot afford to refuse these contributions or else it will alienate the contributors and the project will die on the vine or get forked and all the developers will move to the fork.

It is one thing when you are a developer who is getting paid to contribute to a project. It is quite another when your project depends upon developers freely giving their time and efforts to the project. And with HABPanel it is even worse because each new widget is completely hosted and maintained by their developers in their own git repos. There is less central control for those then there is for OIH itself.

Well this is embarrassing. I go to make a PR and discover that there is totally a link to actions from rules. How did I miss that? ugghhhhh