In the light of things to come (OH3, that is) I’d refrain from this move.
Yes there’ll be a replacement for PaperUI/JSONDB but unclear if there is going to be anything to replace or keep the text files for things and items.
I recommend to stick with this recommendation.
1 Like
You can do these with changes made through PaperUI too.
It’s mainly because OH may save changes to the files you just edited, wiping out your manually made changes.
Just to elaborate on this answer a bit. addons.cfg always takes precedence over anything installed through PaperUI. So if the addon is not listed in addons.cfg, it will be uninstalled automatically.
If you are serious about dumping everything without being careful, you can stop openHAB and delete the files in $OH_USERDATA/jsondb. That will wipe out all the Things, Items, and Links.
When deleting Things through PaperUI, make sure to delete the Links before you delete the Things or else the Links will hang around and OH will think the Item exists even after you delete it because the Link remains.
You can’t set parameters on zwave devices when you have .things file created Things. Also, automatically discovered Things always just work. You never have a syntax error. You never have to research what parameters are required or available.
You can change the name of any Thing at the moment you accept it from the Inbox.
There are alternative ways to achieve this while still using the REST API (not PaperUI). My preferred is to create the first Thing, query for the Thing using the REST API Docs, copy/paste/edit the json, then create the Thing using your edited version of the JSON through the REST API Docs.
It’s not perfect but the advantages of being able to use automatically discovered Things, avoid syntax errors, and have just one way to configure Things make it worth while. And as has already been mentioned, they get stored in a text file so all the backup, source control, etc type things you may want to do are supported.
I don’t think that is still the case. But if it is it’s not really that big of a deal if you give the Bridge Thing the same name as it had before. When the Things are rediscovered and accepted they will have the same ID and all your Links to Items will be preserved.
I don’t think anyone will argue that PaperUI is anything but awful. But PaperUI is not the only way to work with Things without using .things files. And many of the issues brought up look like they are on the way to be fixed and made much better in the OH 3 UI replacement.
But I have to spend exactly zero time researching what parameters are required, not required, available, and messing with syntax errors. Slightly more awkward but requires far less time in the long run.
And you beat me to the grand conclusion. It is unclear whether .things files as they exist today will be supported in OH 3. The same goes for the rest of the config files.
Users won’t be left hanging. I’ve already tested some very early versions of the PaperUI replacement and they’ve build in a way to copy one or more .items file Items definitions and import them into OH. I would expect/hope for the same for .things files, .persist files, etc. I’m not sure what will be possible re Rules DSL files, but some sort of way to migrate those has been mentioned as well.
I wouldnt know of any other ways to work with it. I like textfiles cause it gives me the best overview, plus I can have catagorise through textfiles as well.
Often when using textfile, either the developer have already done most of the job, or there are examples here on the forum to grap.
I wouldnt mind having some other way to do this, as long as I get the same overview and have the same possibilities to categorise, (if needed ofcouse).
Not for the zwave devices, for example. I guess you could try querying the database but that is not too intuitive compared to something that “just works”.
I know… That why I said, “often” 
Considering that is my main binding for Things. your “often” is my “very rarely”.
And if OH3 development goes similar to OH2 then I might find it stable and suitable enough with version 3.3 or 3.4 - so we are talking about 2023ish. So for the next 3-4 years I still prefer to organise my OH2 as I prefer.
What I really don’t understand is this, almost fanatically religious, urge to persuade people to do things the way you decided for yourself. @hmnb stated clearly that he wanted to switch everything to text files and had a few questions regarding that issue, which I tried to aswer to the best of my knowledge …
And deleting Things in Paper UI that way is the only one that I know, but I hace to admit I only ever did it once with someone else’s setup who also wanted to switch to text only files.
Anyone knowing a better way to delete things in Paper UI to set them up in text files, please feel free to write it here, instead of trying to advertise doing it through Paper UI, as obviosuly he wants to get away from that.
The official Docs also do state that text only files are definitely a viable option, so why not let everyone do what they prefer to do and try and help them with their problem, instead of some desperate conversion attempts??
I think I just did.
If you are serious about dumping everything without being careful, you can stop openHAB and delete the files in $OH_USERDATA/jsondb. That will wipe out all the Things, Items, and Links.
Since you asked… because I and most of the other people who help on this forum spend hours helping people with problems they would not have if they didn’t use .things files. Why do we push people away from .things files? Because it saves our time.
Maybe its selfish, but there you have it. Users, particularly users who are not experts in the bindings they want to use, consume out sized amounts of our time in support on this forum because of syntax errors and questions that would not occur if they used automatic discovery or PaperUI to create at least the first Thing.
That now is unfair, inacceptable blaming of the developers who aim to do all of that for YOU and all the other users (most of which do NOT want to cope with text input).
Because you don’t have insight to the code architecture. It’s really unbelievably difficult (and no core developer dares trying) to consolidate the current “text” and “GUI” input tracks which is why we have this awkward dualism in current OH2 already. Which is one (if not the one) major OH issue today.
I prefer text, too, but on the other hand it is merely an almost fanatically religious urge (as you call it) to demand keeping the current text input method for things and items.
Take a breath and step back a little. Once you take a look at the big picture from some distance, you’ll get to notice that adding+editing things and items is a one-time action for the most part.
(Well it might be divided into multiple steps, another one to be taken when you add a new binding or similar substantial extension, but essentially, you need to do all of this ONCE only).
And that’s where @rlkoshak is right: you get that faster done in a GUI where you have immediate access to the linter/docs etc and cannot become a victim to syntax errors. Let alone that he promised there’ll be a migration/import feature for existing files.
Mind you rules are a different story. While the ‘outer’ part of a rule (triggers) can be entered via GUI like NGRE already allows for today, the ‘inner’ part (body) will remain to be text files of some sort, simply because you cannot ‘GUIfy’ the programming.
You did, but by that time I was so agitated by some of the superfluous one-liners saying ‘You should only use Paper UI for things’ that I wrote what I wrote. For items, thankfully, text files is still the recommneded way 
Honest answer, thank you! And you are definitely always trying to be helpful from seeing your posts, but again, some non-descript one-liners just saying everyone is wrong for using text files only really are annoying.
You definitely got that down the wrong throat, I did in NOW WAY mean to downplay any of the developers or the development of openHAB, but with the many bindings that I use and my whole flat completely depending on openHAB it wasn’t until 2.4 (core and the various new OH2 bindings!) that I could confidently and safely switch from OH1 to OH2. I didn’t blame anyone for waiting that long, and was happy that the development came to a stage suitable for me.
I will happily wait for such a time again if I find it necessary with OH3, without complaining about it or trying to blame anybody.
Trying to turn my honest described behaviour here into some slagging off of developers or the development, that is not fair.
True, I might not have insight into the core architecture, but defining everything in text files - from Things, Items down to Addons, Runtime, Epemeris, Regional, Basic UI, Charts configurations works perfectly fine in OH2, and it is my, and some others, current preferred way in OH2.
Come OH3 and the time I decide to switch over, I am more than happy to follow anything required then by OH3. 
No, this is much too much work. Remember i don’t have just 10 things, it’s more than 200 things.
That’s nonsense, when the file is free of errors, it’s free of errors. I do not type the file manually again all the time.
Look at the first point. It’s not! The autodiscovery thing names tend to be either guids or other technical names, i like them human readable. And short. Because my Item Names consist of <thing_name>_<datapoint_name>.
More awkward and it’s far more time in the long run. When the files are done, they are done. Whenever someone has to recreate his 20 or so mqtt things in jsondb, i guess we will hear his curses everywhere.
Perhaps. But we also do not know, if the structure of JsonDB will bee 100% compatible or if we need to rediscover everything. So what?
As long as no really suitable technology exists to do it differently, i will use things-files. All the current tools to create things without files only work for a small number of things or are too complicated.
avmfritz,bosesoundtouch,hue,http,icloud,mail,network
I’d still deem myself a beginner in OH, but experience in other software system. I personally prefer configuration-as-code style hence I’d raised this topic.
While I understand the reasons for UI based configuration and it’s upsides, I think there should still be a possibility to configure OH using some sort of text files. I don’t mind whether thats yaml, json etc. it can also be a MapDB format, I don’t care. I’d still like to have that “expert” kind of mode of setting up and extending the system.
That possibility should be the foundation for configuration of OH from my point of view. On top of that I’d see UIs, whatever they are called. I like the current Paper UI showing my the runtime config, bindings, things and items configured using the text files though.
Whether using text files (for experts) or UIs for configuration should result in a central configuration store. The UI is just the “glass” to this configuration store.
Where did I say anyone is wrong for using text files? My specific replies to you enforced and elaborated on your answers. I didn’t even disagree with your suggestions. I provided additional information to your answers.
Beyond that my “one liners” were correcting some missperceptions and misstatements. I honestly don’t care all that much if a user chooses text files for Things as long as they have complete and accurate information about the implications of the choice. I have a bias of course which does come through but far too often the advantages touted by .things file advocates are either outdated or simply not true. Not all of them but many of them. When I see something that implies or outright states something wrong I’m going to correct it. Otherwise the forum becomes full of FUD and we spend too much time correcting wrong understandings rather than solving real problems.
That’s not the same thing as can’t be done. Your original statement implied you cannot change the name of a Thing in PaperUI.
And yet so many users consume so much of our time with syntax errors in .things files. Good for you. Can’t say the same for hundreds of other users though.
???
My Zwave controller Thing ID is zwave:serial_zstick:dongle. My Zigbee coordinator is named zigbee:coordinator_ember:huszb. My MQTT Broker Thing is called mqtt:broker:mosquitto. They are all human readable.
When the Things are created in PaperUI they are done. So what’s your point?
No one is recommending creating 20 or more MQTT things in PaperUI. But I converted my 130 MQTT Things to JSONDB when I moved over to MQTT 2.5 in about the same amount of time it would have taken me using .things files with copy/paste/edit on the JSONDB itself. And I did an additional few dozen through the REST API using the procedure outlined above.
And that’s just fine. But if you state or imply something cannot be done through JSONDB managed Things that can be done, I will continue to chime in and correct the statement.
I’ve said this many times before and will have to say it many times in the future. My replies to anyone’s topic is not just about you. These posts stay up forever and future readers will come across them. If incorrect information remains unchallenged then we are doing no favors to those future readers.
The hue textual configuration is well documented and easy. You just need the lightId as an attribute and you can get that from the hue app. Navigate to the about page of the app, there you will find the lightId. The types are well documented in the binding documentation.
This is the syntax i use if a bridge is involved:
Bridge hue:bridge:<bridgeid> [ ipAddress="<ip>", userName = "<username>" ]
{
Thing 0210 15 "SZDL" @ "SZ" [ lightId="15" ]
}
I used to use the network binding as well, it’s pretty straight foward, no bridge involved:
Thing network:pingdevice:10_10_10_1 "modem" @ "FE" [ hostname="10.10.10.1", retry=1, timeout=5000, refreshInterval=60000 ]
I do not use the others, so i can’t comment on that.
NOT YOUR one-liners @rlkoshak!! I thought I made that clear by saying " by SOME of the superfluous one-liners" (not by you!) and that “you are definitely always trying to be helpful from seeing your posts”.
This topic really always gets the emotions rising up I just hope that a UI representation of easily textually configurable files will see the light in future (OH3??) incarnations. I think this is also what @hmnb means it his last post. It sort of is already this way, with all the manual text file configurations being visible in Paper UI or retrievable via the karafe console. Just as I mentioned before, the Docs could do with more updates for people preferring text files, which would also alleviate the previously mentioned support issues in this forum.
Out of these I only use the network binding, which obviously already has nice textual configuration details on its doc page.