How to get started with new scripting?

Setup, Configuration and Use Scripts & Rules
, ,
Tags: #<Tag:0x00007fc900945338> #<Tag:0x00007fc900945270> #<Tag:0x00007fc9009451a8>
#1

Hi all

As I don’t like the current Rules DSL I finally took some time trying to switch to the new rules engine. But digging deeper I’m just lost now, the more I read the fuzzier it becomes. Actually I was hoping that it’s part of the docker image by now, ready to use :wink: . I went over endless threads, different OH wikipages and github repos of unclear origin… Unfortunately still not really a clue what is the way to go now… the situation is unclear, what is still valid, what is outdated by now? (And the whole thing seems pretty hacky…)
And finally I’d like to avoid starting off with something that’s going to be a dead end when migrating to OH 3 and having to start all over again.

I’d be grateful for suggestions what to choose and where to start with the below preconditions! Is it easier to get started with scripting with OH3, i.e works out of the box?

I run OH from the docker image. Still 2.5, as I’m somewhat hesitant to switch to 3. Language wise Python and JS seem to be the sane choices, either one would be fine. I would go with whatever is easiest to use in OH and offers the most possibilities, and of course is future proof.

Javascript: Apparently ready to use without additional installs? On the other hand said to be removed with next Java update. Whatever that means… Also the examples look very… verbose. Lot’s of boiler plate code for a simple rule.

Jython (why not just call it Python?): Nice decorators, but “only” through that community helper lib (if I understand it right).
On the other hand only Python 2.7., complicated installation and the general (political) situation around the Jython addon seems somewhat unclear. And I suppose every update to the helper libs needs to be done manually, as well.
Neither seems absolutely convincing. Leave alone maybe other issues with either one I have not yet come across…

Any guidance appreciated!

Thanks

Michael

#2

Not gonna make it easier for you, but there are also JRuby (the newest unofficial env) and HAPapp (Python3 but run in a separate process and use the OH REST API). There is also Node Red (not a scripting env per say that also communicates with OH via the REST API).

Ultimately you need to make the decision yourself based on the pros and cons. I am in the progress of moving from Jython to HABapp. No env is perfect, this is why it is quite difficult to make decision :). In OH, we suffer from the problem of too many choices. Quite a luxury I would say.

#3

I think I would like to stay within OH and not add another layer of complexity if I can help it, so that would rule out HAPapp or Node Red. Ruby, well, didn’t do much beyond Hello World or fixing some bugs mainly by educated guessing :wink: But if it’s maturity wise more advanced than Python or JS, then I can sure learn what’s needed for OH. “Newest unofficial” doesn’t sound like that, though…

My problem is more that I’m a bit lost in available information, or the lack there of, in order to be able to make a decision…

#4

Generally depending on an external language that is implemented within Java is not ideal, as typically the implementation can’t be maintained to catch up with with the official native implementation. This is the case of Jython; it will be forever stuck at version 2.7. GraalVM is the solution, but it will take a while.

In OH, the official Java is in API. My guess is that the REST API is meant to be the official non-Java API initially. Then we have the various languages implemented with the JVM and can access the Java APIs directly (rather than going through the REST API). One thing to note is that all these scripting environments have a thin layer that wrap the interaction with the Java API. As such, if you structure your rules in such away that they stay purely within that language (e.g JS or Python), then it is less painful for you to have to adapt to changes later. This can be done by introducing an additional layer of abstraction.

I understand you’re not interested in HABapps, but I think this post I created couple days ago is still somewhat informative, as I did come from the Jython side.

#5

Thanks for the link. Reading it, maybe I should reconsider…
The JSR223 horse seems dead before it even really started. Even with OH3.

#6

JSR223 isn’t dead. GraalVM is newer and would let us have Python 3, but that is a ways down the road yet. Migration from Jython (Python 2.7.2) to Python 3.x will probably be fairly seamless, same as migrating from those versions in CPython.

Between JavaScript and Jython I would suggest Jython. The Helper Libraries are more developed, and there is a PR that makes them compatible with OH3.

There is work on getting ES6 available via GraalVM, but that’s not merged yet, if javascript is more your style. There are some helpers written by the same guy but you won’t find many examples of that yet since it’s all pretty new.

#7

JavaScript comes out of the box. Jython and Groovy can be installed as add-ons. The Helper Libraries are not yet released as add-ons and the main branches are not yet compatible with OH3. But for Jython at least there is a PR to update it for OH 3 support.

None of the four supported languages (five if you count Blockly) are a dead end.

Yes, the “Experimental Rules Engine” also called the “Next Gen Rules Engine” is just The Rules Engine for OH 3. The old Rules DSL engine is gone and the Rules DSL language has been ported to the new Rules Engine.

To be replaced with GraalVM Java Script which will also result in an updated version of JavaScript. There is lots of work on this front ongoing. I would expect the changes required when that happens to be relatively minimal with the main difference being in how the libraries are loaded. Most of the complex stuff comes from interacting with openHAB and those won’t be changing.

A lot of that goes away when using the Helper Libraries and completely goes away when creating rules through the UI.

Because it’s a specific implementation of Python 2.7 that runs on the Java Virtual Machine. Eventually, if it does not gain some support and activity to implement Python 3, Jython will likely be replaced with a GraalVM Python. Again, when it comes to rules, most of the differences between Python 2.7 and 3 will be relatively minimal as most of the complex stuff comes from how one interacts with OH itself which won’t be changing.

Correct.

It’s just an add-on you can install like any other now. Even on OH 2.5, there is an add-on available on the Eclipse IoT Marketplace (you can get access to the Marketplace through it’s own addon under Misc in PaperUI).

There is work being done to make the Helper Libraries an add-on. But until then yes, you’ll need to manually update the Helper Libraries. Depending on how you install them, that could be as simple as a git pull on the command line.

OH support of jRuby is currently in work and not as mature as Python or JS support.

I started a tutorial for doing JavaScript without Helper Libraries (since there weren’t any yet) a long time ago that is still mostly relevant at Experimental Next-Gen Rules Engine Documentation 3 of : Your First Rule which shows how to do most of the stuff you need to do in Script Actions and Script Conditions.

A large portion of the Helper Libraries revolve around the creation and management of Rules. All of that is done for you in the UI so most of what you need from the Helper Libraries is gaining access to stuff like the MetdataRegistry, Actions, and stuff like that.

1 Like
#8

This is only true for OH2, there is no Helper Libraries addon for OH3. That said, with the Python addon in OH3 you no longer have to play with the path variables, {OH_CONF}/automation/lib/python is already added by the addon.

I actually prefer the Helper Libraries being outside an addon, that way you can modify and update them at will. If they were in an addon it would slow down updates and make modifying them more difficult on a running setup. The other side of that is that not everyone wants to modify them.

#9

My understanding was that there was an add-on for 2.5 on the marketplace and for 3 the add-on is in work. Is there not one planned?

By not being available as an add-on they essentially become useless to those who are advanced enough to understand the utility of a library but not confident enough to work with text based rules.

Given the number of people posting about how they are moving to UI rules, even those who already have working rules in Python and JavaScript, I suspect UI rules users are going to be the majority.

I don’t think there is anything that is preventing both approaches being supported. But if no add-on is forthcoming the Helper Libraries will not be all that helpful to all of those users until such time that we have a marketplace and they are made available there.

Even for me, I’ve been struggling not to recreate the Helper libraries on my own in my efforts with my own rules and my rules_tools libraries.

1 Like
#10

Thanks for shedding some light on this. So for now I’ll try to get the Jython going, and see what the situation is like when I switch to OH3 when it has matured a bit.

In my opinion the helper libs, esp things like decorators, are required to make the scripting worthwhile. It’s too much boiler plate code and verbosity otherwise. I mean I’m looking into the new languages not for the sake of it, but because I would have an improvement over that weird Rules DSL. Not to trade one pain for another… :slight_smile:

Well, the rules engine itself is only so useful, if I have to manually figure out and install interpreter libs or helper that make it useable (see above). The engine itself is already available as add-on with 2.5 (which would be sufficiently out of the box).

Yea, but as I understood there are not a lot helper libs other than for Python :wink: And programming is just fine, I do that for a living (That’s why I’m looking for a proper scripting language). The, somewhat annoying, challenge is to dig through all the information and hack to get it to run.

But in the end it’s Python? The actual interpreter should be an implementation detail, which should be referenced somewhere in the docs, to be aware of subtle differences, sure. But reading here or in wiki pages it’s everywhere and it sounds like it is an own obscure language (or maybe it is? never used it…).

Hmm ok, I only found that beta add-on. Downloadable from some unknown Google drive, and only if you have a Google account (not the case, not going to happen)…

#11

IMHO at least parts of the helper libs should just be an integral part of the supplied scripting environment, like the decorators to allow to write compact and clean rules. Then there would not be a lot of need for updates.

Other parts, that are not specific to a certain language, should be language agnostic add-on/modules anyway. And a more flexible update mechanism for add-ons, aside from OH upgrades, might be a good idea anyway.

1 Like
#12

Honestly, I’m not really here to discuss what should be. For all discussion about should I’d request moving to Github and filing issues, or even better start implementing PRs. I pretty much only talk about what is and in some cases what appears may be in the near future. Should is almost always a matter of opinion and any discussion about should devolves into argument.

The current state is that the Helper Libraries are separately maintained and not yet a part of the openHAB project itself. For OH 2.5 I think they are available on the IoT Marketplace. They are not yet available in OH 3. I believe the plan is to make them available via an add-on.

As I’ve already said, Rules DSL and JavaScript (and Blockly) come out of the box. All other supported languages can be installed as add-ons from the Automation category of Addons in MainUI. Python at least can be installed as an add-on once the Eclipse IoT Marketplace has been installed. I don’t know what category it appears in.

There is no requirement to manually install the language support beyond selecting the add-on and clicking “install.”

There is quite a lot for JavaScript too. Where it is weakest is in creating Rules in .js files. But when working in the UI, you don’t need to create the rule. All you need to code is then “execute” function. All the rest is handled outside the code. If you want to write text rules, Python is probably your best bet. If you are very much against “boiler plate” you would probably be happiest with the jRuby efforts.

#13

Yes, there is one on the marketplace for 2.5. What I meant is that there is not one available for OH3, not that there won’t be one. I was also not aware that the marketplace was available on OH3.

Good points, I think having both offerings would be best. On the dev side it would be more work to have both since I think the code in the add-on is Java but the libs are in each scripting language. I don’t know much though, I have had no involvement in the helper libs add-on so I don’t know what’s in it.

#14

Oh, it’s not and I didn’t mean to imply it was there yet. There is a replacement planned but not developed yet. But based on the discussions it should support more than just add-ons and include widgets and libraries and rules.

I’ve no doubt there is some Java code, but I don’t see how one can implement a Python annotation in Java. There almost had to be Python code in there somewhere and somehow it seems.

1 Like
#15

Consider looking at HabApp