openHAB VS Code Extension 0.4.1-beta

Apps & Services VS Code
1

Hi all,

I know that there hasn’t been a bigger progress for a while.
I have talked to @kubawolanin and he isn’t able to spend much time on the extension, so i am trying to help a bit out here.

We pushed some topics forward and possibly could solve some problems.
Now it’s up to you, to give some feedback before i will push a new release to the marketplace.

Rough changelog

Removed docs search

We are not able to search directly on our new website design.
Hopefully there will be a fix in the future, that brings back this functionality.

PaperUI gets opened in external browser (for now)

There was a change in the vscode extension apis and we are not able to get Paper UI working reliable with the new webview api for now.
We are still investigating on how to solve this on long term.
External browser works fine and we decided to make it the default and only option for Paper UI for now.

Fixed Basic UI Panel within VSCode

We had more luck with the Basic UI which works fine within vscode with their “new” webview api.

Clarified -restCompletions- description

This setting can help, if code completion results in high loads on your openHAB environment.
We were not able to solve this problem fast, but you can at least deactivate the completions and still use the rest api for items and things explorer.

Concepts for a better integration of language server with completion are already in discussion and will bring us a reliable solution on mid-term hopefully.

Thanks

I wanted to thank @MHerbst and @Rangarid again.
Both tried to make some progress with me in the last days and helped much.
Kudos to you.

Download

You can find the beta .vsix file in my PR on Github:
openhab-0.4.1-beta.vsix.zip

Here are the docs for installing a vsix extension file directly:

I will wait some days for feedback and if we are stable enough i will merge the PR and push a new marketplace 0.4.1 release.

One thing left:
Have a nice weekend everyone. :slight_smile:

11 Likes
3
  1. Should be easy

You seem to have the option activated before already and I removed it now completely. (Since we made browser the default)
So simply removing the option in your user settings should solve that.

I will have a look @ 2 before I can answer that.
Thanks for reporting. :+1:

1 Like
5

Ok then we should see if there is an issue for #2 and open a new one if not.

We can invest time on that later, before the PR gets too much overhead. :smile:

1 Like
6

Changes look good to me. :+1:

Really nice to get the Basic UI and Paper UI functionality back. Not really an issue for me having Paper UI in the external browser.

Thanks for doing this!

1 Like
7

You’re welcome, i wanted to start a long time ago too but was busy.
Now i had enough spare time to push something forward too.

We have recently discovered that it seems to be denied
to edit items in Paper UI when the configuration “simple mode” is activated.

  1. @Kai i think Paper UI Item editing is deactivated on purpose in simple mode. Can you confirm that?
  2. I have already prepared a simple mode check through rest api, if 1. is confirmed and will add that to the 0.4.1 then to prevent opening Paper UI with a page that is empty because you are not allowed to edit items.
1 Like
8

I am bit confused. I have tried to reproduce this problem but I don’t see these commands in my context menu for items or sitemap files. Also, I can’t see definitions for these commands in the extension definition file.

10

What exactly should this do anyway? If you’re right-clicking on the item in the items file or sitemap, aren’t you already looking at the item or sitemap definition?

BTW, there are some real issues with path mapping between the client where VS Code runs and the server where openHAB/LSP runs. I tried to fix one of them here, but there are still issues.

11

Yes, I tried it there. This is how the menu looks in my installation:

image
image.png937×914 138 KB

I have seen those two commands in editors for Typescript and Go but never in the openHAB editors.

Maybe these commands were provided by another extension.

14

If you don’t know what it’s supposed to do, then why are you clicking on it? :wink:

Reminds me of the old saying “Patient: Doctor, it hurts when I do that. Doctor: Then, don’t do that”. LOL

16

Can you check your key bindings definition, e.g. the definition for F12. In my installation it looks like this:

{ "key": "f12",                   "command": "editor.action.goToDeclaration",
                                     "when": "editorHasDefinitionProvider && editorTextFocus && !isInEmbeddedEditor" },

Maybe it’s different from the standard.

any selection of the first 4 options cause the error
the first 2 options produce the error and close the file
the second 2 options leave the file open but produce the same error and no results

As far as I understand the extension’s code these 4 options should not be visible when editing .items or .sitemap files because there are no definitions for these options.

I think functions like “Find/List all References” would also be interesting for the openHAB extension, e.g. to find references to items in sitemaps.

1 Like
19

Uninstalled all, wiped clean all VSC related settings…
Installed clean again… can’t reproduce it (right click menu doesn’t show these first options anymore)

forget about it… i don’t know what the heck was wrong… I really had no customizations done to VSC in the past.
Only 2 extensions on top of OH (Debugger for Chrome and Powershell)

20

Now it’s getting interesting: I have created a fresh VSCode installation on a Ubuntu VM machine and now I can see this menu items (with version 0.4.0 …).

It seems that these options have to do with the LSP. If LSP is disabled the options are not visible but if I activate the LSP then these options will appear not immediately but some time later. It seems that VSCode activates these options automatically as soon as it gets a certain value back from the LSP server.

somehow the Linux path is visible to VSC and I can’t figure out how/where to change this…

I always see the share that I am using. Which openHAB version are you using?

21

OH2.4.0.S1454
looks like you found something
ehm… with all settings clear I don’t see the menus under 0.4.1-b

the settings that I removed during the cleanup operation are:

{
    "openhab.username": "",
    "openhab.port": 8081,
    "openhab.password": "",
    "openhab.host": "homer",
    "openhab.lspEnabled": true,
    "openhab.useRestApi": true,
    "openhab.paperPath": "paperui",
    "openhab.restCompletions": true,
    "openhab.sitemapPreviewUI": "basicui"
}

I will try to put them back now

22

yup… confirmed.
with the minimum settings:

{
    "openhab.host": "homer",
    "openhab.lspEnabled": true,
}

the bogus menu options re-appear.

23

Yes that’s it :-). But it only happens if the LSP really can parse the file. If it can’t get it because of the share definitions (see https://github.com/eclipse/smarthome/issues/6611) the menu options don’t appear (that’s why I was not able to reproduce it in my first tries).

We should disable these function if there is no working implemention. Will try to figure out whether we can do it in the extension or whether the LSP itself must do it.

1 Like
24

you are correct.
Even on 0.4.0 these menu options appear
The difference in my 2 screenshots here is that the first one had no settings applied on settings.json
Since the default is: "openhab.lspEnabled": true
the setting that is affecting this is the "openhab.host": "homer" (without this, my local VSC on windows cannot connect to the remote Linux machine running OH2 and to the default LSP port)

25

edit

26

edit

27

The mapping happens here. It’s passed to the client in the JSON.

1 Like
28

edit