[Solved] MySQL Persistence does not restore on start up

I’m using the MySQL binding for persistence. Data is being saved and accessed fine. I am having no luck with restoreOnStartup. I’m using 1.8.3.

Here’s my mysql.persist file:

// Persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
	everyMinute	: "0 * * * * ?"

	// If no strategy is specified for an item entry below, the default list will be used.
	default = everyChange
}

/*
 * Each line in this section defines for which item(s) which strategy(ies) should be applied.
 * You can list single items, use "*" for all items or "groupitem*" for all members of a group
 * item (excl. the group item itself).
 */
Items {
	//mysqlper* : strategy = default, restoreOnStartup
	Presence* : strategy = default, restoreOnStartup
	Doors* : strategy = default, restoreOnStartup
	Battery* : strategy = default, restoreOnStartup
	//chartValues* : strategy = everyMinute
	Presist* : strategy = default, restoreOnStartup
	HVACRuntimeC : strategy = everyMinute
}

All items I’m wanting restored are saved to the ‘Persist’ group.

Also, I did some searching and saw something about creating a delay but I’m unsure if this is what’s causing the problem. The solution was a Linux based script that would touch files. I’m running windows so I’d have to cobble together a batch script to do something similar. I also read a thread that mentioned touching the mysql.persist file while OH is running. I tried doing this by adding a CR to the mysql.persist file and I saw that it reloaded but the values were not restored.

I’m also seeing that I lose values when I modify my sitemap. Is this supposed to happen? Is OH supposed to try and restore these values after the new sitemap is reloaded?

This ‘issue’ is the last thing that I need to fix before I can say that my system is fully functional. Any links/tips on fixing this would be most appreciated!

Weird behavior to be sure.

Based on a reading of the Persistence wiki page, I don’t think it is right to explicitly assign “default” like that.

// if no strategy is specified for an item entry below, the default list will be used

It is admittedly a little vague but one implication of this is that default is not a strategy you can explicitly use. It is what applies when you don’t supply a strategy.

Try replacing the "default"s in your Items section with everyChange to see if that makes a difference.

1 Like

In searching for the instructional website I had bookmarked that contained that code I stumbled on a different page I had bookmarked. That paged referenced a persistence line in openhab.cfg. I took a look and it was set to:

persistence:default=rrd4j

I’m not sure if that’s on by default, but I had not changed it to mysql since switching. I just modified it and restarted and now everything is loading.

This is great, but I did notice something odd. I have several hardwired contact switches I use for my alarm system. I track the last time that these were active by saving a time stamp. I noticed that while the switch states were loaded correctly, the time stamps were all the same and correspond with the time OH was restarted. It seems like when it restores the state it also sends an item update message which in turn causes my rule to run that updates the time stamp. I would think that this would not cause the update message to be sent. I’m unsure how I would go about preserving the correct time stamp on start up.

Updates get sent any time anything is sent to an Item. I don’t see your rule that is recording the timestamp but you might be able to change your trigger to be on when the contact receives a command rather than just being updated.

Here’s one:

rule "Update time/date for Door_Laundry"
when
  Item Door_Laundry received update
then
    postUpdate(Door_Laundry_Update, new DateTimeType())
end

So I could just change ‘update’ to ‘command’ and it should time stamp any time I get an ON/OFF orany command the device can receive? Excellent. I’ll give that a try!

Typo? Shouldn’t it be Persist*?

Yes, and it should be. I’m terrible at spelling apparently, but I’m consistent so it works. haha

The distinction between a command and an update is that a command comes from and great sent to the binding attached to an item. An update if generated internally inside of OH and dies not get sent to/from the binding.

By changing your rule trigger to received command you make it so the rule only triggers when the item is updated by the binding and not when OH makes a change (e.g. during a restore on startup).

I tried changing the rules like this:

rule "Update time/date for Door_Laundry"
when
  Item Door_Laundry received command
then
    postUpdate(Door_Laundry_Update, new DateTimeType())
end

Unfortunately this is not working for me. It is not adding the timestamp. Am I doing it wrong? The only change I made was changing the word ‘update’ to ‘command’.

Here is my code that I use to save the most recent door opening time to a DateTime Item. I’m using MapDB so it only saves the most recent.

                // Save the date/time for openings
            if(door.state == OPEN) {
                        gDoorSensorsTime.members.filter(dt|dt.name == door.name+"_Last_Opened").head.postUpdate(new DateTimeType().toString)
                }

The big difference is I don’t send the date as a DateTime but as a String instead. There are many reports of the postUpdate action not working well with data types that are not String so perhaps it is having problems posting the value. Do you see any errors in your logs? You can try one of the following:

Door_Laundry_Update.postUpdate(new DateTimeType())

postUpdate(Door_Laundry_Update, new DateTimeType().toString)

Door_Laundry_Update.postUpdate(new DateTimeType().toString)

Thanks for the info. I tried and it still does work. I am not getting any errors. Are you sure that I should be receiving a command when the door opens? The reason that I ask this because I only see :

Line 48392: 2016-07-05 06:32:57 - Door_Laundry state updated to OPEN
Line 48404: 2016-07-05 06:33:37 - Door_Laundry state updated to CLOSED

in my events.log file, but for some devices I see commands like this:

Line 3897: 2016-07-03 04:27:52 - X10_B4 received command ON
Line 3929: 2016-07-03 04:29:05 - X10_B4 received command ON
Line 3936: 2016-07-03 04:29:06 - X10_B4 received command ON
Line 5001: 2016-07-03 05:47:54 - X10_B4 received command OFF

If the door never gets a command then the way I have it written will not work.

There does seem to be some inconsistency in how some bindings treat updates verses commands. This looks like a case where it is only sending updates for changes to the contact which is unfortunate. Indeed the rule will never trigger.

1 Like