Support for JSR223 Scripting

[ThomDietrich]

Hey!

At the Smart Home Day the question came up if/when the vscode extension will support JSR223. Just wanted to leave the question here for later discussion. See http://docs.openhab.org/configuration/jsr223.html

For help and/or guidance @steve-bate might be the right guy to trigger 😃

[kubawolanin]

Hey Thomas!

Never used it, will need to take a closer look at it first. However, if anyone's willing to implement it now, hers's some guidance:

• It might be worth to create a new set of snippets for js, py and other files that are stored in $openhab-config/automation/jsr223 folder
• It would be good to detect if a new rule engine is installed. The best way to do it is with hasExtension method with misc-ruleengine parameter. If promise returned true, proceed with attaching JSR223-related disposable.

[Confectrician]

Hey @openhab-5iver,

Pinging you, because i want to go on with this in the nearer future. I think we need to adapt some things, to get openHAB support into jsr223 files, since they have no special openHAB file endings.

vscode has the concept of so called "embedded languages", which was designed to get js/css support in opened html files. I think that's exactly our usecase for JSR223. We have some kind of file (groovy/js/py) and want to get some openHAB language features inside.

I will take care of the extension part, but it would be nice if you and other helper liebraries contributors join forces with me and the extension and get some progress, especially for the language definition. I have some rough ideas of how that could look, but this is all early state. Maybe you could ping some names in here, who should discuss together with both of us about how it should be done and what should be included for supporting JSR223. :)

[5iver]

@Confectrician, I'm honestly not sure what all would be required for this, but since the helper libraries will eventually be going away with the introduction of a Scripting API, I'm not so sure this effort would be worthwhile. Do you have some links describing what you are looking to do, or just some usecases? Is it something like autocompletion and hover for the HLs and scripted automation?

[Confectrician]

For now we only have the things/items browser available in jsr223 files. I enabled the sidebar on a permanent basis, when one has restApi enabled.

Embedded language: https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide#embedded-languages

will eventually be going away with the introduction of a Scripting API

There is much could be in here. 😄 So i would not care about what may be in some kind of future. We have jsr223 now and there are helper libraries now.

I have no roadmap available now, since i know only my personal needs. But this is not the confectrician extension, so i need input from others. Who should we ping for more input? I would guess @rkoshak could give some input too. Do you know others? What basically would be interesting (from my point of view):

• Snippets for common structures (e.g. a rule template)
• Syntax Highlighting for openHAB specific structures (which is probably not that easy)

But i would guess there is more that could be done.

[rkoshak]

Having spent some time with Python rules at least, some of the things that would have been nice:

• Item and Thing/Channel awareness. That's kind of tough though as the "Item" are just Strings for the most part. Want the Item's state? items["MyItem"]. Want something else from the Item? ir.getItem("MyItem").members. They are not just "naked" Item names so I imagine this will be quite challenging to capture in the extension. Even the Triggers are String.

• Auto imports would be nice. Back when I coded in Java I remember there was a key combo to automatically import a class you've just referenced. That would be a nice feature since unlike with Rules DSL there are a number of imports that are required to build a Rule. Again, imports with Python are quite a bit more complicated so it might be tough in an extension to handle that.

• I have a Python Linter installed and as far as I can tell operational, yet I still have to exercise every line of code to ensure there is not some typo that would have been picked up automatically when using Rules DSL. I suspect this is just a limitation of Python so there isn't much that can be done, but it will hang up a lot of new users and migrators.

• Snippets are a good one. Definitely creating a Rule. Creating a Timer would be handy. Maybe even populating a whole file with imports, a Rule, and stuff like scriptUnloaded(). I can't really think of any others. I'd need to sleep on it a bit to come up with more. The problem is my goal, at least, is that a lot of the repetitive stuff that a user might want to code like with the DPs would no longer need to be coded by the users, just downloaded/installed and used. Rule creation would become more of a search and assemble exercise as opposed to a copy and adapt exercise.

• Rule awareness. One of the things that you can do is enable/disable Rules from other Rules. But you have to know the Rule's UUID to do it which you need to go to PaperUI or the REST API to discover. Having a list of the Rules and their UUIDs would be helpful for that.

[Confectrician]

I will catch up on your post later, but want to add one thing already regarding snippets:

Snippets are easy to integrate like described shortly here: https://community.openhab.org/t/reusable-sitemap-sections/83955/19?u=confectrician

Basically those are just json objects, so it sould be no big deal to include some of them here very quick.

The only tricky part is, to make them available in jsr file types, but this is one effort to be done. If that's solved once, we can add tons of snippets by just merging some json.