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

Tags: #<Tag:0x00007f617c270ff8> #<Tag:0x00007f617c270f08>

Hi All,

I’m trying to persist my items state. But no luck and I cannot find what do I wrong…
I have successfully configured mysql and I can confirm my items states are written to the appropriate table.

I have configured mysql persistance for testing purposes:
Items {
gMotion*, gLightNormal*, gAnyoneHome*, BalconyLiving_LightIntensity, gAnyoneHome, gEveryoneHome, gLightDesign* : strategy = everyChange, restoreOnStartup`
}

Everything starts with “g” is a group.

My ligth item looks like this:

Switch LivingRoom_Main_Light “Main Light” (gLivingRoom, gLightNormal, gArriveHomeLight) [“Lighting”] { gpio=“pin:27” }

I turned on the light confirmed the state change is written to the database then restarted my Pi.
In the logs I can see this:

2019-03-30 23:24:23.382 [ome.event.ItemCommandEvent] - Item ‘LivingRoom_Main_Light’ received command ON
2019-03-30 23:24:23.391 [vent.ItemStateChangedEvent] - LivingRoom_Main_Light changed from OFF to ON
2019-03-30 23:25:19.224 [vent.ItemStateChangedEvent] - LivingRoom_Main_Light changed from ON to UNDEF
2019-03-30 23:26:53.474 [vent.ItemStateChangedEvent] - LivingRoom_Main_Light changed from NULL to OFF
2019-03-30 23:26:53.483 [GroupItemStateChangedEvent] - gLightNormal changed from NULL to OFF through LivingRoom_Main_Light
2019-03-30 23:26:53.488 [GroupItemStateChangedEvent] - gArriveHomeLight changed from NULL to OFF through LivingRoom_Main_Light

Any idea what do I wrong or what I have missed from this topic?

Thank you in advance!

You’ve just stated that it’s working correctly while claiming it’s not working.
Care to clarify what problem you’re trying to solve?

Persistance is NOT working. Storing the value in the DB IS working. The value is stored in the DB but is not loaded during startup.
According to Persistence Doc:

  • restoreOnStartup : load and initialize the last persisted state of the Item on openHAB startup (if the Item state is undefined ( UNDEF )).

But as you can see in the logs at the end of the boot process its state is Off even if the stored value is On.
I assumed if the stored value is On then after a reboot the light should turn on automatically.

That’s not how it works.
Restore on startup is like postUpdate for an Item. It sets the state, but does not get passed to bindings and so will not affect actual devices.
In your case, you have a binding, which will update the Item state from the real device state after the restore anyway.

You could run a rule at system startup which reaches back into the db from before bootup for previoustate and uses that to issue a new command.

Thanks for the explanation! But what is the point of the “restoreOnStartup” property in the persistence file in this cased? What is used for?
Could you please help me with a sample rule or with a “how to link” regarding the rule you mantioned?

Also there is a chepter in the doc:

When restarting your openHAB installation you may find there are times when your logs indicate some Items have the state NULL . This is because, by default, Item states are not persisted when openHAB restarts - even if you have installed a persistence add-on. In order for items to be persisted across openHAB restarts, you must define a restoreOnStartup strategy for your items. Then whatever state they were in before the restart will be restored automatically. The following example persists two items on every change and restores them at startup:

Strategies {
  default = everyUpdate
}

Items {
  item1, item2 : strategy = everyChange, restoreOnStartup
}

It is usually not necessary to restore all Items since there is a good chance that they are no longer accurate (switches may have been toggled, sensor values are likely to have changed), and the restoration may result in unwanted rule actions.

This doesn’t mentiones anything about rules or bindings or whatever. Its just sais:
In order for items to be persisted across openHAB restarts, you must define a restoreOnStartup strategy for your items. Then whatever state they were in before the restart will be restored automatically

That is correct. An Item is something in openHAB, It may or may not represent some device, or part of a device, or situation in the real world.
restore-on-startup is only intended to restore the state of the Item.

If you want to to take some action on a real world device, it’s up to you to do that.

Example rule

Edit - this discussion is useful too

Thank you very much! It is starting to beginning clearer! However it is still not fully clear. Maybe this is because of my English language knowledge -> maybe sometimes I missunderstend some sentences. I appologies for this!

I get the rule from that post. Also I found according to the first example (thanks again, it is very useful!), there is a known issue with GPIO binding and restoreonstartup. At the moment I haven’t finished researching that topic… I will do it.

From the other side I tried restoreOnStartup with my ESP8266 controlled LED Strip. There seems to be some signs of life but…

> 2019-03-31 14:26:15.252 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_Power =&gt; mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power' has been removed.
> 2019-03-31 14:26:15.273 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1 =&gt; mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1' has been removed.
> 2019-03-31 14:26:15.275 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_FX =&gt; mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_FX' has been removed.
> 2019-03-31 14:27:42.333 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_Power-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power' has been added.
> 2019-03-31 14:27:42.372 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1' has been added.
> 2019-03-31 14:27:42.387 [.ItemChannelLinkAddedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_FX-mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_FX' has been added.
> 2019-03-31 14:27:49.939 [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-03-31 14:27:49.945 [GroupItemStateChangedEvent] - gLightDesign changed from NULL to OFF through LEDStrip_Kitchen_Cabinet_1
> 2019-03-31 14:27:50.175 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Power changed from NULL to OFF
> 2019-03-31 14:27:54.213 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Color changed from NULL to 296,97,51
> 2019-03-31 14:27:54.263 [GroupItemStateChangedEvent] - gLightDesign changed from OFF to ON through LEDStrip_Kitchen_Cabinet_1_Color
> 2019-03-31 14:27:54.314 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Speed changed from NULL to 64.0
> 2019-03-31 14:27:54.385 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_FX changed from NULL to 7.0
> 2019-03-31 14:27:54.423 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Intensity changed from NULL to 36.0
> 2019-03-31 14:27:56.160 [INFO ] [g.eclipse.smarthome.model.script.LED] - Source LEDStrip_Kitchen_Cabinet_1
> 2019-03-31 14:27:56.182 [INFO ] [g.eclipse.smarthome.model.script.LED] - Source LEDStrip_Kitchen_Cabinet_1
> 2019-03-31 14:27:56.168 [INFO ] [g.eclipse.smarthome.model.script.LED] - LED Strip Item: [LEDStrip_Kitchen_Cabinet_1 (Type=StringItem, State={"state":"OFF","color":{"r":255,"g":255,"b":255},"brightness":64,"effect":"solid","transition":0}, Label=Kitchen LED Strip 1, Category=null, Groups=[gLightDesign, gLEDStrip_Kitchen])]
> 2019-03-31 14:27:56.270 [ome.event.ItemCommandEvent] - Item 'LEDStrip_Kitchen_Cabinet_1' received command {"transition": "153"}
> 2019-03-31 14:27:56.340 [ome.event.ItemCommandEvent] - Item 'LEDStrip_Kitchen_Cabinet_1' received command {"brightness":91}
> 2019-03-31 14:27:56.394 [nt.ItemStatePredictedEvent] - LEDStrip_Kitchen_Cabinet_1 predicted to become {"transition": "153"}
> 2019-03-31 14:27:56.439 [ome.event.ItemCommandEvent] - Item 'LEDStrip_Kitchen_Cabinet_1' received command {"color": {"r": 121,"g": 3,"b": 130}}
> 2019-03-31 14:27:56.505 [nt.ItemStatePredictedEvent] - LEDStrip_Kitchen_Cabinet_1 predicted to become {"brightness":91}
> 2019-03-31 14:27:56.724 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"state":"OFF","color":{"r":255,"g":255,"b":255},"brightness":64,"effect":"solid","transition":0} to {"transition": "153"}
> 2019-03-31 14:27:56.737 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"transition": "153"} to {"brightness":91}
> 2019-03-31 14:27:56.779 [nt.ItemStatePredictedEvent] - LEDStrip_Kitchen_Cabinet_1 predicted to become {"color": {"r": 121,"g": 3,"b": 130}}
> 2019-03-31 14:27:56.996 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"brightness":91} to {"color": {"r": 121,"g": 3,"b": 130}}
> 2019-03-31 14:27:57.065 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"color": {"r": 121,"g": 3,"b": 130}} to {"state":"OFF","color":{"r":255,"g":255,"b":255},"brightness":64,"effect":"solid","transition":0}
> 2019-03-31 14:27:57.083 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"state":"OFF","color":{"r":255,"g":255,"b":255},"brightness":64,"effect":"solid","transition":0} to {"state":"OFF","color":{"r":255,"g":255,"b":255},"brightness":91,"effect":"solid","transition":0}
> 2019-03-31 14:27:57.106 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"state":"OFF","color":{"r":255,"g":255,"b":255},"brightness":91,"effect":"solid","transition":0} to {"state":"OFF","color":{"r":121,"g":3,"b":130},"brightness":91,"effect":"solid","transition":0}
> 2019-03-31 14:27:57.111 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"state":"OFF","color":{"r":121,"g":3,"b":130},"brightness":91,"effect":"solid","transition":0} to {"state":"OFF","color":{"r":0,"g":0,"b":0},"brightness":91,"effect":"solid","transition":0}
> 2019-03-31 14:27:57.154 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"state":"OFF","color":{"r":0,"g":0,"b":0},"brightness":91,"effect":"solid","transition":0} to {"state":"OFF","color":{"r":0,"g":0,"b":0},"brightness":35,"effect":"solid","transition":0}

There is no rule to load previous state and I can see log entries during boot time that it loads the previously set ‘Speed’, ‘FX’, ‘Intensity’ and ‘RGB’ properties /samples from the above logs/:

2019-03-31 14:27:54.314 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Speed changed from NULL to 64.0
2019-03-31 14:27:54.385 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_FX changed from NULL to 7.0
2019-03-31 14:27:54.423 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1_Intensity changed from NULL to 36.0
2019-03-31 14:27:56.996 [vent.ItemStateChangedEvent] - LEDStrip_Kitchen_Cabinet_1 changed from {"brightness":91} to {"color": {"r": 121,"g": 3,"b": 130}}

However the ‘Power’ state is not loaded. Can you please help me to understand what happens here?

Thank you in advance!

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 =&gt; 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 ’ =&gt’ 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.

Dear @Newbie2 nad @rossko57

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 =&gt; mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power' has been removed.
2019-04-06 23:13:51.282 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1 =&gt; mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1' has been removed.
2019-04-06 23:13:51.284 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_FX =&gt; 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 =&gt; mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1_Power' has been removed.
2019-04-06 23:30:20.327 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1 =&gt; mqtt:topic:generic:LEDStrip_Kitchen_Cabinet_1' has been removed.
2019-04-06 23:30:20.328 [temChannelLinkRemovedEvent] - Link 'LEDStrip_Kitchen_Cabinet_1_FX =&gt; 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 :smiley:
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