Im not sure I was clear in my last msg so… im grateful to Chris for all his work so far, of course I am, but whilst we are in this development phase of OH2 it’s prudent to be able to go back to a well-known state, mapdb just doesn’t do that, chris himself has had issues with this in the past and he proposed a different storage mechanism – whatever happened to that ? Text files are the most basic mechanism to define that well known state as it stands, and I believe this is defined in the base ESH standard design, although it doesn’t specifically state it, im assuming this isn’t an optional mechanism. So until I can revert to a well-known state as OH2 progresses and things change I’m am happy to continue to run production on OH1 rather than migrate prod to OH2 and still have other OH2 test systems. I have even been down the route of trying to replay the XML via the REST api, which actually works reasonably well but after 30 or so devices just becomes too cumbersome to maintain. so unless you have a better option than MapDB, text files are the only viable option, it works well for all the option things I need to define.
It’s awaiting review…
Yes - I proposed the above - it’s perfectly usable if you want to use it.
I’ll just point out that this statement still focuses primarily on the proposed solution rather than the problem. My original question was to mainly just figure out if someone managed to make some binary database format reliable and support roll back to a previous state, even rolling back just one part of the DB back to a prior state, would you still find that solution unacceptable?
I agree, right now MapDB does not do this. MapDB may never ever be able to do this. But to make the leap from “MapDB can’t do it so text files are the only solution” is, IMHO excluding a whole host of potential solutions prematurely. And I guess that is my main point.
I’m more than willing to accept that text files may indeed be the best solution.
I would agree…
While I might agree, I think the perceived advantage (rightly so!) of text files is that if they get screwed up, you can edit them and fix the corrupted values. On the other hand, the downside of text files is they are probably less tolerant to errors.
As probably mentioned elsewhere and eluded to above by @mike_mccaffery I implemented the Json storage after loosing my complete system configuration, so I’m completely sympathetic to the concern and I think it addresses some/many/most of the thoughts here…
- It automatically keeps backups of each file.
- If lots of writes are made to the database over a short time, the system will only write to disk periodically to improve performance, and reduce the number of writes that may impact flash drives used on the likes of RPi.
- It puts each type of information (items, things, links) into a separate file, and stores 5 previous versions in a backup subfolder in case it’s required.
- If it can’t open a file, it will automatically try and open the newest backup file
- It’s actually significantly faster than MapDB
I completely agree. I actually do believe that text files is probably the right answer and I look forward to trying out your JSON data store. If it works out I’d like to see it become the standard. My biggest concern though is fragmentation, but I’m sure everyone is concerned about that.
I think JSON strikes the right balance between human readable and easily machine parsable.
Have you given any thought to adding this as not only a data store for OH config but as a persistence option? I’m not sure there would be much demand for it but I must admit I’m thinking it might be a nice way to bootstrap an Item’s initial state (e.g. manually set the value in the text file and touch the .items file to restoreOnStartup to this value) or overriding values that have been saved in the past that might be wrong or causing problems (e.g. I have an Item that got populated once but the device is currently dead and I’ve been too lazy to create a System started rule to reset the value until I can get around to rebuilding the device).
It’s not like you have anything else to do. 
No - it’s not something I’d considered. In a previous life (ie before OH) I wrote a persistence system for the Vera called DataMine - that did you text files and the performance wasn’t as bad as I initially expected. However, as a general persistence store, I think a database is probably more suitable…
For a simple ‘restore on startup’ persistence service though, it could be ok. However, I would probably argue that the configuration database is a special case - the consequences of a failure a pretty major - even if it only happens once a year. On the other hand, a once a year failure of the startup persistence might not even be noticed…
I was mainly thinking of using it in place of MapDB for restoreOnStartup, not something that would be used for historic data. And it really only just scratches a couple of edge cases I have which I’ve already found work arounds for.
I completely agree, the configuration DB is a special case.
It seems we are all sort of in agreement, no-one trusts MapDB at this moment in time it appears… and I suspect we are all just picking up on txt files because 1. That’s what everyone is used to coming from OH1 and 2. Its currently the only other defined option until the design/standards change. I will readily switch to an alternative if one becomes available 
P.S. Chris, DataMine was fabulous too I still have a couple of vera’s in a drawer that probably have it installed…
And to open another can of worms… nah will leave that for another day
Hi @chris,
Any news on this development?
(I mean the development of a working .things file configuration)
It will go into the dev branch when I finish the current developments - probably a good few weeks away I would guess.
Excellent. Thanks.
Any update on this? I have a few dozen times
ct100 thermostats that I am trying to configure as text .things. Text would be much faster then clicking through the UI and changing all names and scales.
It’s in the development branch, but I won’t be merging this into master for a little while. I hope to be able to make a development version available so a few more people can test it out (a few people are already using it).
Any news on this? With more than 30 Z-Wave devices the configuration though the UI is very cumbersome, that’s why i’m still on OH1. But since the last devices i’ve got (FGS-223) aren’t supported by (the abandoned) OH1 i’m forced to migrate to OH2.
Sure, works, migrate to the developmet branch:
Examples:
I’ve migrated to the current snapshot, both the zwave binding and openhab2. Still unusable, still on OH1. I’ve started with a complete new installation and setup all Things and items via PaperUI (don’t know how much mouse clicks are necessary), nevertheless basic configuration of things and items (e.g. things switch type connector or the label of items) was not possible and results in internal server errors. Which debug/error infos could i provide for supporting the development?
Manual things files don’t work in the snapshot, that’s the reason I wrote:
You need to upgrade to that branch!
Sorry for my missunderstanding post. I’m not using the latest snapshot from cloudbees, 'm using the current version from the “OH2 Z-Wave refactoring and testing… and SECURITY”. Is there another development branch?
@oppo1967p, I think you need to have the latest JAR from this thread to be able to use .things file: