v1.0.1: JS hover tooltips and log-based state extraction

[s0170071]

Summary

This PR adds two features to the hover tooltip system

Changes over v1.0.0

1. **Hover tooltips for JavaScript .js and .sitemap files

2. Key-value state extraction from log lines — When hovering over a variable name, the extension extracts its value from log lines with the format someitem="state" and shows just the state. Shows the complete log line if the search string is found and does not follow the = convention.

[pgfeller]

Hi,

I noticed your work in the forum. Thanks for your contribution!

I currently work on a widget preview extension for my visual studio code setup - as there are other users using VS-Code, it might make sense maintain the extension actively (as proposed by @rkoshak in the forum post).

I'm working on a setup to maintain all rules and widgets inside a git repository, including regression tests: Managing openHAB Rules Like Production Software.

My question: Why do you parse the log files - and not leverage the API to get the item states? I'm not sure, but I assume the web client even uses a socket connection. If I remember correctly, the extension already uses a token to get access to the server.

I'll follow up and check who is currently listed as maintainer. But next to my daytime job and the multiple project progress on each of them takes time ... but maybe a slow maintainer is better than no maintainer 🤔.

But first, what do you think about the API based approach ... as a maintainer I would be hesitant to use the logs, as it has several drawbacks (e.g. system running in a container on a linux host and you would like to do something on a windows system without using complex WSL or SSHFS mount configurations) ...

with kind regards,
Patrik

[pgfeller]

The tree view feature uses the api - I'm not sure, I think the item preview part if broken - but I would approach if from the API and not parse the logs to get the item states.

It is worth to evaluate if we have the items and item states already in the extension (tree view) to fix and use this mechanism as well for the new proposed functionality.

[pgfeller]

If we maintain the repo again, I also propose to track new features and issues properly. Another small thing I work on is (limited) support for intellisense for widgets. openHAB is very flexible and allows to solve things in different ways - but in my setup I aim for consistency. So I opted to standardize they way I create widgets. At the moment this relies on a defined workspace structure, or file pattern for the schema to filter the yaml files it applies to.

Something like this could also be a feature of the extension, which could be enabled if desired.

@openhab/maintainers
What is your opinion on this, and what is expected from a maintainer (especially the response time will be problematic if I would take responsibility here). I know, there is a nomination process - would someone be willing to share the maintainer role with me (in case the response time is not a show stopper) - and provide guidance on how to fulfill the role?

[s0170071]

TLDR;
added support for .item and .js files.
added support for variable state mouse-over. Items are not variables.

Dear Patrik,

thank you for reaching out to me.
The extension 1.0.0 was made with DSL rules in mind. It could show mouse over tooltips of item states. A great feature.
It does not, however, show the tool tips for .js files and .sitemap files. Adding the sitemap and js files is one part of the PR.
The other part was improving debug support. Originally I wanted real debugging capabilities like stepping through code. Turns out thats not so easy. Instead I settled for displaying variable states after the rule has run. Not as good but hey, more often than not it helps figuring out which route your case statement went.

My question: Why do you parse the log files - and not leverage the API to get the item states? I'm not sure, but I assume the web client even uses a socket connection. If I remember correctly, the extension already uses a token to get access to the server.

Thats because you can only access item states via the API. Variables are intermediate within rules. Temporary and gone when the rule exists. Or the js function for that matter. But what you can do is dumping your variable in the log.
Instead of searching through it manually, the extension now does it for you and displays it as mouse-over tool tip.
Very convenient but not to be confused with fetching item states via the API. That remains unchanged ;-)

I'll follow up and check who is currently listed as maintainer. But next to my daytime job and the multiple project progress on each of them takes time ... but maybe a slow maintainer is better than no maintainer 🤔.

Thanks a lot !

[pgfeller]

Thats because you can only access item states via the API. Variables are intermediate within rules. Temporary and gone when the rule exists. Or the js function for that matter. But what you can do is dumping your variable in the log.
Instead of searching through it manually, the extension now does it for you and displays it as mouse-over tool tip.
Very convenient but not to be confused with fetching item states via the API. That remains unchanged ;-)

I see - then I misunderstood what you were aiming for ... with this approach the log statements might be stale and it needs careful consideration how to use them to get results that will not be misleading. I do not say this does not add value - don't get me wrong. But the lack of debug capabilities is a pain point for many of us I think.

In theory it should be possible to modify the JavaScript addon to support debugging:

GraalVM supports debugging of guest language applications and provides a built-in implementation of the Chrome DevTools Protocol. GraalVM

This would require some changes in the code of the add-on and a POC to verify. Did just a quick skimming - but something along the line of

Context.newBuilder("js")
    .option("inspect", "0.0.0.0:9229")
    .option("inspect.Suspend", "false")
    .build();

Of course the user could enable, or disable the debug API (in case it is not needed) - as this might have side effects. But this would allow for proper debugging - how cool would that be 😃 ....

My problem is not the lack of ideas - but lack of time. I hope to finish the Jellyfin project soon and then do some minor maintenance on the hue sync binding.

➡️ But would you be interested to team up to investigate if the idea is feasible? In this case I think a follow up with the add-on maintainer would make sense ...

[s0170071]

GraalVM supports debugging of guest language applications and provides a built-in implementation of the Chrome DevTools Protocol. GraalVM

Here you go...
https://community.openhab.org/t/debug-js-files-in-vsc-with-a-debugger-how-to/168861

We would not need the extension for this.

[pgfeller]

GraalVM supports debugging of guest language applications and provides a built-in implementation of the Chrome DevTools Protocol. GraalVM

Here you go...
https://community.openhab.org/t/debug-js-files-in-vsc-with-a-debugger-how-to/168861

We would not need the extension for this.

Ultra cool ... I'll give it a try as soon as possible. I've checked out the extension repo as well to have a look, as combined with the debugger the expirience would be quite nice. An the extension could help to lower the bar to configure things.

Anyhow - first I need to clarify the maintener thingy, as else we can not merge PR's.

I propose to create a feature request to include the debug interface by default into the add on (I would make it a configurable option). You could link your work in the request. So we would get feedback on the idea. As I'm not a JAVA expert, we have to consider if there is a downside, that I'm not aware off - but for me this is a must have 😄.

If ok withou you, I recommend to abandon this PR and follow up on the feature.

[pgfeller]

@Confectrician

Hi Jerome,

I would like to re-activate the extensions - as with the potential to integrate the debug functionality for javascript rules and the possibility to to create unit tests in case the rules are maintained in a dedicated repository (prototype available as well) - see this forum post.

I checked the history of the code - do you know who is the current maintainer of the code? If it is you, and you do not have time anymore to take care of the code I'm interested do help you. But I would need some guidance ...

Let use know what you think about the ideas and to leverage the extension to make it more accessible and lower the bar to those cool features. It would also be a USP for openHAB: a home automation supporting rule regression tests and full debugging ...

with kind regards,
Patrik

[lsiepel]

Jerome has not been active on github for a while, so i doubt you will get a response.

[pgfeller]

Yep - but fortunately @florian-h05 did help out, and we were already able to merge a first PR with some code maintenance ... I would like to re-active the extension - if we are able to integrate JavaScript debug support together with synchronization of the code update to openHAB via REST would be very helpful.

If we can achieve that, we might consider to also enable jest regression testing of rules - but here we'll have to discuss a bit, as my approach depends on the use of LLMs - and for an extension that's too risky from a security point of view. I'll have to see how much assistance we can provide without AI (it's basically the mock generation that might be tricky ... but that's a problem for a future that may never come, as one of my professors once said 😄.

Many thanks @lsiepel that you step in and help out. Highly appreciated. A common experience, that unfortunately even in big communities and companies, only few key people drive things and ensure success. My time does not allow to be one of those persons for openHAB; but I try my best to give something back to the community as well.

take care!

[florian-h05]

Hi @s0170071 and thanks for your contribution!

As Patrick already said, we have to take care of a few organisational things before development can traction pace again, but that soon should be completed. In the mean time, I will process PRs.

Looking at your PR, the changes to the language and snippets definitions look good and I welcome your hover improvements in general. I however don‘t like the whole log search logic, that‘s „not clean“ and will also be unstable/not working in many cases. I think the reason to implement it was debugging of JS Scripting, which will become possible by enabling the debugger once openhab/openhab-addons#20440 is merged.

Can you please remove the log-based functionality from this PR?