Fun project: kotlin scripting for openHAB

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

EDIT
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

2 Likes

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

Should we allow calling Jython and JavaScript (Rhino/Nashorn) code? I am not yet sure. It will confuse users. JS is primarily UI libs and their backend nodeJs libs, most of them primarily target web-site development. Utility libs from JS, like collections, dates, are already available in Kotlin.

But Python has many scripts and modules useful in home automation, at least that we should consider.

I’m a few hundred lines away from completing a Rules DSL to Jython migration (~6000 lines), so I’m a little invested in Jython right now. If Jython could be called through Kotlin, it would make a nice stepping stone for migrating. And using updated Python libraries would be very enticing! At almost every turn, I’m running into newer Python code examples that won’t work in the outdated Jython. Hmmm…

I like what you did with the rule structure, especially the triggers! I’ve made a single Jython decorator that will handle most triggers, and I had started to work on a more Rules DSL-like trigger format.

1 Like

I have revised structure such that only a few programming and OH concepts need to be learned by newbie.
Now Thing Label is also supported as device locator, as long as they lead to unique Thing - which should be true for most users.

Will look into Jython integration. I also suspected Jython and Python may not be always compatible. But still the working code in Jython is also huge, I myself have some.

1 Like

At the risk of being pedantic, there’s something about the use of the word “turn” that seems off to me. Yes, an argument can be made that it’s commonly used in the English language such as “Turn on the light.” or “Turn off the radio”. However, its usage is narrow. The example above highlights what I mean. To turn a light to 60 percent sounds odd.

Wouldn’t “set” be more generic and applicable to a broader group of devices? For example, “My Kitchen Timer”.set(15.minutes) reads better than “My Kitchen Timer”.turn(15.minutes). It remains clear in other circumstances: “Furnace Fan Speed”.set(50.percent), “Pool Pump”.set(ON), “Ceiling Lamp”.set(25.percent).

Anyway, just food for thought.

1 Like

I know. There is sendCommand() too as an alias to turn() function. Set seemed more natural to me too but I was afraid it could conflict with something that is already there on String type or some other extension lib could choose the same in future, then we have a regression situation. And since we do want to support intelligent type casting, the input parameter type I cannot use just smarthome specific base State Type or Command Type. I wanted numbers and strings too as acceptable types of turn()/sendCommand()/updateState() overloaded functions. Note that updateState() doesn’t send command. I need some more natural name for it too.

Any other more appropriate name you can think of for turn()? I had used cmd() as a shorthand. Short names come in handy because newbies are less likely to go through IDE setup process. They will be typing in basic text editors for 10 liner rules.

How does setTo() sound?

Another IDE
What about VS Code integration?

1 Like

From my point of view IntelliJ is the recommended IDE for anyone who wants to develop complex rules and Kotlin Apps. Maybe Eclipse and VSCode work equally well with Kotlin. All are open source projects. We will get there, one step at a time.

For copy and paste 10 liner rules, things are just fine without IDE. Thats why I have removed as much programming noise from syntax as I could.