User enhancements

[rlkoshak (Rich Koshak)]

@Andrew_Rowe

Is time learning to write rules in dsl wasted time?

Not at all. One of the not very well held secrets is once you know how to program in one language, you can quickly come up to speed in pretty much any language. The overall concepts are the same. If human languages were the same, you could learn to speak French by learning a dozen new words and a handful of grammar Rules. Most programming languages are very similar in structure and how they are used.

With the JSR223 libraries, you can even build Rules that look a lot like Rules DSL Rules.

@Andrew_Rowe

Should I go check JSR223 out?

Yes. It is very much worth looking into it.

@Andrew_Rowe

My understanding it I can use javascript, groovy or one other as well? I already know some js

Python is the third. The libraries for Python are a little more mature than for JS and it does let you write Rules that look more like Rules DSL Rules. But the JS library is pretty complete and works well as well.

I believe that we (Scott and myself) will be pushing to make Python the “default”, but all three will be supported as first class citizens.

[Andrew_Rowe]

@rlkoshak

Python the “default”, but all three will be supported as first class citizens.

ok, I like that to

@rlkoshak

If human languages were the same, you could learn to speak French by learning a dozen new words and a handful of grammar Rules.

wouldn’t that be cool, I wish
I started in qbasic in the 90s, AutoLisp (architect by trade) VB, VBA in the 00s web stuff, C#, taught myself PHP and wrote a mySQL powered 100% dynamically generated web sites, BASH for commission mail servers, CentoOS, Fedora was my playground, learning Deb for openHAB, rusty been a few years

[rlkoshak (Rich Koshak)]

@Andrew_Rowe

AutoLisp

OK, so maybe Lisp doesn’t translate so well. I love functional languages but they are different enough that they break my simile.

Lisp

[Andrew_Rowe]

umm… AutoLisp was a sub langauge of Lisp create to run inside AutoCAD (AutoDesk product - vector drawing) It is paretheses delimited and nestable, super low level but the drawing database was a list of lists and lisp (list processing) work superbly for the task. It was uber hard to learn but stupid powerful and fast. A lot of the application’s native commands are themselves still written in it

[rlkoshak (Rich Koshak)]

@Andrew_Rowe

It was uber hard to learn but stupid powerful and fast.

That’s Lisp and it’s derivatives in a nutshell.

I’d totally write Rules in Clojure or Scheme or the like if it ever becomes supported. I’d never push for it, but would totally use it.

[Andrew_Rowe]

those comics are a riot… we used to have contest for best one liners and stuff it was fun

Clojure or Scheme?? you lost me off to google

[Andrew_Rowe]

@rlkoshak

That’s Lisp and it’s derivatives in a nutshell.

this particular variation had no error handling (is that the norm?) in 2K MS pushed AutoDesk to implement VBA, is smelled really nasty and worked less well then it smelled. Ten years later, MS changed up there mind. AD had invested… firms had invested… much gnashing and grinding of teeth ensued.
but yeah, I liked lisp, car cadr cardrr ()())(((()))) counting parentheses until you went mad, I couldn’t write a line if you held a gun to my head anymore but remember I liked it

[5iver (Scott Rushworth)]

@Andrew_Rowe

I know nothing about JSR223 but what I wonder is could rules dsl or JSR223 be enhanced similar to what jquery did for javascript? Not a direct example of what I talking about but more of a make easy things really easy and make hard things much easier.

Previously, all automation in OH was scripted using the rules DSL. There is now a new rule engine, where there are more options, including using the REST API, which can be used by a UI to generate rules. This is an abstracted way of building JSON resource bundles, which are ugly and complicated and nobody will want to write them by hand. So how to do scripting? JSR223 to the rescue. Pick a supported language, Jython, Javascript and Groovy are popular, and you can write scripts. There are also language specific helper libraries that remove much of the complexity of interacting directly with the Automation API, just as the DSL did for the old rule engine. These helper libraries are providing functionality that will be absorbed into OH by migrating them into a new scripting API and ModuleTypes, so that all JSR223 languages have access to them.

JSR223 allows you to write scripts that create rules, or it can be used inside rules, but it can do MUCH more. In the new rule engine, there are Modules (Triggers, Conditions and Actions), which are further broken down into ModuleTypes. I am wrapping up ModuleTypes that will allow a script made with any JSR223 language to be used in a Condition or Action. I am also working on bundles to ease the installation of Jython, Groovy, and the helper libraries. After those, I plan to address the scripting API and creating more ModuleTypes (aka, more options in the dropdowns when building a rule in Paper UI).

@Andrew_Rowe

Not a direct example of what I talking about but more of a make easy things really easy and make hard things much easier.

Layers of abstraction… these are being built so that you can drag/drop, point/click, etc. your rules in a graphical interface, or so that you can do complex things in a script with simple commands. The rules DSL provided abstraction for the old rule engine. For the new rule engine, there are ModuleTypes (mostly for use in the graphical interface), a scripting API, ScriptExtensions, and language specific helper libraries for areas where the API has not yet been built out.

@rlkoshak

The libraries for Python are a little more mature than for JS and it does let you write Rules that look more like Rules DSL Rules. But the JS library is pretty complete and works well as well.

The Jython/Python libraries are a LOT more capable. We will need JDK9 support, which includes ECMAScript 6, in order to built out the same functionality into the Javascript libraries. If the other maintainers agree on it, I plan to rename the https://github.com/OH-Jython-Scripters organization to OH Scripters, and include repos for all of the languages, so that there is a single place to go for helper libraries, scripts, examples, rule templates, etc.

[rlkoshak (Rich Koshak)]

@Andrew_Rowe

this particular variation had no error handling (is that the norm?)

Lisp is programming distilled to its most rarefied minimal set of features. Errors are just a special case of a condition.

@5iver

Previously, all automation in OH was scripted using the rules DSL.

This post is 90% of the way to a “Getting started with JSR223”. It’d make a grate tutorial. Then we can link back to it every time this topic comes up. I’m actually wanting to start pushing JSR223 a little harder than I have over this year so we have a little more of a user base by the time OH3 comes out.

Maybe wait until your WIPs get done?

@5iver

If the other maintainers agree on it,

If you need a :+ I’ll add it to the issue.

[Andrew_Rowe]

@5iver

these are being built so that you can drag/drop, point/click, etc. your rules in a graphical interface, or so that you can do complex things in a script with simple commands.

this will be a boon for noobs and OpenHAB’s more broad adoption

@5iver

I am wrapping up ModuleTypes that will allow a script made with any JSR223 language to be used in a Condition or Action. I am also working on bundles to ease the installation of Jython, Groovy, and the helper libraries. After those, I plan to address the scripting API and creating more ModuleTypes (aka, more options in the dropdowns when building a rule in Paper UI).

sometimes folks like us are to buried in our own OpenHAB journey to forget about folks like you who are blazing the trail out a hundred miles ahead of us… thanks… sounds exciting I’ll be checking this out tonite when reading time is greater

[Andrew_Rowe]

@rlkoshak

Lisp is programming distilled to its most rarefied minimal set of features. Errors are just a special case of a condition.

very well put Rich

@rlkoshak

This post is 90% of the way to a “Getting started with JSR223”.

I agree, excellent explanation Scott, thanks and pity if it was lost in this silly thread.

[5iver (Scott Rushworth)]

@rlkoshak

If you need a :+ I’ll add it to the issue.

Not OH maintainers… OH Jython Scripter maintainers

@rlkoshak

Maybe wait until your WIPs get done?

Yes… best after the 2.5 M2 build. I’m not sure if the Jython bundle will be ready by then, but . There is a lot more in my head and on paper, but small bites…

Once I’m past the current bottle neck, I’ll work on a flood of communications/documentation.

[rlkoshak (Rich Koshak)]

@5iver

Not OH maintainers… OH Jython Scripter maintainers

Just point me in the right direction and I’ll :+1 where ever it can do some good.

[David_Graeff]

Hopefully those posts here doesn’t get lost. They would be wonderful introductions for openhab.org/docs.

[5iver (Scott Rushworth)]

@rlkoshak

where ever it can do some good.

Actually, you could help me bug @lewie about Migrate repo to OH-Jython-Scripters? · Issue #4 · lewie/openhab2-javascript · GitHub .

[rlkoshak (Rich Koshak)]

Done

[5iver (Scott Rushworth)]

@Andrew_Rowe

this will be a boon for noobs and OpenHAB’s more broad adoption

This is a stepping stone to collaborating on rules through the use of rule templates, which are currently functional. All of the basic rule examples can be shared as a template, potentially even included in the distribution. Instead of sharing rules as text in the forum, they can be shared as a link to a template that can be installed. Templates will be able to include scripted Actions/Conditions, and people using the templates won’t need to know anything about Jython, JS, Groovy, Kotlin, etc., but just use a dropdown to select which of their personal Items/Channels/Things/time to trigger on.

The future of OH that I see, especially automation, is very bright! There is a LOT of really neat stuff just around the corner.

[Andrew_Rowe]

@5iver

Instead of sharing rules as text in the forum, they can be shared as a link to a template that can be installed. Templates will be able to include scripted Actions/Conditions, and people using the templates won’t need to know anything about Jython, JS, Groovy, Kotlin, etc., but just use a dropdown to select which of their personal Items/Channels/Things/time to trigger on.

Scott… that has AWESOME written all over it!!!

[christoph_wempe]

I haven’t read the whole topic but I just had a thought and I think it would fit here.

Is there something like “IFTTT on premise”?
Maybe the “new rule interface” could be inspired by IFTTT.

I haven’t used IFTTT either.

[Misiu]

Currently bindings/addons release cycle is closely linked with openHAB release cycle.
Now, when there is a bug in binding and it gets fixed we have two options:

• manually install that binding
• wait till next release of openHAB

I’ve started wondering: maybe add-ons/bindings could be separated from the main bundle?
Wouldn’t it be awesome if we could create, version and build each binding separately?
This would allow to quickly deploy fixes and new features.

Currently in Paper UI in bindings You see all bindings that are already there, all You must do is just enable them. Why not list bindings/add-ons/etc that are available to download?

Take a look at nuget, npm and others. Each binding is already built, it has dependencies listed, so it could be easily downloaded.
I know that bindings heavily relay on openHAB version, so each package should have minimum openHAB version requirement. This is how NuGet works - if You have a .NET 3.5 application You won’t see packages that require .NET 4.7.
Node-RED has this type of nodes management mechanism.

This behaviour would also allow UI to inform user about new version of bindings, so he could update it with single click.
Bindings/addons could be marked as prerelease so developers will be able to easy distribute new binding to testers, faster gather feedback and finally finish and release finished binding faster.