Persistence configuration via UI

[J-N-K]

The problem

I'm currently working on adding the possibility to configure the whole openHAB system via UI. Parts of this effort are #1448 and #1452. The next step is adding UI support for persistence service configuration.

Currently persistence is configured in two places. The default persistence service is configured on the right side of the settings page under "System Services/Persistence" and individual configuration (like URLs or access data) is done under "Other Services/". The configuration of items and strategies can only be done via files.

The core part of configuring items/strategies (and filters as new feature) is in openhab/openhab-core#2871.

I tried to implement UI support for the latter part but I'm unsure how to achieve the best user experience.

Your suggestion

There are three possible places for the configuration page:

• On the "System Services/Persistence" page with a gear wheel in the selection list. The wheel will then open a new page for configuration. It feels wrong to configure individual services under "System Services". It also requires a special handling for org.openhab.persistence which is currently handled by a generic config-sheet.

• On the "Other Services/" page. This is slightly better because it groups all configuration for a service in one place. It's not so good because the list will get longer an longer the more persistence services are installed and there is no page currently for services that do not require configuration (like rrd4j), so we would need to add support for that, too. Also IMO the configuration done here should move to the add-on page once Introduce metadata for all add-ons openhab-core#3050 is implemented and good support for configuring all add-ons is provided. That makes item/strategy configuration IMO too invisible.

• Via a new "Persistence" section (like the "Transformation" section). This would be my first choice but having three places where persistence is configured (default service, service configuration and items/strategies) in different parts of the UI could be confusing.

WDYT?

[kaikreuzer]

IMO the configuration done here should move to the add-on page

I'd agree on this. The "other services" currently are configurations for various add-ons of different types. We should instead have a dedicated place where for each add-on its configuration can be found easily. This is then imho the right place to also put the persistence add-on configurations.

[rkoshak]

I don't like having three different places to configure anything, including Persistence. It's confusing and can become tedious when setting it up in the first place.

I like the idea that all add-ons configs kind of look the same and can be found in the same place. This consistency helps end users be able to predict where to go to change configurations.

But the current "Other Services" section is itself confusing right now. It's not clear why certain things are listed under "Other Services" while others are under "System Services:". I see with the latest snapshot that a lot got removed/moved from that section which is good, but it's still not clear why, for example, the LSP which is part of the core same as ephemeris (e.g.) but is listed as an "Other Service". (When/if we move the Rules DSL to it's own add-on, maybe it makes sense to move the LSP to be part of that add-on since it only supports Rules DSL, right? Then the config would be part of the Rules DSL add-on).

I only bring this up to point out it's important that what ever we do we try to be consistent in how we order and group what we present to avoid that sort of confusion in the future.

If we keep the current "Persistence" entry under "System Services", renaming it to "Default Persistence" I think will avoid some confusion. That should make it clear that this entry is dealing with a system level configuration, not a place to go and look for general Persistence configuration. So if we can limit it down to just two locations, the system level default persistence config and the TBD add-ons config section I think that would be reasonable from an end user perspective.

[ghys]

It's not clear why certain things are listed under "Other Services" while others are under "System Services:".

Quite simple from a technical POV: the response to the GET /rest/services made in this page distinguishes those services with category set to system and the rest (I didn't deem it necessary to have more than these 2 groups, the system services are usually the majority anyway).

openhab-webui/bundles/org.openhab.ui/web/src/pages/settings/settings-menu.vue

Lines 181 to 185 in 49a6000

	servicesPromise.then((data) => {
	this.systemServices = data.filter(s => s.category === 'system')
	this.otherServices = data.filter(s => s.category !== 'system')
	this.servicesLoaded = true
	})

I pretty much agree with what was said above. As stated for the transformations config I'm not too keen on adding these as top-level objects like rules or items or things (unless we decide on a new design for the settings menu maybe).

I would mention that to add persistence configuration to the add-on config page, it would perhaps even NOT be strictly necessary to have openhab/openhab-core#3050 but just openhab/openhab-core#2871 and #1452 (which adds the config page for all add-ons in the store UI). Since persistence add-ons can be identified with their type (with type: persistence in /rest/addons/:addonId when loading the add-on config page), we can theoretically add another section to configure the persistence strategy for these types of add-ons even if we can't actually configure the add-on itself - a bit like the log level section:

But all in all it would be nice to remove for instance the info of the desired InfluxDB server from "Other Services" and put it in a consolidated page for the add-on. Here's hoping we can assume one add-on = one service of the expected type, and that e.g. add-ons classified as "bindings" would never come with their own persistence services (which would be technically possible) because then this design wouldn't work.

[J-N-K]

I don't think that bindings and persistence services should be mixed. This should be prevented by @openhab/add-ons-maintainers.

Regarding one-service per add-on: the add-ons PR allows config descriptions in the addon.xml (successor of binding.xml but for all add-os). As long as the config descriptions are correct, it'll work, no matter how many (different) services are configured. The only issue would be e.g. two InfluxDB connections with different configurations. But AFAIK currently we don't support that.

[ghys]

Yes I was just mentioning the fact that in theory we could have "hybrid" add-ons, perhaps not in the distribution as it would not pass review, but which install 3 bindings, 2 persistence services, 4 profiles, a transformation service etc. This is quite possible with Karaf features and even in a single OSGi bundle.

Edit:

As long as the config descriptions are correct, it'll work, no matter how many (different) services are configured.

Ok I got what you mean, the add-on author still has to provide configuration for the add-on as a whole. But then it could become confusing where to fetch the configuration if there would be one for the overall add-on and also the usual service configurations.

[rkoshak]

Quite simple from a technical POV: the response to the GET /rest/services made in this page distinguishes those services with category set to system and the rest (I didn't deem it necessary to have more than these 2 groups, the system services are usually the majority anyway).

Which I guess pushes the question up a level to why do Ephemeris and LSP have different categorizations? It's not a topic for this issue but it might be worth a look to make sure we have some clear criteria for what the appropriate categorizations are if the "Other Services" section is going to stick around. As an end user, I could not tell you the difference between the two except that I don't see any add-ons listed under System Services but I do some some core stuff under Other Services.

[rkoshak]

I absolutely agree and won't deny that, but when you're designing an UI, you work with what you have.

I'm absolutely not blaming you or anyone. I would have implemented it the same way.

[lsafelix75]

At first, I felt loss where to set the Persistence Configuration. Ended up I had to configure one default at System Services/Persistence and then Others to make it works. I think it will be good to group all in a one place instead of scattering same thing around. Also, it will be good if there is a place in main UI to configure persistence strategies, instead of text file.