Hey guys,
If anyone is interested in development in Scala, have a look here https://github.com/radi-ka/example_openhab_binding.
I just pushed a working example and plan to build on top of that in the future.
Cheers
1 Like
I’d be more interested in writing Rules in Scala.
From a technical perspective, is this approach something that could ever be installed and configured the same way as an “official” binding? There would be other problems (e.g. lack of knowledge by maintainers to be able to effectively review the code) but I’m more concerned whether this is another case of something that can only ever be something external to openHAB or whether it can become part of openHAB.
Hey Mirco,
first of all welcome and thanks for your experiment. I’d be interested in the result of your it and how easy that could be integrated. As it is JVM based I’m optimistic that there are no giant roadblocks.
Nevertheless we should keep in mind that (to become more than just an experiment) there needs to be a sustainable basis of maintainers who feel comfortable in reviewing and maintaing java code (compare Rich’s statement).
So interested to see where it can bring us and maybe in a later stage you make yourself familiar with the core and probably come up with an alternative solution to do rules in Scala 
As far as I understand the official delivery process there is one massive “addons” repo that is built using maven. The resulting bundles are then pushed to and served from some repository.
To integrate a scala project into the addons repo there needs to be a way to specify a compiler on a per project basis or to integrate with other build tools like sbt. Though my expertise with maven is very limited, I do think this might be possible somehow. Something like this would open the doors to all kinds of jvm based languages: scala, kotlin, clojure…
I think something like that would be a huge plus for openhab, but I dont think the current development / integration process would be able to manage anything else but pure Java. I am thinking of project complexity, best practies, reviews, …
Regarding rules:
I am not familiar with rules, yet. Until now I used openhab as a glorified UI and offloaded all the relevant events to my own application that would trigger actors. The respective bridges then sent their status changes to openhab. So, I did my own rule processing outside of openhab. This is actually the motivation for this project: figure out how I can do the processing within openhab.
my current idea is to:
- implement working scala example (check)
- receive websocket events from the deCONZ bridge(s) (manual thing/item configuration)
- processing
a. review rules
b. either use/upgrade the rules engine for my processing needs, or process events in some component that is connected to the event bus - automatic thing/item configuration
To begin my research on rules in openhab:
From your perspective: What is wrong with them?
Cheers
Rules DSL had a lot wrong with them but it’s not worth going over everything because they are already on track to be deprecated.
JSR223 rules which include Jython, JavaScript, and Groovy are pretty awesome actually. Most of my complaints are being actively worked by the maintainers. I’d like to have Scheme (or Clojure) as an option because it would be fun to code rules in a functional language. I always found Scheme and Common Lisp a joy to program in.
I don’t think there is a major roadblock in supporting these as jsr223 rules languages beyond no over had looked into adding the libraries to make using them convenient.
If you are looking to create a binding to house your own rules engine, IMHO, that is an abuse and misuse of what a binding is for and probably an abuse of the binding API. Bindings are not intended to sit on the event bus and process all events.
… IMHO, that is an abuse and misuse of what a binding is for …
Yes, I absolutely agree with you there. But it was the quickest solution to my problem when I first set my hands on openhab. But I have begun with iteration two to change that.
I don’t think there is a major roadblock in supporting these as jsr223 rules languages …
I just had a quick read of a few lines from org.eclipse.smarthome.automation.module.script and I agree. But I think for me as a developer it would be more intuitive and faster to just create a bundle that directly talks to the event bus and implement my logic there (I could almost copy and paste the code from my old project as it also used event sourcing).
Well, we’ll see… Got other stuff to do as well 
family, work, …
Except that work be a dead end. Such an approach would never become a part of OH proper. Constantly there would be an extremely limited set of users, probably just you.
As a developer using an open source project, wouldn’t it be better to code an approach that would actually contribute to the over all project?
sure, thats why I wanted to look into the rules engine in the first place. But I have some time constraints and may not be able to do that. But we’ll see.
Also:
I am not sure if scripting is a good solution for the rules. The advantage of scripts is, that you are able to modify them quickly. Downsides are that you still have to learn the scripting language or be somewhat used to programming. Also a whole lot of code complexity is added to support scripting.
Why not enable people, that are willing to learn coding or already able to, to write and deploy bundles quickly? A rule bundle could just sit on the event bus as the scripted rules stuff does, the openhab api could be reused. bundles should already support being deployed at runtime, so a modification of a rule would just take a few seconds depending on the compiler in use.
Have you seen the NGRE concepts? They will let non-coder users build their Rules graphically for the most part. Only for relatively complex behaviors would they need to write little snippets of code, and even then that is if there isn’t already a Rule template that someone who does know how to code hasn’t published yet.
For those who do know how to code, we have currently two Rules engines built in supporting four different languages (Rules DSL, Python, JavaScript, and Groovy). Outside of OH there are at least two more (NodeRed and HABApp). Once OH can advance to using a modern JRE we will be able to support pretty much any language that can be handled by GraalVM (which is pretty much any language supported on the JVM). Even now, the only thing limiting the use of other languages supported by JSR223 is that no one has done it.
I just don’t see what what you are proposing adds beyond what is already support beyond the fact that you don’t have time to learn how to use any of these and prefer to use what you know. I’m not saying that’s a bad thing for you, but as far as advancing OH, it’s a dead end for us. It’s not an approach that fits with the current architecture and design and therefore would never become a part of the distro.
Speaking as a user, any approach that would require me to compile my Rules as a separate step wold be a step backward, not an advancement.