That is my main approach as well, but rather than not wanting to destroy my installation, I very intentionally destroy it on every startup. Or rather recreate it from things and items files. If you feel you have free time to invest, looking into docker would give you revelations in that “has-to-be-cleanly-recreatable” approach.
Hear hear. I want to have a system that can be recreated from a clean image without any manual interaction. Which in turn means that we are back at a docker image and lots of things and items files
And the recommendation of most on the forum would be to but charge this. Keep your items in. Items files organized in a way that makes sense to you. Though realize that PaperUI supports a search function that makes it very easy to navigate the big list of Itens or things.
This raises a bigger issue though as if you followed the migration tutorial the Links would not have been automatically created. The only time links get automatically created is when simile mode is turned on, in which case both the item and the link are automatically created. In simple mode you are not expected to ever deal with Items directly which is unworkable for someone coming from OH 1.x, which is why the tutorial sends you down a path that avoids it. So either:
there is a mistake in the migration tutorial
there was mistake made when you followed the tutorial
something else is wrong.
This IMHO should be the primary focus. Assuming the link was automatically created, what went wrong to cause that to happen. Because links don’t just get created automatically outside of simple mode.
I’ll also reiterate something I mentioned from the very beginning. You don’t have to mess with any of this. You can continue to use the. OH 1.x bindings pretty much the same as your always have. Nothing new to learn. Very few of any changes to deal with and limited amount of your time is required. You don’t have to migrate to 2.x versions of bindings. If you stick to 1.x version bindings you don’t have to mess with Things or Channels or Links at all. I kind of expected this to be the path you would take as it is the path requiring the least amount of time, effort, and new concepts to learn. IIRC you were facing a memory leak problem which the move to. OH 2 as the core should fix. But you don’t have to use OH 2 bindings too long as there is a 1.x version bindings to use.
As someone who uses Docker and who destroys and creates his containers at heart I’ve a week, what exactly do you find lacking the the JSONDB in this scenario? Is a text file. It’s well formed and has a defined format. You can check it in to git or your source control of choice and keep track of history. You can edit it by hand. You can mount it into your container through a volume.
I know these because I do all of these. The only differences between .things files and JSONDB are
JSONDB files are in a different folder
you can’t edit the JSONDB by hand while OH is running
JSONDB is a little less human friendly in its format
JSONDB uses a standard format with support from editors and lots of libraries, .things and .items files use a custom format based on Xtend, that much maligned base for the rules language
you can have bindings automatically create Things for you with JSONDB, you have to research the syntax and format to create .things files
-JSONDB files get automatically backed up
I just don’t see why so many users assert that if you use automatic discovery you are giving anything up except the ability to edit /add Things by hand while OH is running. Literally everything else, including add,/remove/modify things by hand while oh is offline you can do with .things files you can do with JSONDB.
This is the FUD in refurring to. There are lots of reasons one may want or desire to avoid using JSONDB, but the ability to rebuild a clean environment isn’t one of them.
For my part, I consider the jsondb file to be internal knowledge of the openHAB / smarthome core and the items / things / rules files to be the external interface. It’s not the human-friendlieness, or editability while running, it’s just that I like well-defined responsibilities in software, and the jsondb belongs to the core for my taste…
Also, if I as a developer cannot set up my OH system with just the external files and the documentation for them, what hope does a semi-normal user have? The beginner user would be pointed to PaperUI, of course…
Just as I would not manipulate class files (which I did when necessary, I also wrote enough bytecode manipulators for $WORK) when I can use the java code and have the compiler convert that well-defined “text files” to something that can be executed.
As I’ve always said, there are good reasons to use .things files. And what you describe IS a good reason. But when you extend your personal preference to not treat the JSONDB as configuration to a posting that implies that one CAN’T treat the JSONDB as configuration is when I have a problem because then this tells users who may not know any better that there is something mysterious and inviolate about the JSONDB which is not true.
Not everyone will have the personal preference to treat the JSONDB as if it were internal knowledge about the system, Some may be perfectly happy treating it as configuration which can and should be managed as such. But when users post a sentence like “I want to have a system that can be recreated from a clean image without any manual interaction” that strongly implies that one cannot do this using JSONDB, which is not correct.
This indeed is a tricky issue, but only with regard to what we understand as who the user is. Please bear with me for a while:
1 - if we consider the user as being end user (like a totally non technical person), yes, you are right
2 - if the user is at least willing to achieve a certain knowledge, no, you are not
openHAB is a framework that somehow got the characters from the above two points in to a swirl (which I consider is great - there are benefits on both sides)
Again, we should define who we are addressing: if one shall want advance capabilities, then one should build his knowledge in order to be part of the crowd in point 2, without being frustrated that he/she is a part of the crowd in point 1.
