Greetings all,
I was hoping someone could provide me an explanation of the difference between creating items manually in the items file as opposed to creating and mapping the items in the Paper UI.
Would also appreciate insight on which is best to use, the pros/cons, and what is considered to be best practice.
Thanks !
One of the main pros I can think of right off the bat for items files, thing files, is that you can link your system to github, svn (source control systems).
And upon install of new system pull your entire config from source control or after a change that fails you revert to previous version.
I use things & items files everywhere. I removed all bindings which do not support thing files.
This is really helpful if you have many identical things, you can simply copy and paste complete configurations, instead of clicking and waiting and clicking again.
That is really interesting, thank you.
Is there any documentation available anywhere that can outline and walk me through getting started with this ?
I assume using something like Visual Studio Code and linking that to github would be part of the initial setup.
Not sure there is actually. Yeah that would be part of it. Visual Studio code, link to a repository. And then you edit in visual studio code then perform a commit.
Then on your openhab system, do a git pull and pull the updated code from repository.
There will be methods for the openhab system to be updated automatically but I haven’t got to that point yet.
Use paper ui while keeping an eye on the files option. You’re learning a lot so take one easy path. If config files and code are not your forte then use paper ui.
I’ve petty converted everything to files now for reasons stated above in other posts. In the early days I used the gui as it is very simple.
File option is far better than UI but another thing to learn.
C
With all the example files of things, items, sitemap, rules, etc… found in the doc’s and here on the forum you shouldn’t have an issue. If you do hit a snag, were here to help.
I would highly recommend using VSCode with the OH extension if you do choose the file route.
Oh almost forgot, I also would recommend the file route to anyone, but that’s just my two cents.
Personally I use Paper UI only. A mix of paper UI and files is not recommended, because you cannot interact (delete/alter) with items/things created by the other service respectively.
The backup argument doesn’t hold by the way. The JSON database where paper UI created things and items land in, is human readable and can be backuped to a git repository as well.
Cheers, David
You can do that with JSONDB too. They are just text files. I do this myself. This is in fact my backup and restore strategy (with the added help of Ansible to rebuild the machine in the first place).
There are several. Here is one I wrote up awhile back. Actually that one was a REALLY long while back, pre OH 2 days. This thread might have some more useful information. The big thing is to make sure to include /etc/openhab2 and parts of /var/lib/openhab2 in your configuration control. You can use two different repos or use the symlink trick I described to make the checked out repo appear in the right spots for OH.
I’d apply a nuance to this and say using a mix of PaperUI and files for the same type of thing is not recommended. For example, I manage all my Things through PaperUI but I manage all my Items through .items files.
Part of this is just legacy, I got started on OH 1.x so already had .items files. Another part of this is because PaperUI does not yet have full support for all that Items do like tags or 1.x version bindings of which I use several because there isn’t a 2.x version yet (MQTT will soon be replaced thanks to your hard work, but I still need Expire (I haven’t seen any discussion on that issue you opened awhile back concerning Timers in ESH) and HTTP). So for consistency I’ve kept my Items in .items files.
You will find many opinions on this matter. My own is to let PaperUI manage binding installation and configuration and Things and use text file configuration for everything else. Given the current state of the art, this provides a good compromise between taking advantage of all the goodness in PaperUI and support for some newer (e.g. tags) and older concepts (e.g. 1.x version bindings).
It’s not so hard to change over if you need to at some point. I’m somewhat surprised someone hasn’t written a script to go back and forth yet between the two.