I just migrated from OH2 to OH3 all works fine (apart from one rule that uses jodatime, which I have not been able to rewrite to java time with all the info I have found so far).
Until now I have been using VS Code with the openHAB Extension. So all of my configuration is done in files. And as I use github for version control it allows me to " go back to how it was" when I mess up things by adding new items or changing rules.
I read the advice that with openHAB 3, it would be best to start anew and do all the configuration from the web interface, which I am considering to do.
But in doing so: is there a good way to keep doing CM/Version control?
I hope someone has some advise on this!
Because although it is still supported it certainly does not have focus, at least that is what I concluded from reading the updated documentation. The documentation mentions more than once that adding items through Main UI is the recommended way of doing things.
The documentation also mentions that having a good semantic model is important, yet there is no documentation that describes how to do that in files.
As an example: Configuration | openHAB does not even mention semantic models
So my idea was to maybe: " go with the flow" and step away from using files but keeping a way to do versioning.
A visual person or a new user, especially, find a UI approach works better.
It is basically a combination of Item Groups & tags. Locations are groups, for instance. Since it was originally designed for HABot, the documentation is scattered. Here is some.
From what I read in the documentation I kind of guessed that, Bruce. But it is not stated in that way in the documentation. But is still leaves me guessing how I could create “Kitchen as part of Downstairs as part of House”
In my configuration I have an item that is exposed to Google Assistant using as a Blind:
Rollershutter GarageSim "Garage Door" [Blinds]
It is the only thing that shows up in the model page because that defines it as an equipment, but how I can make this equipement part of the House->Downstairs->Garage?
So instead of asking all that I thought " maybe I should start using the Main UI"
Maybe I should also add that as I started this in OH1.x I use it mainly for rules and items and never really added the things in files, those I added using the web interface. (And linked items to channels using the VS code extension)
I had already tried adding groups etc and could not get that to work. I just realised why: the configuration files have moved from /etc/openhab2 to /etc/openhab, which means that my nfs export of /etc/openhab2 (for VS code) changes files that are no longer being read. I did not realise this as openHABIAN took care of all of this for me…
There’s many religious fighting on text vs UI but on the pragmatic side I think this (config mgmt) is what it is about.
Same for me. When OH2 introduced Things, I started adding them via UI as that was the recommendation. Even although PaperUI is history now, looking back that still was a smart move as I was able to take advantage of the UI capabilities.
Bottom line is that Things have not really been an issue in terms of config management because they rarely change.
Note I kept my Items in files throughout OH2.
Now in OH3 it’s more or less the same again with Items. History DOES repeat
The IMHO main point to consider now is that there will be functionality that cannot be configured via the old items file format such as the Semantic Model extension and its metadata or UI definitions such as widget looks. Note I’m not saying you cannot configure them via text. But it’s new functionality that cannot be force-updated back into the old .items file format.
This is why I took OH3 as the turning point and started with Items in GUI this time (@Spaceman_Spiff yeah I also hate I had to. But the world keeps on turning).
There’s some people to use scripts to generate the initial config or extension batches.
That now you still can do (you can use the batch import feature).
Once the initial config batch is in, using the GUI to maintain Things and Items is even more efficient than doing it in text.
My Rules are still text of course.
Now take a break and reevaluate the situation:
If I understood you correctly, what you call “configuration” really is Things and Items only. Am I right?
With both of them now in GUI, I have effectively eliminated the need to do configuration management (the maintenance part) in files.
PS:
don’t mix or confuse config mgmt with backup/restore. All OH data incl. Things, Items, Rules, all new GUI features ultimately IS stored in text format (in JSONDB) so can be backed up and restored.
But this does not have anything to do with config management. It’s a completely separated thingy.
This sums it up perfectly!
I use GitHub - ddt3/OpenHab2: My openhab configuration
mainly to do versioning on rules (and related to that items) but rules being the most important. In general because I would like to answer questions like “what did I change, when did I switch over to that” and to roll back a change in a rule when I started realising my brilliant idea was not such a brilliant idea after all. Maybe I should add that in a past lifetime I was responsible for SCM of a software team, so I felt like I had to
I too would like to take advantage of all the new things and UI capabilities.
And if I really look at what I do CM for , it is not so much the items: it is the rules which as you mention are still text…
I think I will start from scratch on another system and once I am satisfied with that, replace the running OH with the one I created from scratch
I regularly merge rules and items between multiple openhab instance and with text files it’s just so much easier. I already structure them by functionality and once a feature is stable or a feature get’s updated it’s just copy pasting and syncing through the cloud to the other instances.
The nice thing is that this also deletes obsolete items that I don’t need any more.
I know the conversation has continued somewhat, but if it helps I’ve just written up my notes on creating a Semantic Model using configuration files. You may or may not find it helpful!
But what is the suggested way of managing widget code? Is it only possible to define them via the UI? How to do version control? I have all my files in git.
Widget definitions like anything else of the UI are ultimately stored as YAML text in jsondb but there’s no “input file” feature.
You quickly create new widgets by storing then copy’n’pasting the YAML definitions from the code tab.
(you can even edit YAML offline but that’s tedious without being able to see the effect in GUI so no point in that).
