[Feature Request] Create & Restore Configuration via UI

[GumbyMan82]

Hi together,

reading the following thread: https://community.openhab.org/t/how-to-backup-openhab-suggest-discussion-docs-and-future-docs-for-backup-strategies-which-is-lacking/100182/2 I'd suggest we could add a feature in the OH3 UI to create and restore a backup.

For now, backing up openHAB (or exporting the current configuration) needs you

• to know how openhab-cli works
• and for a real backup you need to dig into amanda. Both options might be to complex for people who are not experienced with cli. Forthermore this solution would be OS independent.

So my suggestion would be a section in the UI (let's call it Backup & Restore Configuration) that

• let's you export the current configuration
• import a previously exported configuration.

This section should also tell what is to be exported and what not. e.g. it does not export the ZWave controller settings or Grafana settings.

We also could think about making this extensible to add the possibility to directly create an Grafana or Zwave backup (if possible of course)

If such a request has already been filed or implemented into the OH3 UI, feel free to reject this here.

[ghys]

Before features can be added to the UI an HTTP API needs to be exposed, regarding backup/restore it first needs a decision about whether it's a openHAB core feature (probably not unless @openhab/core-maintainers are on board) or an OS distribution feature (i.e. openHABian).

I have no objections to having an "openHABian" section for operations like this (installing/uninstalling software, backups, system monitoring & configuration, log viewing etc.) to be performed from the UI if a properly defined & secured API is provided, since openHABian is an official part of the openHAB ecosystem. That's for @openhab/openhabian-maintainers to decide.

[mstormi]

I have no objection to that UI section either but openHABian does not provide any API and I see no point in adding one for this purpose. There's a menu option but it in turn only calls the openhab-cli script and that in turn only calls platform specific OH scripts as @BClark09 explained in the thread. openHABian does not add any additional data so it doesn't add value and therefore shouldn't be part of that chain. Also openHABian is some Linuxes only while OH scripts are implemented for Windows and other OS, too. You could consider making the existing OH scripts available for access from the UI, though.

The :rolleyes: linked thread IMHO is just because some people want to ignore the complexity involved (so they don't even start reading into Amanda docs). So thanks for staying with facts rather than emotions here. Then again, just like within the thread, this request is exposing some lack of proper understanding how things are related and how they are packaged: Grafana is not part of openHAB. As such, any openHAB config export ("backup") will not include Grafana config or data, that's what Amanda is there for so you need that anyway. ZWave also works different from the OP's understanding. There's zwave things and linked items in OH config that can be exported yes, but there's also device and network configuration data on the ZWave controller and the devices. That can not be backed up from inside openHAB or even from openHABian. So I believe that even if we implemented an UI item, that would raise user expectations that cannot be met.

[GumbyMan82]

@mstormi I do understand the complexity. My (maybe naive) idea with having the UI extensible was: If Grafana provides an API to perform backups one could think about calling the API from the web UI. Yes, an ZWave was a really really bad example.

But definitely if the UI contains a create / restore configuration menu it must be stated that this only covers the openHAB related configuration and nothing more.

From my understanding this feature should be provided by openHAB-core. I think calling the existing scripts from the UI will cause more troubles since somewhere it must be detected on which OS openHAB is running and then select the correct scripts, ensure that the commands can be also executed (managing of user rights, ...).

[mstormi]

: If Grafana provides an API to perform backups one could think about calling the API from the web UI.

I do understand the complexity.

But not enough of it, sorry. Again: Grafana is NOT part of openHAB. The core is unaware that it exists or if it is installed or where. openHAB runs on platforms Grafana is not even available for.

I think calling the existing scripts from the UI will cause more troubles since somewhere it must be detected on which OS openHAB is running and then select the correct scripts, ensure that the commands can be also executed (managing of user rights, ...).

Another misunderstanding. The core (to serve the UI) has no concept of the underlying OS so all we can do is use concepts that are generically implementable in Java such as say to provide a tarball for download. Or to use scripts. The scripts in turn are OS specific thanks to openhab-distro to cover this.

[GumbyMan82]

Thanks for clarification and your patience to explain it. I do have misunderstood the architecture. Let's keep additional software like Grafana out of focus.

such as say to provide a tarball for download

Exactly this or something similar would be a good solution in my opinion. So speaking of only the configuration of openHAB (so to say, sitemaps, transformation, items, things, addons, persistence-configuration, ...) would that technically possible to provide in the future in the web based UI? Or is that something too complex or would disrupt the architecture?

[ghys]

Again, if the wish here is to have a web-based version of openhabian-config, which deal more with the underlying OS than openHAB proper (including, why not, backuping/snapshotting important files from third-party tools): remember that launching other UIs by clicking tiles on the main UI - like OH2's dashboard - is still offered, and openHABian can provide that additional UI and a tile for it, as it does with frontail and others.

Rather than adding a section in OH3's UI (what I suggested above), I think it would be an even better idea. Also, there are things that are difficult to do while openHAB is running, like restoring its configuration or upgrading it, but an openHABian-specific web app running separately on a different port could.

[kandersen01]

Stay focus on the goal please - To backup openHAB configuration in an easy way. Dont mix this with any 3.party services (at least not yet), otherweise this suggestion will fail into a debate about 3.party services beeing an issue..

The :rolleyes: linked thread IMHO is just because some people want to ignore the complexity involved (so they don't even start reading into Amanda docs).

Not quite true. The point of the thread beeing refered to, was actually the exact opposite - Having a fully descriped backup solution (even though its limited to openHAB configuration only), without beeing too complexed for new/non-knowlegded users.

[zukunft]

I agree with the main goal to backup only openHAB configuration. I suggest that after the backup a message is shown to the user, how many things, items, scripts ... have been included in the backup. This gives the user an indication if the correct configuration has been saved.

[jimtng]

Most switches/routers/wifi access points allow you to take a backup of its configuration, save it on your computer, do a factory reset, or heck, throw it in the bin, and buy a new one, restore that "Backup" and you now have the same running version of the device like before.

That's the kind of backup I think openHAB could use and should have as a part of the web ui (and supported by core, of course).

We're not talking about daily/weekly/monthly backup rotation stuff.

My switch/router mikrotik, also allows saving multiple copies of such backup onto its local filesystem, and allows you to select which backup file to restore. But that's if we want to get fancier. Just allowing the backup file to be downloaded to the user's PC (through webui) and to be restored is a giant first step.