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
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).
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
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.
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?
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?
