Hey folks
question … I have correctly set influx persistence on various stuff, which I can see in influx db when viewing data.
But after OH restart some of those are not populated and OH things they are undef.
specifically Switches states, is it something which is not meant to be restored after startup?
I have my persistence for Switches set as follows:
Use the Mapdb persistence service for restoreOnStartup. It is specifically designed for that purpose.
What may be happening is that InfluxDB service is not running yet when the start up is going on.
You also need to be aware that some bindings by their nature like MQTTv2 will set the items at UNDEF even after a successful restoreOnStartup.
why would mqttv2 set items to undef by nature? as they have values from persistence?
Does it mean that mqtt values is not worth to restoreonstartup? would it be simplier just to retain all messages then? will mqtt binding pickup those msgs after reboot?
This is a little of a thorny issue as there is some disagreement as to how the binding should work. I will try to find the thread but others feel free to post it cause is late and I’m tired
The reason why the binding sets your Items to UNDEF is because after OH gets it’s new connection to the broker it doesn’t know the state of those Items because there is no message to receive.
There is an issue open and I think there are plans to break this behavior and have the binding just leave the Items alone instead of reporting them as UNDEF. Personally, I think UNDEF is the more appropriate behavior. See https://github.com/openhab/openhab2-addons/issues/5879 for the issue.
I can’t remember the forum thread either and a quick search didn’t find it.
there is no need to search for some threads … I was just surprised it’s not working as expected and it’s not really mentioned anywhere.
As mqtt is very usable as well as easy to use it would be nice for further reference make it acknowledgeable.
I don’t mind to have certain messages retained, but as I was not aware of this binding’s design I was using persistence instead and then encountered this strange behaviour when I was monitoring something else that day
And as this aplies probably not ontly to switches, but as well temperature and other stuff, I will probably retain everything important, instead of hoping for persistence tho.
That would be the more MQTT appropriate approach I think (though that opinion is controversial but at least I have sited references that back it up in the github discussion). Just be careful not to use retained for messages that represent momentary events (e.g. button presses) or for sensor readings which may go stale.
If your temp sensors report once a minute and it doesn’t matter if OH has to wait up to a minute before it gets the temp and you don’t want OH to pick up a temp reading from hours ago if the sensor goes offline, then you should not use retained.
sure
btw all this mqtt is not really using restoreonstartup persistence explain why I’ve seen always errors within rules in logs, as those which are calculating stuff from mqtt data were null/undeff after start which now is explained why.
on the mqtt binding discussion: i don’t really see a reason why it should not be restored from persistence (as this would be more consistent approach in OH) because in case of retained msg it would override persisted value anyways… so this UNDEF after start seems to be quite odd.
(same thing is happening when mqtt broker is restarted btw)
