as I originally posted, i do have it consistent = in files.
this test machine went thru “official” approach to use paperui and so on, which for me is not very convenient as having editor for several things and gui for some other is not really very intuitive at all.
I would like to know more about performance drop when using things files instead of paperui things, as I do have defined quite a lot of stuff in thing files which I kind of dont want to migrate to soon to be abandoned paperui.
“performance drop” is a bit of a misnomer.
While running, all things are operating on the same live database.
At startup only, there may be more overhead parsing xxx.things file.
It all has to be bit stressed anyway before you’d notice.
k, so during normal run it does not matter if using files or paperui for things, that’s what I wanted to know. I’m not concerned about boot time tho
I may be in the minority but I hate simple mode. I spend more time helping people understand that one feature than almost anything else in OH. And every time they turn it off and undo what simple mode has done. As a feature, it is IMHO an abject failure.
Why should they be the same? One of the issues with openHAB is we are carrying all this legacy stuff around from openHAB 1. The text files are part of that legacy. When you do things through the REST API in OH 2, your Items and Things (and Rules if you like to run experimental) get stored in JSON format in the JSONDB (/var/lib/openhab2/jsondb). The entries in this get parsed and loaded exceptionally fast.
If you choose to stick to the legacy way, you are using a custom file format defined using the XText grammar definition language. This library is slow and it appears not to be well maintained. It is sited as one of the reasons we cannot move to a more recent version of Java. And there is no writer for this format so even if we wanted to write the config changes made through the REST API back to .things files (for example) we couldn’t because there is no writer, just a reader.
And then you get another problem, there are two sources of truth. There is the stuff done through PaperUI and the stuff done through text files. Which one “wins”? In this case the text files will win, but it isn’t perfect. If you accidentally try to redefine an Item in .items files that already exists and was created through PaperUI, you will encounter errors. But, just to have more inconsistencies, if you accidentally redefine an Item in .items files, the second one loaded will take precedence, no error.
Honestly its a complete and total mess.
I hardly consider myself a beginner and I use PaperUI for exactly the reasons described. They are important considerations for all users.
No, it doesn’t. First OH loads the JSONDB into memory. Then OH loads the text files into memory. They do not get written back out to JSONDB. Except for where they reside in memory, they are completely separate.
There is no equivalent for sitemaps yet but that is in work. The only way to do sitemaps is through a .sitemap file. The same goes for .persit files though I think work is even further along to making that go away.
Items and Things and Rules work like I described. First OH loads them from the JSONDB which is really fast. Then it loads the text configs.
In terms of Rules, it’s worth mentioning that Rules DSL is a completely different Rules engine. There is a new Rules Engine which supports writing Rules in text files (see JSR223) or building Rules through the REST API. Those built through the REST API get saved to the JSONDB as well. NOTE: Jython, JavaScript, and Groovy are the languages supported by the next gen Rules engine right now. We are working very hard to make the next gen rules engine become the default Rules engine for OH 3, at which point Rules DSL will become deprecated, or at a minimum no longer the default.
Programmers have the biggest problem with Rules DSL. It has some limitations (deliberate) which makes it challenging for programmers to code in the way they are used to. That is why I started creating the DP postings. Non-programmers do pretty well with it though because a lot of the complex concepts that exist in “regular” programming languages do not exist. In short, the same reason programmers hate Rules DSL is why non-programmers do well in it.
But when the GUI Rules builder is done being developed, non-programmers will have an environment more akin to NodeRed for building their Rules which will be even better for those users. Programmers will be able to continue using JSR223 Rules.
But, as good as Rules DSL is for new users, it has some serious technical problems:
Everything you do through PaperUI get’s saved to the JSONDB. The same will be true for any replacement to PaperUI because all UIs work through the REST API. The more future proof approach would be to use PaperUI (or the raw REST API) to define as much as you can. It’s the .things files that will, at a minimum, change formats in the future (e.g. become yaml).
At this time though, for Items PaperUI lacks support for tags and metadata and the REST API isn’t sufficient (IMHO) to work with metadata. For Things PaperUI is feature complete. For Rules, PaperUI is very much lacking and has some bugs, but the REST API is feature complete.
Using Things and automated discovery of Things where available is also a long term time saver. For example, in the move from 2.3 to 2.4, the Zwave binding changed significantly resulting in a need to change the Things. For those who used automatic discovery, the process was a simple 1. delete the Things, 2. rediscover the Things but those using .things files had to manually update all of their things. Also, as the zwave database changes with corrections and updates (e.g. new Channels are added) they just get updated if they were automatically discovered. You’d have to monitor the database yourself and update your Things manually when a change is made.
It’s also worth mentioning, I field almost an order of magnitude more questions on MQTT 2.x Things from those who use .things files instead of the PaperUI.
I think this may cause a little bit of confusion. The text configs never actually get loaded into a database as most people think about it. They get loaded into memory and stored in the same data structures as the stuff loaded from JSONDB, but they never get saved back to JSONDB. It’s better to think about it as you are using two different ways to populate the memory OH uses.
omg yaml! I hate that thing! One of the reasons I’m not using HA 
Would you rather hand write JSON or XML? There is no good markup language that people seem to like. BUT, at least all three have a writer, so one can have a migration path from REST API/UI/JSONDB defined stuff and text configs. Then users can go back and forth between the two approaches as needed and there will be one source of truth for OH.