Fun project: kotlin scripting for openHAB

We are tempted to integrate kotlin language with smarthome core. It will be an alternative to Xtend rule language we already have. Core syntax is as clean as Xtend. There will be smarthome specific DSL to deal with items, item states, things, channels and bindings. It will also be possible to write bindings in it.

Latest rule examples, re-usable rules and actual ESH-extension code will be maintained here

Those who are curious would find generic info here

I have also considered Eclipse/RedHat Ceylon but we already have Xtend from Eclipse. Kotlin is developed by JetBrains, the people behind IntelliJ IDEA. So the IDE support will be good.

More details in upcoming posts.

Improved newbie syntax in simple version of the rule
Rule level Timer and weekly scheduling support
TBD: Monthly and Yearly scheduling
TBD: Timers in rule and test actions
TBD: OH actions integration


I like the idea though worry about long term support to the plugin. Most of the ESH devs and maintainers do not seem to have much interest in supporting/improving support for languages outside of the up and coming Experimental Rules Engine. Even the current Rules DSL is mostly coasting (though the recent additions of triggeringItem and Member of Rule triggers are noted massive improvements).

That has been one of the big problems with the JSR223 add-on which lets us write Rules in Jython, JavaScript, or Groovy. You might find it useful reading to look through the JSR223 add-on code and issues as you embark on this project.

I’d like to see lots and lots of choices for writing Rules from Scratch to Lisp.

And while I like the idea and some of the things being done by Kotlin better than Xtend, reasons 0, 3, 4, 5, 8(ish), 9 (at least from the calling side), 13 (I think), 16, and 17 would also apply to the Rules DSL. And many of the numbers that don’t apply are because of the deliberate decision to not support classes in the Rules DSL (Xtend does have support for classes).

I bring this up not to bash Kotlin or prop up the Rules DSL, but to point out that what appears to make a language really useful is support for and existence of a vibrant ecosystem of libraries. So as you work on integrating it with ESH, don’t leave out the libraries, please! :slight_smile:

Good luck!

Kotlin does integrate well with Java libs, so no worries on that front. And I will develop bridging code that smooths integration between Kotlin scripts and ESH core. There is no huge re-usable set of libraries (like Perl CPAN) for Xtend either. So it should do fair against it.

So does Xtend, but the Rules DSL (remember Rules DSL != Xtend) only gives us access to core Java libraries, Joda, and ESH/OH core libraries. I wouldn’t want that same limitation with Kotiln Rules. That was my main point.

With JSR223 languages managing libraries like that isn’t so hard, just download them and put the files in the right spot. For something like Kotlin though, especially if we are talking about only importing Java libraries in jar files we now need to mess with classpaths and the OSGi container and all the stuff that makes getting access to Java libraries in the Rules DSL all but impossible.

You are worrying too much. :slight_smile: It will all be handled. The primary goal here is give users a good tooling/debugging/testing support at development time. You are talking about runtime, that can always be handled/developed, nothing is frozen in stone, otherwise we wouldn’t be here developing new things.

OH, I thought you were talking about adding an alternative to the Rules DSL.

And as I see it one of the biggest weaknesses of the Rules DSL is it’s lack of the ability to import libraries we can use in our Rules.

This is a feature that has been requested for the Rules DSL since at least OH 1.5 but the technical hurdles were big enough that it is one of the reasons that Kai has abandoned the Rules DSL in favor of developing the Experimental Rules Engine, which does support libraries.

But if it is something that is a mere trifle to handle, please add it to the Rules DSL as well while you are at it.

It will be a generic programming environment. Not just site specific automation rules, you could write bindings as well. I chose kotlin because there are people willing to stand behind it (JetBrains team). JSRs and JavaZ specs always come “after” something has been successful in the market. Java copied most Spring/Groovy concepts and called it Java7/8, JEE 5/6 and JSRs. Copycats!
I wouldn’t give much weight to JSRs than the individual teams/communities like Scala/Kotlin.
Xtend is something that I know for sure, it sucks. Its a personal opinion. :slight_smile:

This was one area where JSR223 ran into well. People wanted to enhance support to make it easier to write add-ons in those languages and they ran into strong resistance from the maintainers of ESH and OH. I don’t know the details. If @steve1 is still around he might share some of his lessons learned. I don’t know for sure, but his experiences may have contributed to his moving on to another HA system.

OH is a project populated with people. Sometimes that makes things hard.

Let me first create a working proof of concept and then we will see if we as a community want to invest more energy on those lines. I primarily want kotlin for my own offline IDE only testing purposes. I want to make sure my binding code doesn’t produce regression issues if a new feature is added. I should be able to create simulated devices in order to ensure protocol compliance of a binding/gateway etc without actually deploying anything anywhere. It should be simple to write test cases. Kotlin strikes me as a good candidate supported by good community/team. Any other suggestions are welcome. Scala anyone?

1 Like

Could you by any chance provide a repository with your changes? I am just getting in touch with the whole openhab2 code and I think kotlin would be such a great improvement

Sure Michael. It will all be open source.

I don’t want to burst your bubble but I’m not sure if Kotlin would be a good choice, while it may be easy to implement with the existing code and i’m all for using leaner, more modern languages than Java and offer something more flexible for rules, it’s not a very popular language either, it was hyped a year ago amongst android/java devs but barely made it the top 50, which means we might have Rules DSL all over again. Too hard for the normal user to learn and too quirky and unusual for the common dev. Something with a less steep learning curve and a brighter future might be more suitable. Anyways i use a lot of Jetbrains stuff and i’m open to new ideas, would love to see your efforts.

1 Like

Kotlin is backed by JetBrains (the people behind IntelliJ IDEA) and Google Android community. Thats what matters. Top 50 charts you got. that is for songs, not frameworks. You gotta have people and teams standings behind it for years. Kotlin’s got that. Thats why I chose it over Scala.

Proposals will be maintained below. Most of it is done already. Rest is also perfectly doable. Suggestions on readability improvements are well-come.

Code will appear in same repo soon

Improved newbie syntax in simple version of the rule.
Removed dash - from entity names for code conventions
Better naming of syntactic constructs
Rule level Timer and weekly scheduling support
TBD: Monthly and Yearly scheduling
TBD: Timers in rule and test actions
TBD: OH actions integration


Moved to .kt file from .txt, turns out github likes kotlin :slight_smile:
Updates today

  • Improved newbie syntax in simple version of the rule.
  • Intelligent command dispatcher introduced
  • Weekly schedule spec moved from string to native kotlin syntax
  • Added timer support (periodic executions)
  • Improved offline testing support

What about timers? They are pretty critical to any home automation rule.
And also the OH actions?

Timers in actions clauses are coming soon. Kotlin has many paradigms here: async functions, threads, timers, co-routines. We can leverage co-routine feature to reduce load on JVM/OS level thread allocations. I am thinking on it.

All the standard routines available in current rules dsl will also be available in Kotlin integration. e.g map service, sendCommand function, they will work mostly by just copy pasting.

Lambdas from Rules DSL, you may need to convert a little bit. I will document how to do that.

I am really looking forward to playing with this
What I meant are the OH actions like, say(“blahbla”), executeCommandLine(xxxx)…
These actions:

Ahh, those actions. Sure, why not. As long as those are written in Java, I have no problem integrating those actions.

Yeah, they are pretty key to a smooth migration of rules from DSL to koitlin
They are almost like key words of the DSL

1 Like