OH 3 Examples: Writing and using JavaScript Libraries in MainUI created Rules

[rlkoshak (Rich Koshak)]

@Redsandro

Although I’m still somewhat disenchanted from all the verbosity we need in our ECMAscripts, such as (1) downgrading scripts from other projects to 2009 ES5 even when running the latest version of openHAB, (2) needing to import a special logger rather than just extending console.log as in other projects in every script, or (3) requiring 6(!) commands just to run another script as defined in the UI. These are my first annoyances as a brand new user, so it feels a bit like sharp edges that could have been sanded by now.

Well, the above is for Nashorn JS which is:

• what comes with Java 11
• hasn’t really been touched in many years by the Java maintainers
• is deprecated and is completely gone in Java versions past Java 11

If you are getting started now, you should use the JSScripting add-on which is the latest ECMAScript, comes with a helper library (instead of needing to install one separately) that makes it easier to interact with OH, supports npm to install libraries, and soon (I think there’s a PR) will support console.

Nashorn is and has been a dead end for quite a while. Not a lot has been written on it because doing so will take a huge amount of effort for something that will be gone in a year or two anyway. Now that we have the JSScripting which I and others will push to make installed by default in OH 3 I plan on writing some more and more official docs for it.

This and other tutorials I’ve written were mostly intended to be stop gaps until a more permanent solution was implemented. Nashorn is definitely going away when OH moves off of Java 11. Jython will break at some point and won’t be fixable since it’s all but abandoned by upstream (and it’s Python 2.7 which is end of life). jRuby is only now starting to pay any attention at all to UI rules. Rules DSL is not fully capable. Blockly is great but itself renders to Nashorn and needs to be updated to render to something else. JRules do not and never will support the UI. Java Scripting does support the UI but is only available in the Marketplace.

The only candidate right now to become a default rules language is JSScripting. So over the past couple of months a ton of work has been put into it to make it suitable for writing in .js files and for creating rules in the UI in a way that will still support third party libraries from npm without placing too much of a burden on those writing Script Actions and Script Conditions in the UI.

@Redsandro

Because if you start from scratch in OH3, you never get to write those OH 2 things or create those files. So these examples in the community are really helpful.

Yes you do. You can write all that stuff in the same files in the same ways in OH 3. All the UI stuff in OH are new capabilities that were added in addition to what was supported in OH 2, not in place of.

@Redsandro

So I thought I’d share my first little library script that helps sending notifications from Matrix/Synapse so that it may help someone.

It will be much easier for others to find if you post it as a separate thread under Tutorials & Examples Solutions. Not only will it be easier to find but it will be easier for you to help others who want to use it and for you to post updates and such.

If you decide to jump to the bleeding edge a little bit, see Migrate from Nashorn to JSScripting for UI Rules, GitHub - openhab/openhab-js: openHAB JavaScript Library for JavaScript Scripting Automation, and most of the work being done is covered at GraalVM JavaScript replaces Nashorn, breaking Blockly and existing Nashorn rules · Issue #2433 · openhab/openhab-core · GitHub with links to three outstanding PRs that I’m waiting for before I jump head first into building some proper docs.

You might consider turning this into a Rule Template. Then a user can install it from the Marketplace just like an add-on. With JSScripting (or even Blockly) it’s easy to call a rule from another rule and you can pass data to the called rules. So a user could install the template, instantiate it, and then call it using a one liner from the helper library.

Alternatively it could be distributed as an npm module with JSScripting and users can install it using npm.

@Redsandro

In my opinion, a broad range of notification services should really be built in using a single dedicated library like Apprise or Shoutrrr. I’ve opened a feature suggestion, so give it a thumbs up if you think this is a good idea.

As for this, if you intend this to be built into the core then you filed the issue in the wrong place. It would need to be filed in the openhab-core repo. However, I don’t think this is something suitable for core and implementing it as an add-on is the correct approach.

Apprise isn’t an option for an OH add-on because it’s written in Python. Shoutrrr isn’t an option for an OH add-on because it’s written in Go. OH is written in Java and OH add-ons are written in Java. Obviously one could run these as a separate service with an API and an OH can interact with that separate service via an add-on. That’s how MQTT works. But these cannot be embedded into OH itself.

As for your comments in the issue, OH takes an agnostic position re cloud services vise self hosted services. We neither encourage nor discourage either approach.

But, as with everything in an all volunteer openSource project, having a good idea isn’t enough. Someone has to volunteer their time and effort to implement it so it’s pretty rare that a mere feature request ever goes anywhere unless it’s backed up by a PR. So if you feel strongly about this feature you’ll probably need to code yourself or find someone to code it for you.