My jdbc.persist file looks like:
// persistence strategies have a name and a definition and are referred to in the “Items” section
Strategies {
// for rrd charts, we need a cron strategy
everyMinute : “0 * * * * ?”
every5Minutes : “0 */5 * * * ?”
everyHour : “0 0 * * * ?”
everyDay : “0 0 0 * * ?”
}
Items {
// which data to be stored
// * : strategy = everyChange, restoreOnStartup // after switching this OFF, no more Group states have been stored (G_Lights* only stores the members)
G_Lights : strategy = every5Minutes, everyChange, restoreOnStartup
G_All_OFF : strategy = every5Minutes, everyChange, restoreOnStartup
G_Mobiles : strategy = every5Minutes, everyChange, restoreOnStartup
G_Windows : strategy = every5Minutes, everyChange, restoreOnStartup
G_Melder : strategy = every5Minutes, everyChange, restoreOnStartup
G_Bypass : strategy = every5Minutes, everyChange, restoreOnStartup
G_Battery : strategy = every5Minutes, everyChange, restoreOnStartup
G_OverR : strategy = every5Minutes, everyChange, restoreOnStartup
G_Net : strategy = every5Minutes, everyChange, restoreOnStartup
G_jdbc* : strategy = everyChange, restoreOnStartup // Switches and Strings
G_Numbers* : strategy = every5Minutes, everyChange, restoreOnStartup // Numbers only
After a restart of OH (at least) one item (Presence_Num in Group G_Numbers) is stored on changes in the MySQL DB only.
This can easily be recognized in the habpanel chart:
As soon as I copy the SAME persist file to the config/persistence folder it obviously reads the persist file and the item is stored every five minutes in the DB.
Is this some timing issue during startup?
Any other idea?
I will redo the whole procedure to make sure. But actually it happend recently whenever I restarted OH 2.1.
I will keep you updated.
If I need to fill an issue, I might need help as this is new to me…
Thanks
Actually I have an update on this issue:
After starting from scratch (switch over to brand new openhabian 1.3 iSD-card image) I haven’t seen this issue since.
(in a short test using my old SD-card with the previous installation it was still reproducible though).
Anyway, I guess an issues does not make sense in this case, but I will keep a close look.
Hmmm. When problems go away with a new SD card it makes me think the old one was going bad. These sorts of problems can indicate a failing SD card. With as much that OH writes to logs and persistence an SD card often won’t last super long.
Actually I thought about this, too. So I swapped the SD-cards and the images upon them as well.
So the new installation works well on both physical cards. And both cards show the issue above with the “old” or “faulty” image.