DISCUSSION : BestPratice

Hi, I’m reprograming all my setup ( it’s a 1.8 setup that has been updated and there is a lot of thing miss configure and everything is setup with old 1.x binding, etc. )

So here is my question : which best practice you would recommend ?*

Should I Use PaperUI or just Configfile ?
How should I name my items ?
2.2 or 2.3 ?

If you are coming from 1.8 you will be more comfortable with the config files
The new things are the “things” which can also be added via config files
Wait a little bit for 2.3 stable. Or go for 2.2 and upgrade

No I start longtime ago with 1.8 and update it the day 2.0 goe out but my system is still setup like 1.8 with a lot of config file and some old 1.x addon

but it’s not just about me ! If you had to redo all your conifg tomorrow morning what are the thing that you’ll do like … "This time i will do it right, this time I will : ** insert best pratice here ** "

I have done this. I actually did it when I wrote the Migration Tutorial and the second half of the Migration Tutorial is really addressing this.

  1. Pick one binding at a time to upgrade from 1.x version to 2.x version. Realize that they are usually a complete rewrite and will be configured and used very differently in most cases.

  2. Backup and test the restore.

  3. Uninstall the 1.x version of that binding.

  4. Install the 2.x version of that binding. I personally use addons.cfg to install the bindings but use PaperUI to configure the binding. Now that upgrades work with the Docker images I would probably install the bindings through PaperUI now.

  5. For those bindings that support autodiscovery, I use PaperUI to create the Things (really scan for the Things and accept them from the Inbox). It is theoretically possible to use .things files for all your Things, but some bindings only support this provisionally (e.g. the zwave binding only supports this with the development version).

  6. I still maintain all my Items in .items files and will continue to do so as long as I still have 1.x version bindings (MQTT, Expire, HTTP).

I’m pretty happy with this approach. It strikes a good balance between using the new features of OH 2.x and consistency for those things I cannot.

1 Like