[SOLVED] Restore On Startup not working with mysql persistence?

This is exactly by design. As rossko57 said, restoreOnStartup should occur before the bindings start receiving new states. When the binding starts it will then override the Item with the most recently received state. The driving principle is that the Items in OH should whenever possible exactly match the states of the devices. You wouldn’t want a “fresh” state overwritten by a stale state from the database.

I’ll try to provide an additional explanation. rossko57 covers one use case (i.e. when the command doesn’t match the actual state that an Item carries). In that case, the command would be increase but the state update would be 60%. This is one reason why commands and states are different.

Here is another one. Imagine the following situation. Let’s say you have an MQTT device that reports back whenever it changes state and the binding supports this. In that case what you would want is for OH to not update the Item’s state until after the device reports back that it has become the new state. So you would configure your Item with autoupdate=false. Now, when you send the command, the command will go through the binding out to the device, but the Item won’t actually change state. OH will wait for the device to report back that it has changed as a result of the command and then the binding will update the Item with the new state. I can’t use command because that will cause an infinite loop.

OK, now imagine the case where you have a technology that does not report back the state of the device when it changes. In that case you need to have autoupdate=true and in this case when you send the command, OH will also apply the new state as an update to the Item. In this case, since the device doesn’t report back the new state, we have to assume that our command was successful.

OH has to support both use cases. Therefore updates very deliberately do not get sent out to the binding and the device. Updates are only used to update the state of an Item internally to OH.

restoreOnStartup only performs updates. This again is a very deliberate design choice. For one, theoretically, Rules shouldn’t even be running and potentially the bindings may not even be running yet when the Items gets restored to their previous state. In the best case the commands would be ignored. In the worse case sending a command at this time would result in errors as things start triggering and executing before they are ready.

A binding’s job is to interface between OH and a given API or technology. This interface is exposed to OH as Things and Channels.

Items are used to model your home automation. One way to think about it is that Items are where meaning and context is given to Channels. It also normalizes the way that OH interacts with devices.

Rules are how you coordinate the behaviors of Items based on events. You can’t put Rules in a binding because those Rules could only ever work with that one API or technology. That destroys the whole point of OH.

You can think about it like the layers in the networking stack. Bindings are like the Network Access layer. Things and Channels are the Internet layer. Items are like the Transport layer. And Rules, sitemaps, and persistence are like the Application layer. The simile isn’t perfect but I do think it’s useful. Each layer builds on the previous layer. Each layer has a distinct job to do. And you don’t want to mix the responsibilities of one layer into another layer, particularly another layer down on the stack.


Very sorry for the delay and thatks for your valuable explanation!

However there is one thing we doesn’t agree:

That is the difference in our point of view. In case of a power failure the stored database state should be the expected not the one on the physical item. Because the light bulb will be also turned off however after the power is back I would like them to be in the state they were before the power outage. In this case from my point of view the physical device’s state is the stale one not the state stored in the database.

But still my question is opened in this case: what is the point of restoreOnStartup?
All the discussions under this thread is pointing to the direction of using rules (previousState I believe). In this case when and how the restoreOnStartup has reasonable usage? What was it developed for?

And that’s where you deviate from the purpose and intent of RestoreOnStartup: :sunglasses:

  1. OH will always do its best to reflect the actual state of a thing, so the UI, Items and rules acting upon them know that the state reflects the actual state of the device.
  2. RestoreOnStartup is not designed for enforcing a specific state, but as a ‘stop-gap’ for devices that don’t report their actual state when OH comes back up and would otherwise stay ‘UNDEF’ for a long time.
  3. There are other reasons why OH restarts beyond total power outage of your house, like device reboot, crash, update of OH, etc.

What you want to accomplish needs a rule that runs at SystemStart and a dummy item that keeps the last desired state.

What Ron said. With only one minor quibble. When OH starts up it sets the Items to NULL, not UNDEF. NULL is used to indicate an Item that has not been initialized. UNDEF is used by a binding (or Rule) to indicate that we don’t know the state of the Item for some reason.

For example, MQTT 2 will set the state of Items to UNDEF if the broker Thing goes offline. I do something similar in my own Rules to set some sensor readings to UNDEF when the device reporting that status goes offline according to the Network binding.

I think if you don’t provide a state= or command= to the Expire binding, it will update the Item to UNDEF.

Ok! Now I got it! I think this sentece changed my mind and made this purposes totally clear!

Thank to all of you for your valuable explanation and help! Especially for rlkoshak for his patient and sustained explanations!

In conclusion I think this thread made me clear much more than just the working behavior of restoreOnStartup!

Hi everyone.

I recently implemented the persistence binding on my OH2 falsely assuming that restoreOnStartup would help me prevent unwanted behaviors after power failures, such us my Phillips HUE lights waking us up at 3 in the morning after the power was restored.
After searching for days how to delay the persistence service until all bindings had been loaded I stumbled upon this thread and finally understood that restoreOnStartup is not supposed to automatically restore the status of the actual Things.

Now I understand that the current way to solve this problem is a manual combination of rules + persistence to actually force the “restore” by sending a command, after manually retrieving the last persisted status.

I believe this topic should be further clarified in the configuration guide (https://www.openhab.org/docs/configuration/persistence.html) as I bet a lot of people such as myself, @Newbie2 or @smhaller have been confused by the false expectation that it will solve our problem of restoring the physical things to the previous persisted status.
Just as the “issue” with rules possibly being loaded before persistence was mentioned with workarounds at the end of the page, I suggest something similar is done for this topic.

Thanks for all your support and for this great platform.

At the bottom of the page is a link to edit it. Don’t be intimidated, it seems daunting first time - but contribute :smiley: