VSCode Extension - 0.5.1 update available

Hi all,

It’s been a long time, i know.
I have heard nothing from Kuba in the last time, so i don’t know whats the current state.
Anyway we have got some improvements added in the last time and didn’t have a release with those improvements included yet.

I didn’t have the time i would have loved to invest too, but i have added a new 0.5.0 release for now which incorporates those changes.
The biggest one is the usage of a locally provided language server, which should speed up the syntax validation.

All information about the changes can be found here:

Please install and give feedback as usual.

Also please make sure to reload vscode after upgrading the extension.
The changes have introduced some new settings which are not displayed until you have reloaded vscode.

5 Likes

Since the update, the connection to the Rest API and lsp server isn’t working.

When I try to load the items I get the following error
17

Config:
{
“openhab.host”: “openhab.local”,
“openhab.port”: 443,
“openhab.username”: “user”,
“openhab.password”: “pw”,
“openhab.remoteLspEnabled”: true,
“openhab.remoteLspPort”: 5007,
“openhab.useRestApi”: true,
“openhab.sitemapPreviewUI”: “basicui”
}

Do you use a proxy or something similar for downloading the extension?

Command missing looks like the extension installation went wrong.
I have seen this error message different times after users tried to update and something went wrong with the download. (At least that’s my guess.)

I would try to completely uninstall and reinstall the extension in this case.

Did you install it through the vscode marketplace or via file download?

I have got the same problem. I have updatet it from the VSCode Marketplate. Uninstall and new install did not help.

Same happens if I install from the downloaded vsix file.

I think this is probably causing the problem:

Maybe the vsix file was not packed correctly? the directory vscode\extensions\openhab.openhab-0.5.0\out only contains a “src” folder and not other folder.

Ok on my notebook it is failing too.
And i didn’t check the item tree view on my computer to be honest.

IT seems that the rest connection is missing in general.

It seems that this is the case, but i have no idea why currently.
I have done the packaging as usual.

Hey @MHerbst and @MriX,

I have done a fresh packaging, which seems to work pretty stable on my notebook including items and things explorer.

I have updated the github release and also uploaded a new marketplace version. (This takes some time to appear maybe.)
Hopefully this will solve the problem for you too.

Sorry for the inconveniences. It seems that my workspace was a bit outdated while packaging first.
We have changed the extension structure heavily.

1 Like

Thanks @Confectrician

So now it’s working like the version 0.4.1

But like in 0.4.1 I have the following issue. When I set the host like this:
“openhab.host”: “https://openhab.local
Rest API works, Basic UI Preview doesn’t work

When I change it to this:
“openhab.host”: “openhab.local”
LSP works, Rest API and Basic UI Preview doesn’t work

I didn’t look it up, but if I remember correctly the https is added within the extension. (Might be wrong, due to the latest Changes.)

Did you try the non https setting also with a changed port configuration?

When I remove the https:// I get this error message from my Nginx server:

Error while connecting to openHAB REST API. <html> <head><title>400 The plain HTTP request was sent to HTTPS port</title></head> <body bgcolor="white"> <center><h1>400 Bad Request</h1></center> <center>The plain HTTP request was sent to HTTPS port</center> <hr><center>nginx/1.10.3</center> </body> </html>

When I remove the port 443 from my config, the extension tries to connect on port 8080, but Nginx is only listening on 443 https.

{
“openhab.host”: “openhab.local”,
“openhab.port”: 443,
“openhab.username”: “user”,
“openhab.password”: “pw”,
“openhab.remoteLspEnabled”: true,
“openhab.remoteLspPort”: 5007,
“openhab.useRestApi”: true,
“openhab.sitemapPreviewUI”: “basicui”
}

When using “show in Paper UI” for an item, I get the message “Your openHAB environment is running in simple mode. Paper UI can’t edit items when this mode is activated!” which is not true for my system. Any other task seems to work.

Is your system running in simple mode?

If yes, the extension is not able to access items for preview.
Things should work all the time.

No, it’s not in simple mode. That’s what I meant by

:slight_smile:

@MriX

To be honest:
It is very difficult for me to catch the state of your personal environment.
Any information from your side is appreciated.
https can be done through more than a ngix reverse proxy which you seem to use.
I am not using a setup like this, so i depend on as much information as possible to get an impression of where the problem could have its roots.

What i can read from the posts above:
-> you are running openHAB behind an nginx reverse proxy (probably like it is done in the popular tutorial here)
-> you have configured nginx to listen for port 443 and nothing more
-> did you also configure it to forward port 5007 which is used hardcoded in openHAB for the language server
-> Is there anything additional that could be important for your environment?

I think i can’t do much debugging without a similar setup.
I could try to setup a reverse proxy too for testing purposes, but that will take time and i am not able to do this on short term.

@Udo_Hartmann

Sorry. This happens, when one answers from mobile while already in the personel sleep mode. :smile:

So some background:
Possibly its not the simple mode which is causing this problem. (In this case the error message would be wrong.)

Can you open the preview for a thing or does this throw an error too?
You could also test this in the browser for a thing and then try to use a equivalent edit url for an item to check the general ability paper ui is giving you currently.

I can provide a detailled example later, when i am at home.

Just activate Simple Mode in PaperUI, then save. Set it back and save again. This is one of the known bugs that no one seems to know :wink:

1 Like

Do you have a reference issue for that?
Maybe we should mention that somewhere.

I’m not sure if there’s an issue in GitHub, but it was already mentioned here.

@Confectrician

Here is some information:

  • openHAB is running on a Delian 9.9 server
  • There is a firewall (ufw) enabled and port 5007 for lsp is allowed (even disabling the whole firewall didn’t fixed the issue)
  • Nginx is setup to provide multiple sites on one port
server {
    listen 80;
    server_name     openhab.local
    return 301 https://$server_name$request_uri;
}

server {
    listen                          443 ssl;
    server_name                     openhab.local

    keepalive_timeout               64;

    ssl_certificate                 /etc/ssl/server2/server2-chained.crt;
    ssl_certificate_key             /etc/ssl/server2/server2.key;
    ssl_dhparam                     /etc/ssl/server2/dhparam.pem;
    ssl_protocols                   TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers                     'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers       on;
    ssl_session_cache               shared:SSL:10m;

    rewrite ^(/)$ https://$http_host/start/index;


    location / {
        proxy_pass                              http://localhost:8080/;
        proxy_set_header Host                   $http_host;
        proxy_set_header X-Real-IP              $remote_addr;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto      $scheme;
        auth_basic                              "Username and Password Required";
        auth_basic_user_file                    /etc/nginx/.openhab_htpasswd;
    }

    location = /netdata {
        return 301 /netdata/;
    }

    location ~ /netdata/(?<ndpath>.*) {
        proxy_redirect                          off;
        proxy_set_header Host                   $host;

        proxy_set_header X-Forwarded-Host       $host;
        proxy_set_header X-Forwarded-Server     $host;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_http_version                      1.1;
        proxy_pass_request_headers              on;
        proxy_set_header Connection             "keep-alive";
        proxy_store                             off;
        proxy_pass                              http://127.0.0.1:19999/$ndpath$is_args$args;
        auth_basic                              "Username and Password Required";
        auth_basic_user_file                    /etc/nginx/.netdata_htpasswd;

        gzip                                    on;
        gzip_proxied                            any;
        gzip_types                              *;
    }

    location = /pihole {
        return 301 /pihole/;
    }

    location = /admin {
        return 301 /pihole/;
    }

    location = /admin/ {
        return 301 /pihole/;
    }

    location /pihole/ {
        proxy_pass                              http://localhost:8008/admin/;
        proxy_set_header Host                   $host;
        proxy_set_header X-Real-IP              $remote_addr;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        auth_basic                              "Username and Password Required";
        auth_basic_user_file                    /etc/nginx/.pihole_htpasswd;
    }
}

When I use port 8443 with the default openhab ssl encrypted connection I get the error unable to parse answer. When I add https:// I complains that the certificate is invalid (but trusted in Mac Keychain)
It only works correct when I use port 8080 default openhab configuration.

I think there is a bug in the extension. When somebody enters https:// for the openhab host, this should be removed when connecting to the LSP server because there is an other protocol used.

Yep, indeed that did the trick.

1 Like

GitHub Reference:

It seems that we have a problem with a library that we are using currently.
And aside i can tell you directly that this is out of my scope/knowledge on short term.
Sorry for this direct statement.
I am not happy with the situation and of course this is a thing that has to be fixed in the future.
But i can’t give you any timeframe for now.

I am not too familiar with the reverse proxy and nginx configuration.
Could you allow the computer you want to use vscode on a http connection through the nginx config?
I know that this is not the wanted solution, but maybe at least a temporary one.

Edit:

Some additional cutout which should be interesting for you an dother reverse proxy users:

Solution: Create a chained certificate like mentioned here in the NGINX documentation:

So this should be something we should at least document somewhere.