I was not sure about the things 
stored in the mapdb. So for me this is the moment to move from .somethng files to the jsonDB and to fully use the paperui for configuration
Thanks
Thomas
Upgrading to latest snapshot and changing from mapdb to jsondb worked without any problems.
For Zwave: note that the id of the stick changes while adding it as a new thing (at least for my zwave.me stick).
So if you have any textual items configuration one need to change that to match the new id.
Great improvement, thanks 
Any new thing that is created through PaperUI or HABmin will by default be generated with a new UID, but you can of course name your thing whatever you like (at least in HABmin it allows you to specify the UID when you create the controller).
Never came up with the idea to try that 
But adapting the items files was not a problem … 
Even in PaperUI, you can override the newly created UID.
Hi all,
upgrading to build 624, I have issue described here:
I don’t know if could be related to mandb or not, but I cannot upgrade.
Any help would be appreciated.
Marco
I think this change also causes integer configuration parameters to be persisted as floats. E.g. with the LIFX binding I see the following:
18:52:28.940 [WARN ] [inding.lifx.handler.LifxLightHandler] - Invalid value '300.0' for transition time, using default instead.
The definition of this parameter is:
<parameter name="fadetime" type="integer" required="false">
<label>Fade time</label>
<description>The time to fade to the new color value (in ms).</description>
<default>300</default>
</parameter>
The code is expecting a long and not a float:
try {
return Long.parseLong(fadeCfg.toString());
} catch (NumberFormatException e) {
logger.warn("Invalid value '{}' for transition time, using default instead.", fadeCfg.toString());
return FADE_TIME_DEFAULT;
}
I’ve tested this with a completely new installation of build #624.
While I know this change is excellent and I fully support it, the migration for some of us is going to be a bit more painful than others. I have a rather large install and tried to do as much as possible in mapdb when using 2.0 bindings.
I am using the REST API to extract as much data as I can before burning my mapdb to the ground and populating the jsondb. The caveat is this only works if you are still running pre build 624.
These commands may be handy for others as well. Substitute your hostname and port as appropriate.
export Host=your.host.here
export Port=your.port.here
curl -X GET --header "Accept: application/json" "$Host:$Port/rest/items?recursive=true" -k > OHitems.json
curl -X GET --header "Accept: application/json" "$Host:$Port/rest/links" -k > OHlinks.json
curl -X GET --header "Accept: application/json" "$Host:$Port/rest/services" -k > OHservices.json
curl -X GET --header "Accept: application/json" "$Host:$Port/rest/things" -k > OHthings.json
Perhaps I will try posting a thing or two back through the API as a form of migration and see how it goes, but for now, I at least have the names saved off that match my rule set.
edit: If anyone is curious, it looks like I have 797 items currently 
1 Like
AFAIK mapdb has stored only the last value of each item and therefore was mainly used for “RestoreOnStartup”. Correct?
If so, has jsondb the same limitation? Or can I also use it to produce historical data (charting)?
No - no values are stored here. This storage is only used to store your configuration - it’s not a persistence service, and I think you are thinking about the mapdb persistence service.
1 Like
Oops…yes, I did. Ok, forget my question then. 
I cannot reproduce this. If I look at my json-serialized LIFX Thing, I see:
"configuration": {
"properties": {
"deviceId": "1",
"fadetime": 300
}
and this is correctly passed to the handler.
Note: I created the Thing manually, since I don’t have a bulb at hand right now. You probably used discovery, maybe that makes a difference. Can you check your jsondb/org.eclipse.smarthome.core.thing.Thing.json file?
@Kai My issue is fixed when I use build #627!
With build #624 integers of other bindings were also persisted as floats in the .json file. I used the discovery and inbox to add things. E.g. with the NTP binding I have:
Build #624:
"configuration": {
"properties": {
"timeZone": "Europe/Amsterdam",
"hostname": "0.pool.ntp.org",
"refreshInterval": 60.0,
"refreshNtp": 30.0
}
},
Build #627:
"configuration": {
"properties": {
"timeZone": "Europe/Amsterdam",
"hostname": "0.pool.ntp.org",
"refreshInterval": 60,
"refreshNtp": 30
}
},
I have absolutely no clue why it should behave differently between those two builds, but as it is working, I won’t ask any further…
My things and items are defined in config files. Is it mormal to not find them in the new json files ?
The only file that contains data is the one attached to discovery.
Yes - the storage database (be it mapdb or jsondb) stores the data that is managed through the UI. If you define your configuration in the DSL config files, then they can not be managed through the UI.
Hi! Hope i’m not intruding to much in the important announcement section, but are trying to get my system running with the new implementation of json storage.
As far as I have understood so far, it should allow easy backup and edit (as it is plaintext) that are replicated into paperui, right? Does it mean that the old *.items files should be depricated?
As of yet, I have not known of any other way to use OH2 than by configuring items and sitemaps in the classic files, and things thru paper ui. Right now I feel even more unsure where is the right place to create and maintain my things/items/sitemaps, to avoid any further rework. yes, I know, using snapshot and so on, that must be expected. But it seems like this will be the issue for all upgrading any version of OH2, even the betas, right?
Currently, any changes to the items-file in conf folder, will force-update the json-file. Deletions in json-file, does not seem to delete from paperui. So right now, I feel like what I should do, is to add a things-file to my conf folder, and go on the classic way. That way I have full control again my system, while being able to test and review updates rather painlessly. Or would you advise differently (hard to predict future, but best guess works for me)?
Any inputs much appreciated!
I’m no authority in answering your question so someone might correct me in a few places, but to put it simply, there are two ways of adding an object that openHAB can use. They currently have no interaction with each other. For the normal user of openHAB, you shouldn’t notice a difference in mapDB and jsonDB, only that you’re able to see what’s going on “under the hood” now.
-
Through the paperUI - Everything handled inside the paperUI or through internal services is saved in a database (which is now jsonDB for openHAB), any changes noticed by openHAB will be reflected in this database some how. The change to jsonDB was primarily so that people could edit or debug anything that was automatically set for them, but the usual way to edit anything set this way is to use paperUI or the console.
-
Using text files in the conf folder - Anything in the conf folder overrides what openHAB has set internally. This means that you can quite easily define an .items, .sitemap file etc. and openHAB will be aware of these items. Because they’re in the conf folder and are editable by you only, you can’t make changes to these through the paperUI. AFAIK, sitemaps are only configurable through this way anyway. For people who are comfortable with text, this is often a much faster way of getting exactly what you want.
Which method you use is entirely up to you, openHAB here is about choice. I use a mixture of both but at the moment am leaning more towards setting things up through paperUI,. I know that a few developers, Kai included have said that they prefer textual configuration.
2 Likes
It’s up to you - personally I use the UI for configuration, and not the items files. The JsonDB storage works the same as the MapDB storage - it just allows you to view/edit/correct them if you need/want to.
No - this is correct. The jsondb files are not read back from disk, other than on startup. So, if you edit them manually, you should restart OH2.
The JsonDB storage is meant to be used mostly for configuration through the UI - on a day-to-day basis at least. If you want to do some mass update, or cut and paste of items etc, and you edit the files directly, then you will need to restart.
@chris Thanks for stating that. In between all the discussions I was silently waiting for that information. This should be emphasized for whoever might indeed want or need to hack around in there.