[Proposal] Allow loading storage configuration from /html/habpanel/

[kubawolanin]

Background

So I'm working on a Yeoman generator for openHAB that's in very early stage ;) It'll generate an items file and a corresponding sitemap for your home. E.g. you'll provide a list of rooms, then choose which sensors do you plan to have in each of them (e.g. Lights, Temperature, Windows, Doors etc). As a result, you'll have a complete structure generated for you.

I plan to include HABPanel Dashboards generator as well. The JSON structure of it is really straightforward and I'd like to utilize that.

As a result, it would output a file, e.g. /html/habpanel/our-home.json containing the widgets and dashboards. But to make it really smooth, we'd need some mechanism for accessing <openhab-config>/html/ folder (/static/habpanel/?) so it's easier for HABPanel to pick it up.

Let me know what do you think :)

Cheers, Kuba

[ghys]

Certainly doable, this could be an interesting project... but I have questions :)

First, just to be sure: you mean, doing a one-shot import and/or keeping the loaded read-only, because you obviously won't be able to save the changes made with the GUI back to the file! This would be quite similar to the mechanism allowing to import the config from a local file - in the 'local panel configuration editor' (there is #50 to take care of first) but with a list of detected files in a server directory?

[ghys]

Couple of solutions off the top of my head:

• extend the REST API with HABPanel endpoints - the service configuration trick was clever enough at the time, but a "real" REST endpoint for dashboards would have been better, and could have included some logic to load the config (of part of it) from files in the conf folder, like it's done for items and sitemaps... Don't know when I'll muster the courage to tackle this and come up with a good solution without breaking anything :)

• easier: a panel configuration is currently a simple object in the "registry" (service configuration variable) like this:

{
    "dashboards": [],
    "menucolumns": 4,
    "settings": {},
    "customwidgets": {}
}

When using an "external" config, it could be something like this instead (with a special GUI to do the referencing):

{
    "external_src": "<file_location>"
}

Then it's only a matter of altering the logic in OH2StorageService.useCurrentPanelConfig() to detect external_src, loading the file and populating the $rootScope (yes, this is messy...) with its contents as appropriate.

[kubawolanin]

Hi @ghys thank you for your expertise.

Ideally I'd like to manage the dashboards same way we manage sitemaps - through the file in /openhab-config/sitemaps/. The "easier" solution you've proposed looks perfect for the task. Although we still don't have a way to list all [json] files from e.g. /html/habpanel/, do we? This way we could dynamically create objects with external_src references.

[ghys]

The fundamental problem with this remains: as HABPanel dashboards were meant to be edited right in the app, if they're loaded read-only from external files we'll have to either:

• disable the editing features entirely;
• warn the user their changes might be lost if the file is loaded again;
• have some sort of "merge" between the contents of the file and changes made in the app (?)

Although we still don't have a way to list all [json] files from e.g. /html/habpanel/, do we?

Nope. That's why a REST API taking care of this could be the way forward (even if the storage remains in the service configuration for compatibility purposes).

[kirantpatil]

@kubawolanin, does it work for ESH as well ?

[kubawolanin]

@kirantpatil it doesn't work anywhere yet :-)

[kubawolanin]

@kirantpatil @ghys feel free to try it now :-) https://community.openhab.org/t/openhab-generator-design-your-smart-home-in-no-time/32250

[ghys]

Looks nice! I'll definitely give it a try later :)

I had a redesign of the storage configuration settings GUI in mind, because it's a little confusing for new users, maybe this is an opportunity to do it and include this as well instead of overhauling the API - quick win.

[ghys]

@kubawolanin I just thought about this, but if you're going the route suggested in the thread (write into the jsondb in userdata), maybe it makes sense to write your HABPanel stuff directly in userdata/config/org/openhab/habpanel.config as well... it's ugly, there is a string to JSON.parse and serialize again but it could probably be done. I'm guessing the same warning applies, openHAB should be stopped before doing this.

[kubawolanin]

Thanks @ghys but I think I'll give up for now. The tool doesn't get much love in its current form and I'm pretty discouraged at the moment to push it forward 😉

[ghys]

Don't be discouraged, just give people some time to sleep on it :)

[kaikreuzer]

When reviewing and testing the Home Builder, this issue here is exactly the feature I was missing - so time to revive the discussion :-)

My problem is that I actually do not fully understand the discussion so far. By blunt initial thought would have been that the Home Builder simply pushes a generated JSON through the REST API to the "Panel registry JSON", which is a parameter of the configuration of HABPanel and thus can be posted through the REST API. As the Home Builder is meant to create an initial skeleton (and not edit anything afterwards), it is imho fine that it cannot just add a dashboard to an existing setup, but wipes everything that might have been there (which is nothing in the normal case). What am I missing with this approach?

[ghys]

@kaikreuzer you're right. IIRC this discussion happened when Home Builder was still an external command-line tool and designed to run while openHAB was offline. In its current form it makes sense (and even quite straightforward) to simply call the REST API and alter the HABPanel config from there.

That being said, I don't know your opinion about the current storage location of the HABPanel "panel registry" in the service configuration, but... maybe an actual ESH provider/registry (as in the org.eclipse.smarthome.core.common.registry package) and associated REST API would be more appropriate at some point? :) Assuming we can achieve a smooth migration for existing users of course.