openhab-addons: [mqtt] restoreOnStartUp not working

Expected Behavior When peristence with restoreOnStartUp is set, i would expect that the stored vaue is actually set to the MQTT channel/bound item.

Current Behavior restoreOnStartup is updating the channel and within a split second it is flipped back to the UNDEF state.

Steps to Reproduce

Create a MQTT bridge:

Bridge mqtt:broker:lplxvibroker "Bridge Label" [host="192.168.1.10", port=1883, secure="OFF",retainMessages=false] {
    Thing topic slimmemeter "MQTT Slimmemeter" {
        Channels:
        Type number : stroom_in_stand_laag      "Meterstand in laag"    [ stateTopic="/lplxvi/meterkast/stroom/in/laag" ]
	}
}

Create item:

`Number	verd0_meterkast_stroom		"Meterstand in laagtarief"		    <energy>	{ channel="mqtt:topic:lplxvibroker:slimmemeter:stroom_in_stand_laag"}

Setup persistence:

Items {
	verd0_meterkast_stroom	: strategy = restoreOnStartup, everyChange 
}

Start openHAB and after bridge is initialized post value to topic with mosquito or whatever tool you use (retainMessages = false) and confirm it being stored in the persistence service (i used MySQL)
Restart openHAB and observe the item value not restoring. The event.log would contain something like:

2019-08-02 12:25:10.078 [hingStatusInfoChangedEvent] - 'mqtt:broker:lplxvibroker' changed from UNINITIALIZED to INITIALIZING
2019-08-02 12:25:10.094 [hingStatusInfoChangedEvent] - 'mqtt:broker:lplxvibroker' changed from INITIALIZING to OFFLINE
2019-08-02 12:25:10.414 [vent.ItemStateChangedEvent] - verd0_meterkast_stroom changed from NULL to 9.0  _(I GUESS THIS IS FROM restoreOnStartUp )_
2019-08-02 12:25:10.441 [hingStatusInfoChangedEvent] - 'mqtt:broker:lplxvibroker' changed from OFFLINE to ONLINE
2019-08-02 12:25:10.447 [me.event.ThingUpdatedEvent] - Thing 'mqtt:broker:lplxvibroker' has been updated.
2019-08-02 12:25:10.459 [hingStatusInfoChangedEvent] - 'mqtt:topic:lplxvibroker:slimmemeter' changed from UNINITIALIZED to INITIALIZING
2019-08-02 12:25:10.475 [hingStatusInfoChangedEvent] - 'mqtt:topic:lplxvibroker:slimmemeter' changed from INITIALIZING to ONLINE
2019-08-02 12:25:10.480 [vent.ItemStateChangedEvent] - verd0_meterkast_stroom changed from 9.0 to UNDEF

It looks like the onStartUpRestore is called before the channel is initialized and when the channel is initialized it resets to UNDEF instead of setting the restoreOnStartUp value. If that is true, i qould suggest one of two fixes:

Somehow postpone restoreOnStartUp util channel is initialized
Somehow keep reference to restoreOnStartUp value and set it after channel is initialzed.

Context My smart meter publishes changed value’s to the MQTT topic. Sometimes it takes 2-3 days to get a new value, retainedMessages=false. When the value is not available, the UI is incomplete and keeping track off statistics (with rules) is hardly possible.

Workaround

Setting the broker to retain messages. Can cause side effects and not always possible.
Add a rule that is triggered at startup with a 1 minute timmer that gets the value from the persistence service and use postUpdate to set it to the channel. (i hate workarounds 😃 they always lead to new problems and complexity and you tend to forget them until you are troubleshooting another problem for x hours)

Environment openHAB build #1651

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 23 (22 by maintainers)

Most upvoted comments

And what does happen if your openHAB or zwvae controller restarts in the mean time?

In short, nothing. zwave binding does not push UNDEF. Unrestored Items will stay NULL. That does not mean it’s correct, just what it does. Binding does try to poll devices, replies (and so real updates) can trickle in over a day.

A binding should actually never keep state, that’s what Items are for in openHAB. A “REFRESH” should in theory always re-request the device or service in the background which is the mqtt broker, and that would return “UNDEF” if re-requested for a non retained topic.

I don’t have any disputes with that. The issue is about force feeding UNDEF to Item in absence of any particular device related happening. I suppose the differing view is really about whether you should flag lack of meaningful information at binding start up. For non-retained MQTT, we never have any. As it’s only about start up, Items with no restore or other channels will be NULL, there’s no problem updating to UNDEF then, but neither is there any benefit. A restored Item, or one updated by some other channel, gets trampled.

Maybe we should consider what restoreOnStartup is for. I don’t know if there’s an official reason, but the way people actually use it is to have best available values until something new comes along, which is what leads us here. Perhaps that’s all wrong?

I appreciate that broker retain is a general approach - but in the limited case of openHAB we are most likely restarting the broker as well, so that path is useless (at startup) for many users.

Well, not my decision and I cannot make a case any clearer. Done 😃

Rossko57 on Aug 7, 2019