Perhaps you can explain what that is, what channels it links to, and why you would expect it to be restored.
I would expect to be restored because of two simple reason:
- The official document doesn’t states that anything else is needed
- And in my previous logs it can be seen that in case of some items it works
My binding is:
Things:
Thing mqtt:topic:generic "Generic MQTT Thing" (mqtt:systemBroker:embedded-mqtt-broker) @ "Home" {
Channels:
Type string : LEDStrip_Kitchen_Cabinet_1 "Kitchen Cabinet LED Strip 1" [stateTopic="home/Kitchen_Cabinet_1", commandTopic="home/Kitchen_Cabinet_1/set"]
Type switch : LEDStrip_Kitchen_Cabinet_1_Power "Kitchen Cabinet LED Strip 1 Power" [stateTopic="home/Kitchen_Cabinet_1", commandTopic="home/Kitchen_Cabinet_1/set", transformationPattern="JSONPATH:$.state", on="{state: 'ON'}", off="{state: 'OFF'}"]
Type string : LEDStrip_Kitchen_Cabinet_1_FX "Kitchen Cabinet LED Strip 1 Fx" [stateTopic="home/Kitchen_Cabinet_1", commandTopic="home/Kitchen_Cabinet_1/set", transformationPattern="JSONPATH:$.effect"]
}
Items:
String LEDStrip_Kitchen_Cabinet_1 "Kitchen LED Strip 1 [%s]" (gLightDesign, gLEDStrip_Kitchen) {channel="mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1"}
Switch LEDStrip_Kitchen_Cabinet_1_Power "Kitchen LED Strip 1 Power" (gLightDesign, gLEDStrip_Kitchen_Power) {channel="mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power"}
Number LEDStrip_Kitchen_Cabinet_1_FX "Kitchen LED Strip 1 Fx" (gLightDesign, gLEDStrip_Kitchen_FX) {channel="mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_FX"}
Color LEDStrip_Kitchen_Cabinet_1_Color "Kitchen LED Strip 1 Color" <rgb> (gLightDesign, gLEDStrip_Kitchen_Color)
Number LEDStrip_Kitchen_Cabinet_1_Speed "Kitchen LED Strip 1 Speed [%.0f]" (gLightDesign, gLEDStrip_Kitchen_Speed)
Number LEDStrip_Kitchen_Cabinet_1_Intensity "Kitchen LED Strip 1 Intensity [%d]" (gLightDesign, gLEDStrip_Kitchen_Intensity)
According to the logs for me the Speed, FX, Intensity seems to be restored. Am I worng?
Thanks in advance!
Okay, Item LEDStrip_Kitchen_Cabinet_1_Power is a member of Group gLightDesign.
gLightDesign* (all members of) is persisted by everyChange, and should invoke restoreOnStartup
I’m not too sure now, but I don’t think you’d normally see any evidence in the logs of Items getting their states changed by restoreOnStartup. It’s not a normal update.
What is the state of your Item?
I think the updates you see in your log are due to the preceeding channel links being removed, and new ones added. The new links would probably update the Items states.
Like this -
LEDStrip_Kitchen_Cabinet_1_Power changed from NULL to OFF
I don’t know why your channel links get removed and added.
The presence of => in the log messages suggests there’s an invalid MQTT-1 configuration coming from somewhere. Have you got similar Items defined in xxx.items files and by PaperUI?
I have never installed MQTT-1. There shouldn’t be any junk left behind from that.I believe the ’ =>’ is just some copy-paste issue from the logs to the forum.
Currently I’m trying to test and simulate a power failure but I don’t really want to just pull out the plug from my raspberry if it is not necessery. Therefore I give the command sudo reboot. Durint the reboot I alway see that the link is removed during shutdown and is added back during boot up. That is the link removed and added. I thought it is normal.
The problem is Openhab seems polling my ESP state. So if I turn off my ESP’s power while my Openhab is up and running it will query its state and updates it to off. Therefore what I did:
- issued the command on raspberry: sudo reboot
- when I see the raspy is in a “powered off” state for a second before its starting back I turn off my ESP’s power and turn it back
- with this the item’s state (LEDStrip power) is turned on during the shutdown of Openhab (like in case of an unexpected power off situation)
I’m really trying to understend this! If the restoreOnStartup doesn’t automatically pulls the last state during startup what is its benefit? According to my logic if I simple persist my item’s states and forget this property I still can use rules to restore “manually” the items state. So what is the point in this case?
Also what is not clear is that according to the doc the restoreOnStartup has a small extension:
load and initialize the last persisted state of the Item on openHAB startup (if the Item state is undefined ( UNDEF )
But as I can see in the logs my items state is NULL during bootup not in UNDEF.
I really like Openhab but sometimes I feel its documentation is not for newbies.
Also I really appritiate your effort in helping me. Thanks a lot.
This subject is very interesting. I started using MySQL in the begin and later on switched to rrd4j. But it seems to me clear that there is some kin of an issue with this restoreOnStartup strategy.
Because also I notify that some items don’t get the status back on system start. At least not in the way as I would expect it.
Situation:
Switch (number item) which either can be “1” or “2”
Assumption:
- If I set everyChange, restoreOnStartup in the persist file - rrd4j db should be updated to the value of change.
- When I stop OH it should keep that status.
- When I start OH it initially is having NULL and should be restored to it’s last value as per rrd4j
But as far as I can tell that item is not set to it’s previous state.
While I can see that other items that have a channel assigned such as the comfoair temperatures and in addition use everyMinute in the persist, are getting restored. Basically before the binding itself gets the new values out of the device.
So for me at least at current time and best of my understanding, something is not working as it should.
But maybe my understanding is wrong.
It is quite possible that the restoreOnStartup feature is “flaky” with one or more of the persistence services.
Many people wanting restoreOnStartup do it with the mapDB service - it’s basically made for the job. You can run mapDB alongside other services without much overhead. I say this to explain why you might run into problems that other people don’t see.
rrd4j only works with numbers, it’s not clear what you mean here exactly but I would not expect rrd4j to successfully restore a Switch type Item.
Yes, that’s what I understand too. So, restore is useful in the case of say a fire alarm sensor that reports once a day. Not so useful where the binding is polling data every second.
The restore ought to complete before bindings start up and before rules run. There are well-known issues about order of services start up, though, so there could be exceptions in any particular set up/
Okay, so there was a hidden reboot in the log you showed us. That changes things.
That is what it is supposed to do. (But don’t confuse OH internal Item state with the status of any external device - that will never get commanded without some special action)
I’m not sure that all persistence services can store UNDEF, don’t know. If they cannot store it, they cannot restore it.
Yep, Items always start off as NULL.
When restoreOnStartup works, I believe it will silently update Item so that you don’t see the NULL in the logs, the action should happen before other services are aware. That’s the whole point of it.
Okay, so simulating recovery from a power outage.
There is a race between at least three separate things here -
openHAB
your ESP device
the MQTT broker that connects them
Things that could happen - in just about any order?!
openHAB creates fresh Items with state NULL
openHAB restores Items with pre-fail state
openHAB cannot (yet) find broker, updates Items to UNDEF
MQTT broker tells OH it cannot (yet) find ESP, sets state UNDEF
MQTT broker tells OH it has some ‘retain’ data for ESP, sets some old state.
ESP updates broker, broker is not (yet) ready, message lost.
ESP updates MQTT broker with actual state, OH updates Items.
I’m not at all sure which events you might be seeing in your log.
There is some tip here, using persistence debug to see what happens with persistence if you think the restore is not working
Hi,
Sorry for the delay! I made some tests and I think you got the point. It seems timing is one of the key points.
Unfotunately it’s late night here and I do not feel the power to write my findings and I will be busy in the next 2 days. I will riport back probably on Friday evening or latest on Saturday.
Thank you for your direction!
Also welcome to Stefan and thank to him for sharing his experience!
Well, I’m back… So it seems the thing’s MQTT state has precedence over the persisted state.
In my things I have this set up:
Thing mqtt:topic:generic "Generic MQTT Thing" (mqtt:systemBroker:embedded-mqtt-broker) @ "Home" {
Channels:
Type string : LEDStrip_Kitchen_Cabinet_1 "Kitchen Cabinet LED Strip 1" [stateTopic="home/Kitchen_Cabinet_1", commandTopic="home/Kitchen_Cabinet_1/set"]
Type switch : LEDStrip_Kitchen_Cabinet_1_Power "Kitchen Cabinet LED Strip 1 Power" [stateTopic="home/Kitchen_Cabinet_1", commandTopic="home/Kitchen_Cabinet_1/set", transformationPattern="JSONPATH:$.state", on="{state: 'ON'}", off="{state: 'OFF'}"]
Type string : LEDStrip_Kitchen_Cabinet_1_FX "Kitchen Cabinet LED Strip 1 Fx" [stateTopic="home/Kitchen_Cabinet_1", commandTopic="home/Kitchen_Cabinet_1/set", transformationPattern="JSONPATH:$.effect"]
...
And with this the log looks like this after a restart:
2019-04-06 23:13:51.263 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_Power => mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power' has been removed.
2019-04-06 23:13:51.282 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1 => mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1' has been removed.
2019-04-06 23:13:51.284 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_FX => mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_FX' has been removed.
2019-04-06 23:15:18.179 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_Power-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power' has been added.
2019-04-06 23:15:18.205 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1' has been added.
2019-04-06 23:15:18.207 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_FX-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_FX' has been added.
2019-04-06 23:15:30.095 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from NULL to {"state":"OFF","color":{"r":255,"g":255,"b":255},"brightness":64,"effect":"solid","transition":0}
2019-04-06 23:15:30.114 [GroupItemStateChangedEvent] - gLightDesign changed from NULL to OFF through LEDStrip_Kitchen_Cabinet_1
2019-04-06 23:15:30.644 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Power changed from NULL to OFF
2019-04-06 23:15:30.966 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Color changed from NULL to 296,97,46
2019-04-06 23:15:30.979 [GroupItemStateChangedEvent] - gLightDesign changed from OFF to ON through LEDStrip_Kitchen_Cabinet_1_Color
2019-04-06 23:15:31.064 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Speed changed from NULL to 100.0
2019-04-06 23:15:31.153 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_FX changed from NULL to 7.0
2019-04-06 23:15:31.216 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Intensity changed from NULL to 43.0
LEDStrip_Kitchen_Cabinet_1 -> Off -> has an MQTT binding
LEDStrip_Kitchen_Cabinet_1_Power -> Off -> has an MQTT binding
LEDStrip_Kitchen_Cabinet_1_FX -> Previous value -> has an MQTT binding <- currently this breaks my theory
But if I delete the stateTopic part in the things binding:
Thing mqtt:topic:generic "Generic MQTT Thing" (mqtt:systemBroker:embedded-mqtt-broker) @ "Home" {
Channels:
Type string : LEDStrip_Kitchen_Cabinet_1 "Kitchen Cabinet LED Strip 1" [commandTopic="home/Kitchen_Cabinet_1/set"]
Type switch : LEDStrip_Kitchen_Cabinet_1_Power "Kitchen Cabinet LED Strip 1 Power" [commandTopic="home/Kitchen_Cabinet_1/set", transformationPattern="JSONPATH:$.state", on="{state: 'ON'}", off="{state: 'OFF'}"]
Type string : LEDStrip_Kitchen_Cabinet_1_FX "Kitchen Cabinet LED Strip 1 Fx" [commandTopic="home/Kitchen_Cabinet_1/set", transformationPattern="JSONPATH:$.effect"]
...
In the logs I can see the values are loaded from persistence DB:
019-04-06 23:30:20.310 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_Power => mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power' has been removed.
2019-04-06 23:30:20.327 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1 => mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1' has been removed.
2019-04-06 23:30:20.328 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_FX => mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_FX' has been removed.
2019-04-06 23:31:49.211 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_Power-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power' has been added.
2019-04-06 23:31:49.233 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1' has been added.
2019-04-06 23:31:49.235 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_FX-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_FX' has been added.
2019-04-06 23:32:02.200 [GroupItemStateChangedEvent] - gLightDesign changed from NULL to OFF through LEDStrip_Kitchen_Cabinet_1
2019-04-06 23:32:02.204 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from NULL to {"state":"ON","color":{"r":168,"g":41,"b":146},"brightness":109,"effect":"solid","transition":0}
2019-04-06 23:32:02.255 [GroupItemStateChangedEvent] - gLightDesign changed from OFF to ON through LEDStrip_Kitchen_Cabinet_1_Color
2019-04-06 23:32:02.273 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Color changed from NULL to 296,97,46
2019-04-06 23:32:02.323 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Speed changed from NULL to 100.0
2019-04-06 23:32:02.401 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_FX changed from NULL to 7.0
2019-04-06 23:32:02.418 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Intensity changed from NULL to 43.0
2019-04-06 23:32:02.508 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Power changed from NULL to ON
So for me the conclusion is - however not everything is clear currently for me- that it looks like a thing binding takes precedence over restoreOnStartap. I believe sometimes this is good sometimes is not. It depends on your situation.
However it would be great if this precedence could be configurable maybe. But I understand I cannot see every reason why this is the precedence and I can believe this possibility could cause more much trouble.
@rossko57
Thank you very much your effort and your explanations!
I’ve marked you last reply as answer as your ‘ordering suggestion’ lead to this idea.
I think what you are saying is that for you, the MQTT binding starts working (and updating Items) before the restoreOnStartup happens?
That’s not a good thing, I agree. There is ongoing work about the “order of things” for openHAB startup. It does not always work well, not least because people get different results depending on their host and configuration.
If you want to improve your own setup - I would recommend dumping restoreOnStartup from mySQL and using instead mapDB, just for that purpose. Most people use that without confusion. You can of course keep mySQL for anything else you are doing with that.
The other thing to consider …if MQTT is promptly updating your Item with the real status … what do you want restoreOnStartup for, it doesn’t seem needed for these Items? You can be selective about it.
I think what you are saying is that for you, the MQTT binding starts working (and updating Items) before the restoreOnStartup happens?
Exactly. And it looks after the MQTT binding updated the item’s state, it takes precedence and its previous value is not restored from the DB.
I would recommend dumping restoreOnStartup from mySQL and using instead mapDB, just for that purpose.
I will definietly do it. I’m just short on time.
if MQTT is promptly updating your Item with the real status … what do you want restoreOnStartup for
This is for an unplanned power outage. Imagine the situation:
I’m working at home late night and there is a power outage. My ESP controlled LED lights will power off too. And the LEDs won’t turn on when the power is back. Openhab starts, reads the LEDs status and it sees it’s off. However the previous state was on. Therefore I have to either manually turn on all lights after a power outage or I would do it automatically if they were on before the power problem using restoreOnStartup…
Okay. Remember, we said earlier in the thread that restoreOnStartup is never going to send a command to a binding to affect any external device.
So it’s useless for that purpose anyway. It’s not going to help you at all. It is the wrong tool for the job.
You have to take some positive action if you want to set a device to some particular state on bootup.
Write a rule that runs at system started, reaches back in the persistence database for the Item state prior to boot, and uses that to command the device.
Discussion about that here
I never thought that restoreOnStartup sends anything to a binding. I thought the restoreOnStartup updates an item’s state. That initiates a state change event which will be sent to the binding like in case you press the button on the UI manually. I throught it shouldn’t matter if a “code” changes the item’s state or I change its state throught UI.
In a .Net application if you have a property which is binded to something it doesn’t matter which direction the change is coming from. There is a change which has effect on the binded something.
Anyway, I don’t want to put more effort in the wrong way. I can accept that this is not the right way I need so I will go on the direction you recommended. I just… You know… a binding looks much clearer and followable for me than create rules and rules and rules… Never mind!
Thank you very much your help!
There’s a big distinction in openHAB between commands and states. Not least because they need not be related - you can command a Dimmer to “increase”, but the resulting state is 60% say. At some point the penny will drop about this 
It’s pretty essential in a real world system if you don’t want endless loops.
The UIs generate commands. Commands get passed to bindings.
This isn’t c# or Net
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.
Hi,
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: 
- 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.
- 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.
- 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 