UI for health checks

[seime]

Starting point for a UI that shows issues with the users installation.

First out is broken links.

Depends on openhab/openhab-core#4115

[relativeci]

Job #1890: Bundle Size — 10.56MiB (+0.06%).

f886cd0(current) vs 4a0054a main#1889(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics   3 changes 1 regression

	Current Job #1890	Baseline Job #1889
Initial JS	1.86MiB(+0.05%)	1.86MiB
Initial CSS	607.87KiB	607.87KiB
Cache Invalidation	24.52%	18.3%
Chunks	223	223
Assets	246	246
Modules	2867(+0.21%)	2861
Duplicate Modules	141	141
Duplicate Code	1.73%	1.73%
Packages	95	95
Duplicate Packages	2	2

Bundle size by type   1 change 1 regression

	Current Job #1890	Baseline Job #1889
JS	8.75MiB (+0.07%)	8.75MiB
CSS	890.07KiB	890.07KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
IMG	140.74KiB	140.74KiB
HTML	1.24KiB	1.24KiB
Other	871B	871B

---

View job #1890 report View seime:health_checks branch activity View project dashboard

[ghys]

Thanks @seime - I had the same thoughts a few years ago.
My conclusion was that as most issues can be identified on the server, they should then be collected and processed on the server, not the client.

In practice you'd have perhaps a /rest/issues/scan API call which will run code on the server that will identify issues like:

• orphan links (missing item or channel)
• items with invalid parent group names
• expressions in Pages or config props referencing unknown items
• etc.

then you could get some details about the issue (/rest/issues/1234), its resolution options ('Remove Group1 from Item1 definition', 'Dismiss this issue for now', 'Ignore/delete this issue') and execute a resolution (/rest/issues/1234/resolve).

It would be up to server code in a Java class to detect, report, store (in a registry), prevent duplicates, and eventually resolve a particular kind of issue. That is, every kind of issue would have its own class able to detect it, report it, offer options to solve it, and exercise one of these options.

And with OSGi we would be able to introduce and inject new types of issues - ie. an OH binding could run its own diagnostics and insert its own issues.

[seime]

Yes, there is plenty to do in this space, and I was thinking a bit of the same. Actually started on a separate rest endpoint, but then reverted it.

WDYT about starting small and improve and refactor over time - opposed to crafting a whole new set of backend features just to get started?

[seime]

@ghys ☝️

[florian-h05]

@ghys Can you please comment on

WDYT about starting small and improve and refactor over time - opposed to crafting a whole new set of backend features just to get started?

and let me know if you are fine with this in general, so I can review it?