When I edit my .items file, the values of some items are missing afterwards. I use mapdb for restoreOnStartup which is generally working.
There is absolutely no pattern which items work an which not but they are always the same regardless what I have changed. As an example the first one works, the second not.
Number TemperatureDefaultBesprechung "Besprechung [%.1f]" <temperature> (All, gRestoreOnStartup)
Number TemperatureDefaultBuero "Büro [%.1f]" <temperature> (All, gRestoreOnStartup)
The not working items are totally random and not restricted to a specific type.
I switched to mapdb for restoreOnStartup some days ago but I relatively sure the problem was already there before that.
I already deleted the mapdb files, tmp, cache in /var/lib/openhab2/, renamed the items file etc.
Mapdb Debug shows no errors when saving the items in question.
Some observations I made:
The items which values are missing change when rearranging the items or commenting out random parts of the file.
Restarting openhab magically returns the missing values. (Discovered just now which helps a lot as it is stupid but at least a workaround)
I have no ideas what to do next as I tried everything what might have to do with the problem with no success. Any suggestions what might be the problem?
If changing any .items files, the whole bunch of items are reloaded, because it may be that you added or deleted a group item or doubled a name, so it’s possible that your changes made side effects.
Unfortunately this doesn’t cause a complete restore of data, so the only save way is to restart openHAB after changing items. This is normal behavior, though not very nice…
I disagree, this is not normal behavior. This is a bug and should be fixed. Either ALL the Items should be restored or none of them. Restoring random ones is just plain wrong.
I’ve never encountered this particular problem on the forum and have never encountered it myself. What version of OH are the two of you running? I’m trying to discover if this is new behavior or just something that I’ve been lucky to avoid until now.
I did see this behavior ever since (beginning from OH1.0, currently 1.8.0 for productive and 2.2.0 for test system), most of my items are bound to knx and have a well configured state GA, so openHAB would have to reread all of them like when starting up.
Other Items are bound e.g. to astro binding, and even these aren’t filled when .items files are updated.
In fact, I’m pretty sure that @Kai did a posting about this “ages ago”
Not to mention… there are other issues around unsuccessful dynamic configuration, so the common suggestion if something doesn’t work as it should is, to restart openHAB…
What you are talking about is populating the Items with the values from the bindings. And that is understandable that the behaviors would be different for different bindings.
But OP is talking about restoreOnStartup from persistence not working consistently. This is completely independent of the specific bindings and it should, IMHO, either work all the time or not at all. Restoring the state of some Items but not others from the database on a .items file reload is really incorrect behavior.
I would rather see restoreOnStartup not working at all when reloading a .items file than have random Items repopulated with restoreOnStartup while others remain Undefined.
For testing I switched back to rrd to be sure the problem is there and it is. So it isn’t a problem specific to mapdb.
I’m using the current version (“openHAB 2.1.0 - release build -”) but I’m also relatively sure the problem was also there in older versions but it hadn’t such an impact that it bothered me.
Even simple changes like adding an empty new line results in missing values. As stated before the broken items are totally random but every time exactly the same until I add or remove items.
The fact adding a new line to the end of the file causes the Items to reload is not surprising. You can run touch on the file to just change its timestamp and OH will reload the file and reinitialize all the Items. That is how OH works.
To rule out this as something that has already been fixed you probably should test it out on the current latest snapshot 2.2.
The fact that the same Items remain uninitialized until you add or remove Items indicates to me that it initializes the Items in the same order every time (the order may be random depending on the internal data structure they are stored in) and adding or removing Items changes that order.
So a big question is the same number of Items left Uninitialized or the same number of Items initialized every time you add or remove and Item? That could indicate that it is stopping at the same point every time which could be useful information.
It might be informative to put org.eclipse.smarthome.core.persistence into TRACE logging (I think it is configured to not log anything at all by default) and see if there is anything going on in the persistence code that can point to the problem. The fact that it happens with more than one DB points to a problem in OH core code.
I was surprised as I use touch as a workaround for another bug but touching isn’t enough in this case. The log says refreshing the file but the values are still ok. Only a “real” change to the file produces the missing values.
Is there an easy way to print out all item values on the console so I can count the missing values?
One observation described a bit more specific: same items in the file (order apparently not relevant) produces exactly the same missing items every time. So one specific set of items produces always the same missing values.
The REST API is awesome for doing this sort of thing. Of course, anything you can do from the REST API you can also do from the console, but I don’t know the commands.
The best way to learn about and exercise the REST API is to install the REST API Docs from the Misc tab in PaperUI. The Docs are interactive and lets you make REST calls straight from the docs themselves.
Anyway, https://<url>:<port>/rest/items?recursive=false where <url> is the hostname, IP address, etc. of your OH server and <port> is the port number will return a JSON formatted list of all your Items and one of the pieces of information returned for each Item is its current state.
Which makes the REST API call to get the list, formats it nicely so each field is on a separate line, gets those lines that are “state” : “NULL” and then count the number of matches with wc.
To get a count of all the Items replace the grep with grep "\"name\" : "
