Recommended way to backup/restore OH2 configurations and things?

After reading through most of the previous answers I want to emphasize this statement. Seems like there is a very common misconception among new openHAB2 users.

PaperUI is not needed to accomplish what you want to do with openHAB2! After having my initial difficulties I completely abandoned PaperUI from my personal workflow and am 100% relying on conf files in my OH2 setup. The PaperUI is just one way of interacting with the openHAB 2 core system. Configure your bindings in addons.cfg, services in the corresponding *.cfg files, your things in the things folder, items in the items folder, rules in the rules folder, … you get it :wink:

My personal feeling is, that people first interacting with openHAB2 are drawn to the interesting new PaperUI feature and get misleading expectations. We are trying to solve this problem in the documentation, which is supposed to grow strong in the next two months. Please anyone with clear input on what the documentation should describe, take part in the discussion at Add warnings and/or deemphasize use of PaperUI · Issue #110 · openhab/openhab-docs · GitHub

In another thread I already proposed my idea of an approach to unify the “classic” configuration and the database. Here’s the short version:


I want to vote towards the database approach in combination with what I and others mentioned before:

  • Thing/item discovery and adoption through PaperUI
  • Thing/item handling and modification though PaperUI
  • Increase of UI functionality over time
  • While there are not all functions available in PaperUI, mainly for the tech-savvy user:
  • Direct database access through some existing frontend like phpmyadmin (not offered for mapdb? mapdb alternative an option?)
  • More powerful options on the karaf console (random example: smarthome:items 5 rename 'Bathlight')
  • RAW-view edit through PaperUI (compare InfluxDB data source | Grafana documentation → “RAW”)
  • Export and import of all relevant data from the database to a human-readable file format like xml (as a last resort)

My proposal supports three things:

  1. A clear transition from not-ideal items files to a more suited and system-managed database
  2. Providing the right tools to aid the tech-savvy users to adopt to the new system while not being restricted to a UI
  3. Motivate tech-savvy users to use AND contribute towards a powerful PaperUI
10 Likes