I have a use case where I provide pre-configured OH setups to others.
That just doesn’t work via UI as I don’t have interactive access to the box including the physical devices for this OH instance by the time I (pre-)configure it.
2 Likes
You can with the added benefit that you. can access them from any browser, not just your dev machine.
It’s not necessary. Text based configs are going nowhere. If it works for you that’s great!
It is indeed just as easy with the added benefit that a configurable number of backups is ceated for you automatically.
I did want to add that there has been lots of discussion and some work on ways to make this a little bit easier through MainUI. I’m not surre what the status of these are though but it includes stuff like a table representation of Items, a “duplicate Thing” option, etc. So for now the stuff I mentioned in my post will work for copy/paste/edit type operations, it should be better at some point.
I still expect users of bindings like modbus and knx might still be better off in .things files though.
This is one of the most compelling reasons for using text file based configs. But if you are doing this, then you already know what you are in for and you know where and how to look for which properties can go where and how to solve typos and syntax errors and the like.
I don’t want my post above to come across as anti text file configs.
2 Likes
I only create the things on the MainUI and the items via files.
Rules are a different story.
1 Like
I find that adding things in the UI is incredibly easy.
But because of repeating items, that copy and pasting a template for Items is the best way forward.
But making a UI…
So many options
Don’t miss Developer Tools → Add Items from Textual Definition for something like this.
If you use the semantic model, don’t miss “create equipment from thing” or “create points from thing” to create all the Items you’d link to a given Thing in one go.
2 Likes
Vscode is my GUI 
3 Likes
You’ve mentioned this before.
How does it deal with bulk typo corrections or bulk adjustments?
For example if multiples of items need an update to accommodate a new feature?
Or a change in the binding requires a different channel ID ?
1 Like
- 728 items
- 227 things
- 111 transformations
- 186 rules
- 27 scripts, python and shell
- 15 bindings
I am very comfortable with text based config files and use basic UI sitemap plus Grafana. It all works very well and impresses everyone that sees it on my phone
I use VS code editor to quickly create code. It is great to search for code/ syntax, either in a specifc file or in all files, make changes fast, resuse, copy paste etc; en masse if needed. I like being able to hover over an item and check its state in VSC
I like to learn how to write good code. For me leaning is one of the fun parts and very satisfying when it all works.
I also like to add plenty of comment lines directly in the code so that I can always check at a later date why the code is the way it is.
Currently my backup methods are a breeze. With one click I copy all needed config files to my NAS with versioning too. Also, I mirror the SD cards and keep several generations before any major changes, like updates. eg My recent upgrade to 4.2 destroyed my openHAB due to an issue the putty dropping the connection part way through the update.(still not fully resolved). I also have duplicate hardware making it easy if distaster strikes to move the SD card over.
I might use the new UI way if I was more confident with openHAB back up options and it was as easy to mass create stuff, but so far I have not had much luck eg I just tried the openhab config option 53 backup mirroring which I thought was running and working for sometime but the card does not boot when I needed it. Whereas, thankfully, SD card (BalenaEtcher) mirroring and automated file copying (SynchbackSE) always works and restoration is quick, easy and very reliable.
I have been forced to use the UI method for zigbee but basically, it is not broke and therefore I have no intention of fixing it by moving to a UI method. If I were to eventually be pushed in that direction then it would make sense for me to also review the other platforms as part of the effort.
I’m using text files too.
mainly to have a versioned history and to be able to automate the installation of my infrastructure.
I was primarily referring to the “copy from template” part of your statement. You can copy your template into “add items from text…” which implies creating Items anew by scratch, not editing.
However, you can quickly remove all the Items linked to a given Thing and recreate them in those cases where you need to do something like that.
I’d either edit the Items manually, use the REST API, or most likely remove the Items and recreate them using “add equipment from thing”.
Both this and the prior case are relatively rare events. I’ve had to do it maybe twice in all the years I’ve used OH.
I don’t have to do anything. For managed Items/links, if there is a change in the binding, the Links are automatically corrected as part of the upgrade process.
Just to show how we don’t necessarily give up all of this stuff by using MainUI and managed configs:
- “It is great to search for code/ syntax”: Search in the developer sidebar searches within all OH entities. So you can find anything same as searching within VSCode.
- “either in a specifc file or in all files”: for searching within a specific rule (for example) one uses the browser’s find in page feature.
- “make changes fast, resuse, copy paste etc”: all of these can be done in the UI as well, especially when taking advantage of the “code” tab. Within rules there is the cache and support for libraries as well, those are not just a text file rule thing.
- “I like being able to hover over an item and check its state in VSC”: in the developer sidebar I don’t even need to hover over the Item. I’m also able to command the Item from there as well.
Again, I’m not against text file based configs. Obviously you need to work in ways that work best for you. However, I want to point out that you don’t necessarily give up all these advantages of text file based configs when you use managed configs. If we did, I wouldn’t use it.
I see nothing here that is specific to file based configs. The only real difference between managed and file based configs when it comes to backup is which files to backup and restore.
Backup should be the same. If you save $OH_USERDATA/config and $OH_USERDATA/jsondb you’ll capture everything that you currently capture by backing up $OH_CONF. Even better, use openhab-cli backup and it will grab everything OH related whether it’s file based or managed.
openHAB is not openHABian. You are talking about openHABian here, not openHAB.
And once again, no one is pushing anyone anywhere. File based configs are here to stay.
I keep a versioned history too. Maanged configs are text files.
I had a quick look at you ansible tasks for OH and I don’t really see anything there that would not work with a managed config.
Again, not saying anyone should change how they are doing things. Just making the point that one does not automatically give up all these things by using managed configs.
3 Likes
Currently, when I update openhab, I recreate the whole container and discard all data, except the jsondb folder, the persistance folder and my text based configuration files. I deploy a ‘fresh’ container and reapply these files and folders.
With this procedure I had nearly zero problems when I upgrade to a new version since years. (Except there are changes related to my config files)
Additional benefit for me is that I can refactor things much easier with VSCode and text based files. If you have to deal with hundred of items, it happens from time to time.
Another benefit is that my thing and service files are ansible templates (just normal thing and services files, but with placeholders). This means my passwords and other sensitive data are stored in an encrypted vault file which is not part of my github repository.
1 Like
The container kind of does this already for you when you do an upgrade. It’s doesn’t do the “reapply” part of course, it couldn’t. It just leaves those files and folders alone. Whenever the the container sees the config files are for a different version than the version of OH in the container, it takes a backup and cleans most all that stuff up so it can be recreated with the new versions of things.
I’ve had no issues do to upgrades either. If this works for you that’s fantastic! I just don’t want people to think it’s necessary. When using managed configs there’s the added benefit that during an upgrade many breaking changes get automatically mitigated so there is manual changes required.
I’ve found this to be a very rare occurance over the years. YMMV. For me this happens rarely enough that I’m willing to pay the price of needing to mess with the JSONDB manually or REST API, which is definitely less convenient, and get the day-to-day advantages I get from using a managed config.
I can see this as a good approach to keep that stuff out of source control.
I just host my own git server (gitea) for my OH configs and other sensitive code and configs but if you use github etc. you do need a way to keep that stuff encrypted or excluded.
Though there’s nothing preventing using a template for deploying the JSONDB files. But it would be less human firendly than doing so with .things files.
Note, there is an issue and I think a PR started that hasn’t been updated in quite awhile to add secrets support to OH natively. It would be great for someone to volunteer to pick that back up and get it over the finish line. Then secrets in OH would be encrypted natively, at least for managed configs. I’m not sure how it would work for .things files.
Boy, this blew up … I jumped in for a snoop and saw the variety of replies. Of most interest to me is how people are handling things like templated items. It looks like no one has developed a perfect solution for that scenario, but many people are ‘getting by’ just fine with the solution they’ve developed.
I thought I’d share mine.
Firstly, I use the UI for nearly everything - things, items, rules. Taking on the mantra of DRY, I have a lot of more substantial rules tucked away in external .js files and I’ll include them as necessary. I used to use VSCode for them, but switched to UltraEdit recently. If I can’t work out how to write a particular rule I’ll sometimes use Blockly to generate some javascript that I can then bastardise to my heart’s content.
Template items? I got sick of trying to remember the groups and metadata I’d applied to one smart plug and then re-apply it to the next one I add. So I’ve taken to creating these in Google Sheets. I’ve created my own list of item types with their default values - which groups they belong to, any essential meta data, UOM, semantic tags, default label, etc. Here’s a small snippet of what that looks like:
In another sheet I then add my items, choosing my “Matt OH Type” and filling in any more item specifics (Thing channel, metadata specific to that item, etc). A formula on this sheet then combines all these into something I can copy and paste into the Textual Definition.
The bonus, for me, is that I’ll often discover I need a bit more metadata for one of my templates - or some code change I need is requires specific Item Group to operate over and I need a bunch of items added to that group. I add that to my template sheet and the formula outputs a new textual definition for me - I soon discovered that pasting this in re-creates any pre-existing items from scratch (keeping any persisted values). A new use case I’m discovering is that the cheap set of TP-Link smart plugs I bought recently are burning out one at a time - I can update the Thing channel easily with a search / replace and point existing Items to the new (more expensive, more durable) Thing.
So far I’ve only got my new / frequently edited items in here as I develop further, but over time I’ll add in some of what I’d created on day 1. The end result will serve as an additional back up by the time I’m done.
4 Likes
This made me smile! It’s cool, and goes to show that spreadsheets can indeed be used for just about anything!
1 Like
As long as the name of the Item remains the same, persistence should follow along. You will run into issues if you change the name of the Item though.
It used to be the case that Links and Item Metadata also would similarly follow along. I don’t know whether that’s still the case or not. There has been lots of discussion and a few PRs over the years over whether metadata and links should automatically be removed when the Item goes away or not and it has been some time since I last checked to see what currently happens.
That’s one of the big features that the Blockly maintainers strive to maintain. They work very hard to keep the JS Code generated by the blocks simple and easy to follow so that it can be used as a learning tool just as you are using it.
I’d like to point out that even for text file based users, if you are not going to use the docs or you can’t find what you need in the docs, create the Things/Items/whatever in the UI and click on the code tab. It’s usually very straight forward to translate the YAML you find there to what you need in your text file config. All the properties supported by the Thing (for example) are presented to you in the Thing creation form with a sentence of two describing the purpose of each and the names of the properties you see in the code tab match exactly the names of the property you use in your .things files.
I wish I had a nickle for every question asked on the forum that could have been answered faster and more completely if the user had done this.
That table view of Items I mentioned above sounds a bit like this without the templates through. I do like the idea of custom tempaltes for the Items. Personally it would be really nice for applying default x widget metadata and state description patterns in a consistent way. That would be a nice addition to OH I think.
If you were really enterprising, I bet you could create some JS code in the script to call the OH REST API directly to inject these Items. It’s been a long time since I’ve worked in Google Sheets in this way but it can be very powerful and I’m almost certain something like this would be possible. But this would be even better if it were built in to OH itself.
Something I’m curious about is why people frequently edit Items. What drives this? Are you just adding lots of stuff right now, deciding to change your naming scheme, experimenting? For the most part I almost never have to touch my Items once they are first created so I’m curious why others seem to mess with them so often that building tools to manage them becomes attractive. This is more for the regular users, not those who are building maintaining a lot of OH instances for others like @mstormi described.
I discovered through breaking stuff that they do not - so I build those into my sheet so they are re-applied. I liken it to “remove + re-add”. I guess persistence is maintained simply because it’s separate (?).
I also wish I had a nickle for every time I boil the ocean trying to devise a solution when I could have tried Blockly to cheat from the get-go.
I did consider it and came to my senses after realising I needed a solution, not the solution.
Developing / refining. I use some ‘support’ items for some things as well (eg. smart plugs might have a ‘power mode’ - auto / manually on / manually on until midnight reset / etc). If I discover a use-case for a new such support item, I’ll add it to all items that match that template. Or I might need a particular bit of metadata to support new functionality I’m adding - into the template, built dynamically, then I can be confident all items of that template type receive it. Most of my coding so far has been around power switching and monitoring; when I start automating my hue and other lights I’m confident I’ll be making and switching design decisions a few times over.
1 Like
Links and Item metadata are stored separately too.
I use the UI
I’m a software engineer and edit all kinds of files.
I use an IDE (a GUI for editing source code)
I get my fill of text editing at work and if there is a good enough GUI, I use it.
3 Likes
Hi,
I use the GUI if possible. The only text configs left are some mappings, transformations and service configs. Ok, sometimes I alas change jsondb with vi if I don’t get it in the UI
For the rules I use only JavaScript. Sometimes I use Blocky the get an idea how they would solve a problem and then copy the code.
I like the UI even if it has some issues if you edit to much. Then sometimes it has to force reloaded and start over. Maybe 290 things / 1200 items are to much…
Regards
Christian
Have you noticed that mappings and transformations can be configured in MainUI 