- Platform information:
Win 10, Raspberry 4, openHAB 2.5.2
Recently I have had big problems with “Visaul Studio Code”. The openHAB extension always crashes my “openHAB 2.5.2” or “openHAB 2.5.3”, no matter from which computer I edit rules.
SMB 1.0 / CIFS in Windows 10 is activated.
“\ openhab \ openHAB-conf” is connected to Windows and “VSCode” as a network drive
The web interfaces of “openHAB” and sitemaps can be easily opened in Chrome and I can connect to “openhabian” and “Karaf” using PuTTY.
LSP in “openHAB” is configured on port 5007 and 5007 is additionally released in the firewall, nevertheless the crash happens even if fireawall and virus scanner are completely deactivated!
I have a “settings.json” in C: \ Users \ User \ AppData \ Roaming \ Code \ User \ settings.json and another one in \ openhab \ openHAB-conf \ .vscode \ settings.json
"openhab.karafCommand": "ssh openhab@%openhabhost% -p 8101",
If I call a rule in VSCode and hold the mouse over an ITEM, the status is displayed to me. After a few seconds the display changes to “loading” and “openHAB” has hung up!
With PuTTY you can still connect to openhabian and access “\ openhab \ openHAB-conf” in Windows Explorer
The ITEMS can no longer be switched, nor can the openhab Web GUI and Karaf be called up. OpenHAB cannot be restarted! It crashed completely, you have to restart the Raspberry with “sudo shutdown -r 0”!
Does anyone have any idea what my problem could be?
I had a similar problem.
The solution was to change the setting in Visual Studio Code from
to the IP address
Thanks, but as you can see above I have already adjusted “openhab.host” to my IP address.
I would try to exclude the Karaf settings and just try to start with only host and port.
if that works as expected then add the other setting options
"openhab.karafCommand": "ssh openhab@%192.168.xxx.xxx% -p 8101",
This one is also trying to connect to openhabhost use the IP address there as well
Does it always freeze in the moment when you hover over an item?
Is this a group Item?
Yes exactly, it freezes when I move the mouse over it.
It is a “normal”, single Item. No group Item! And all of my Items behave like this.
Ok i have looked at your gif now on my pc with a bigger screen.
Is it possible that the “sendCommand” method is on the same line as the “then” of your rule?!
This should be a mistake at first.
I will have to chekc if that causes errors in the hover provider of the vscode extension.
Anyways you can do me a favor and provide some more informations:
First you could open the developer tools and clear the console interface and do a hover again.
Also you could provide me this log via personal message, to get an impression of whats going on inside the extension.
There is a save log menu when you right click in the console output of developer tools.
Also it would be interesting to check if this also appears when you do a hover in an items file instead of the rules file.
I can’t see any erros currently when testing it in a rules file.
The problem has been solved with a deeper search via pm.
@Steinspiel will give the results back as feedback here.
Thanks from my side for the constructive path for finding the solution here together.
Also thanks in advance for working up the results and possibly help others in the future.
In the meantime I have found the error:
I have found that the freezing of openHAB by VSCode only ever occurred in one Rule in which Chromcast devices were controlled.
In this rule the code line
now.getDayOfWeek < 6 && now.getMinuteOfDay > 44 + 4*60 && now.getMinuteOfDay < 31+5*60
so opeHAB stopped - I removed the line from the rule everything worked again.
Watch my Video …
@Confectrician made the proposal to insert parentheses (), so:
now.getDayOfWeek() < 6 && now.getMinuteOfDay() > 44 + 4*60 && now.getMinuteOfDay() < 31+5*60
This worked well and openHAB does not freeze.
However, I no longer use this line of code, @Confectrician advised me to use virtual Items + Cronjobs to control the time, which IMO is much easier and clearer.
thank you for your help
What i found interesting here, is that openHAB itself seems to handle this “mistake” properly
while remote LSP went crazy on trying to check those statements and even caused openHAB to crash.
Just a great example of how difficult problem solution can be on such a such a flexible system like openHAB.