With oipenHAB2, setup is now done with PaperUI and everything is hidden in a mapDB database. Hopefully, for advanced users, it is still possible to use config files to define things, items, …
What is missing in my opinion is an help to create config files from the current setup. I would like to use PaperUI in a first time, PaperUI would discover things. Then I would like to put data in my config files (and so avoid loosing everything the day my mapDB is corrupted) and I need something that could help me to create the corresponding config files.
I have not yet studied the following point: is it easy when you have a thing or an item object to produce the config text ? Is it just one method to call or just a little more ?
I was asking myself if it could be a good idea to enhance the REST Api to provide the option to get the result of a GET things or GET items for examples as a text that would be what to put in a config file, rather than a JSON result ?
There’s another option that I’ve been thinking about, and with all the problems with the framework at the moment, and having to delete my mapdb database yesterday (!!) I might have another look at this. That is to replace the mapdb database with a text file - either json, or xml. This wouldn’t have the same format as the config files, but would provide the same functionality - ie advanced users can get in there and modify the files easily, or fix them if the system breaks them.
This would allow full support for configuration using paperUI/HABmin/etc, but still support the ability to edit files at any time…
Ok, that would be a good idea.
Would it replace in practice (in your idea) the usage of config files ? Maybe it is cool to have the option to put separate things in different files and having a more human readable syntax than JSON/XML ?
For me, yes, it would replace the config files, but there’s of course nothing to stop both be used just as it is today (ie instead of mapdb and text files, we have json text files, and the config text files). So you can still put the different elements into different files if desired.
I’ve not (yet!) looked at this to see if it works, or if there are any downsides, but I think it should work, and I think it provides a good middle ground compromise between GUI configuration and advanced editing. Json and XML are pretty readable - maybe not as readable as the config files, but they are more structured.
I too think this would be an excellent feature. Definite benefits for advanced users (are there many OH2 users at this point not somewhat advanced?) – also seems like it could be a big help in tracing down things like what it is in the mapdb that is requiring deletion in the currect binding startup issue as you alluded to @chris.
As far as speed it seems like the objects are basically stored as JSON in the mapdb files so you would think there would be similar deserialization cost. Probably a little extra overhead with things being in multiple files but that shouldn’t be too bad.
Personally, I like the idea of using mapDB, rather than straight config files (xml or json). Scalability, performance, and validation are handled a little better in a DB.
To solve the problem of advanced users wanting to have more granular control, I would suggest an import/export layer that can output files in json/xml, allow users to modify them, then import them back into the DB.
One of the benefits of this approach is that it allows for a syntactic and schema validation of the file before it overwrites the original configs. I can’t count the number of times I left off a closing tag or ‘}’ and corrupted a previously working system because no validation was in place.
The OH2 console might be a good place for the import/export commands (you can already import/export automation types in json there). I’m really excited about the console being more feature complete (adding Things/Items, creating rules, etc). Ideally, you should be able to write a “console script” that configures the system directly once it’s finished. This would be similar to how admins configure Cisco or Juniper routers. The entire system is configured by console commands, so no need for “intermediate users” to know DSLs. More advanced users can still write the DSLs, and then simply import them into the system.
I am (was!) also a fan of using mapdb - until yesterday when the limitations hit home and I lost my complete installation! As has been seen over the past week, when mapdb goes ‘bad’, all is lost (unless someone can come up with something to solve this!). There is currently some sort of issue that has meant that for many people, it has been necessary to delete the database - really - this isn’t nice.
I’ve been looking over the mapdb implementation today, and currently it internally stores data in json format. So, I don’t think that directly storing in json will have a significant impact on performance or scalability.
Yes, a database can in theory ensure integrity a little better than a text file, but current experience says that there are other issues at play. The current problem is probably not an issue with the database integrity, but a problem with the data in the database that the system can’t read out (I think).
Maybe an export to json is a good option as well - there are many options of course… However, by storing directly in a human readable format there’s always the option to edit things relatively easily if things go bad.
In any case, the system is able to be modified, so it’s relatively simple to swap out the mapdb bundle for a different bundle to allow different implementations.
What could be interesting is console commands to show data like for example
smarthome:showDSL things
smarthome:showXML items
smarthome:showJSON item itemUID
I don’t think so. Certainly in OH1 in order to create the DSL files in HABmin, they had to be generated by concatenating strings together which is not nice, not scalable, and very error prone. Maybe I just didn’t find the good method, but I think if you want to generate a file automatically from Java classes, then I think you need Json/XML.
No - I agree. As I said, I did do this in OH1, but it does tend to be error prone to get all the different options sorted, and when something changes or is added, you need to sort it manually. It’s not impossible by any means, but it’s not very nice that’s all.
Another option to consider would be to use an alternative database to mapDB to hold configuration data, i.e. one that you could administer, manually delete/edit/insert records etc…, backup and restore.
There must be reasons mapdb is used vs sqlite or similar(without starting a religeous war, that would work), but I am not aware why. That being said, if mapdb is json under the covers, then are there toolsets for working with the DB directly?
I may be wrong, but mapdb was introduced to openHAB1 to have the ability to save all last states without having growing databases, and I think, for presets this is also sufficient.
That’s funny ! For information, I just discovered that few console commands are already existing, like:
smarthome:things
smarthome:items
Ok, it is implemented by class ThingConsoleCommandExtension for things. Output is provided by method printThings. We could imagine to add an optional format parameter in order to output config DSL or JSON.
This reply from @Kai to another post tonight got me thinking that we can already hard code what is contained in the mapDB database if we wanted, i.e. using a *.things file. In fact when I went and looked at my system I remembered that I already have 4 things set up this way.
Just need to work out how and where to code the channel links.
