Code completion for rules not working (or is it?)

OK, so I am not the only one. Then I might as well stop trying.

All-in-all I am quite excited about OpenHAB. I am coming from Domoticz so the bar was not set very high and I have a lot of criticism already but at least with this it is obvious some folks actually thought about it before something was slapped together. This lack of code completion is a bit disappointing though.

Thank you.

I’d highly recommend using JSR223 rules engine instead of rulesdsl. It takes a bit of time to set up currently but it’s worth the effort. See [beta testers wanted!] Jython addon w/ helper libraries (requires OH 2.5.x)

PS you can continue using rulesdsl even if you’ve set up jython. They can run side by side.

I think the code completion relies on a LISP server provided by oipenHAB. That need to be enabled, and VSCode talking to right url/port

1 Like

I would not know how to make sure that LISP server is active or not. But it got weirder…

After giving me seemingly random non-sense like words I typed earlier and/or a list of my items in any editing contexts, tonight it started to show stuff that looks sort of right:

It does not give me useful options in all cursor positions but here after “state.” it actually look like sensible options. I have only been messing with editor encoding options, did not change anything substantial that could explain the improvement. It is still far from good but this is some guidance. There was some more in the list:

These look like methods and properties of state.

I give it a 3 out if 10.

I suppose you could look, in your openhab.log

2019-12-18 22:20:11.347 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007

and VSCode extension settings

to see if they at least match.
I expect there’s other ways to have access problems from wherever you run VSCode to wherever you run openHAB.

You may just have to ask for your money back.

You may just have to ask for your money back

That, and some flowers to get me back into my regular good mood again.

I will check this out tomorrow, thanks again for helping out a grumpy old man.

1 Like

To bring some light in the dark:

At least some kind of completion “should” come from the LSP server implementation,
but i doubt that it is working completely.
There was a big contribution for this and it has never been touched significantly since that and is still out of my knowledge.

The code completions you are seeing above seem to be taken from vscode directly somewhere,
which is trying to at least provide something at all.
Needless to say that this can’t be helpful for you.

And as always (and said already dozens of times):
Anyone with some programming skills is welcome to help out improving the extension.
Language Server Protocol is and will be out of my personal scope for quite some time.


afaik it is essential for a properly working code completion, that both work directory and settings for the vscode plugin are correct.
I’m using a standard openhabian installation, but it’s on a vm, so the name of the openHAB server is different to openhabianpi :slight_smile:
But that’s my configuration:

    "": "", 
    "openhab.remoteLspEnabled": true,
    "openhab.useRestApi": true,
    "openhab.port": 8080,
    "openhab.remoteLspPort": 5007,
    "openhab.username": "",
    "openhab.paperPath": "paperui",
    "openhab.sitemapPreviewUI": "basicui",
    "openhab.password": "",

    "": "C:\\WINDOWS\\System32\\cmd.exe",
    "workbench.settings.openDefaultSettings": true,
    "editor.renderWhitespace": "all"

I also have bound the openhab-conf directory via net use to the drive letter O (like openHAB…) :slight_smile: and opened this directory as working directory in vscode
-> code completion works like a charm.

Please be aware that some plugin settings got renamed from version to version, vscode will not change the settings automatically, to please ensure all settings have the correct parameter name.

AFAIK code completion is working for me as well, also on a openhabian installation, but this on a raspi3. VSC is installed on a Win10 maschine and the conf folder is setup as a network drive.

My settings.json looks like this:

    "": "MyMaschineName",
    "openhab.port": 8080,
    "openhab.remoteLspPort": 5007,
    "workbench.startupEditor": "newUntitledFile",
    "workbench.iconTheme": "openhab",

Thanks for the example configuration file.

I added the LSP-related parameters:

“openhab.remoteLspEnabled”: true,
“openhab.remoteLspPort”: 5007,

and I am afraid I do not notice an improvement (I restarted OpenHAB).

In Paper UI I have this option under Services->Configuration->Misc to configure “Language Server (LSP)”. All I see here is a port setting and this is already 5007 by default. In expert mode I have the option to add a parameter.

Is there anything I should do here?

This is what mine looks like at similar situation

1 Like

I had something similar two days ago but now it is just items and/or thing names again.
I am wondering though:

Do you get this the moment you type the dot or do you still have to press Ctrl+Space?
What does it look like for the item level (after the dot before “state”)?

That was an existing line, in which I inserted a dot.
I have an unfair advantage running VSCode on the same laptop hosting openHAB, so I don’t get network delays.

The following was typing a completely fresh new rule line, Item was autocompleted from a proffered list of names like test_xxx, then typed the dot

That looks a whole lot better on your side. I now just get the same list of item or thing names in both places. Perhaps it is some subtle difference between Windows and Synology.

Other people mentioned they had mapped a drive letter to the OpenHAB files and I was like “so what, how would that be relevant”. But I did open the folder in VS Code directly using a UNC name. The plugin may have an issue with UNC names so I will try and map a drive letter too and work with that, see how that works.

There is definitely a big difference between using UNC and Drive letter, UNC is //path/to/file and Drive letter is X:\path\to\file so it’s / vs. \

I know how it is different, the question is whether the OpenHAB plugin can handle perfectly valid network paths or not.

Does the LSP only work for RulesDSL and not Jython?

Well… Yo (Yes and No) :wink: There are some (known) Issues with unc.

In fact, if looking into the settings, there is a warning about unc paths:
Anmerkung 2020-05-27 112440

Oh, well, that is promising. And a little embarrassing since apparently it is documented (somewhere). I am not at a PC now, will try soon and report back.

I mapped a drive letter. The first thing I noticed was I now had code validation (squigglies under code fragments that had some issue). Still no code completion though. But, after a couple of minutes, look-y-look:

right after typing the dot. And, after waiting a couple of minutes more:

it is also working for items! But then again, it drops out just as sudden as it appeared to work. It is also a bit bare compared to what a grown-ups IDE offers (I do not see member types) but if it works, the options are helpful.


It looks like the parser is just stupid. If I type an item name as the first word on a line followed by a dot, I do get members. If the item is however in a condition of an if statement… that’s waaaay too complicated for our poor little plug-in. Strangely enough, it did work once in an if statement as the screenshot shows before it just stopped working, in the same edit session.

Anyway, though poor, once you know this it is perfectly workable and beats a search for documentation. I can just paste the object I want to see members for on an empty line and see what my options are. So, success after all.

Thank you all very much.

[Edit 2, one day later]

Aaaand it broke down again. Didn’t change anything, it just stopped working altogether. Must be something with the moon phase or the stars that need to be lined op right. I think we wasted enough time on this piece of #$%^&*!.