I have problems with my battery powered z-wave devices such as door sensors and smoke detectors when restarting openhab…
Very often their values doesn’t get restored at startup although I know the database (mysql) is fine and values are there…
I often have to restart openhab two times… very often it works on the second try…
And its just the battery powered z-wave devices… all the other stuff gets restored just fine…
Any thoughts would be appreciated!
i don’t think that there a connection between the type of endpoint device and the restore on startup…
all devices are linked to Items which have a state. this state is being restored.
you should post more info like logs and configs
Unlike mains devices, battery devices only respond to queries when they wake up. The wakeup interval is configurable per device, usually it’s 1 or 2 hours by default, so that’s the maximum of how long it can take after a restart for the OH item to get updated with the current state of the associated device.
Now all of that does not have anything to do with persistence.
First, persistence will only store the item state information (if you use strategies like everyChange or everyHour)
Second, if (and only if) you also use restoreOnStartup in addition to those storage strategies, OH sets those items state to the state that was reported last before a restart.
Possibly you don’t have restoreOnStartup working properly and ‘all the other stuff gets restored just fine…’ is not due to persistence but just because OH queries mains devices on startup (well it queries all devices but only the mains powered ones will answer quickly).
PS: you shouldn’t be restarting OH anyway, there is no need to.
Thanks for answering…
I understand the difference of mains and battery powered devices … and I do not persist any values of mains powered devices…
Can it be something with the devices being uninitialized when the restore process is taking place?
Example of one item from unsuccessful startup (events.log):
2018-01-24 10:28:39.447 [.ItemChannelLinkAddedEvent] - Link 'Brandv1_temp-zwave:device:3a4f8c95:node14:sensor_temperature' has been added.
2018-01-24 10:29:04.614 [hingStatusInfoChangedEvent] - 'zwave:device:3a4f8c95:node14' changed from UNINITIALIZED to INITIALIZING
nothing more in the log of that item at that startup…
Successful startup:
2018-01-24 10:34:25.233 [.ItemChannelLinkAddedEvent] - Link 'Brandv1_temp-zwave:device:3a4f8c95:node14:sensor_temperature' has been added.
2018-01-24 10:34:48.472 [vent.ItemStateChangedEvent] - Brandv1_temp changed from NULL to 22.39999999999999857891452847979962825775146484375
2018-01-24 10:34:53.958 [hingStatusInfoChangedEvent] - 'zwave:device:3a4f8c95:node14' changed from UNINITIALIZED to INITIALIZING
I agree that the best way is to never restart 
But I also do like to have backups of my system…and as far as I know that includes a restart…
Given my explanation, I don’t see what you feel is wrong with your system behavior.
It’s coincidence when the next message arrives from your battery device. Set zwave logging to debug level and see in openhab.log what’s happening. You should also increase your persistence db’s log level.
As I said I guess you have not properly configured restoreOnStartup (and as a sidenote: yes, you can even do persistence on mains devices).
Nonsense, just keep it running.
It is like mstormi said. If you restart OH all batterie powered devices do not report their state on restart and if you do not persist them and load it on startup, no state is there. It takes time for OH to collect all states time by time due to wake up interval of each device.
And this behaviour is the same if you change item file. A lot of itmes are reinitialized and therefore empty on this devices
What I do is:
Thanks for replying… Sorry I didnt know there was a built in backup script now without restart…all the better!
@HomeAutomation could you share your code for the rule that manually restores the state of an item? That would be very interesting
rule "PresistenceWiederherstellen"
when
Item SW_PresistenceWiederherstellen changed to ON
then
logInfo("Info", "PresistenceWiederherstellen")
logInfo("Logger","##########################################")
logInfo("Logger","gRestoreStateSW-List")
logInfo("Logger","==========================================")
gRestoreStateSW.members.forEach[item |
logInfo("Logger","Itemname laden: "+item.name)
logInfo("Logger","Itemname laden: "+item.state.toString)
item.postUpdate(item.previousState(false,"mapdb").state.toString)
]
logInfo("Logger","gRestoreStateNU-List")
logInfo("Logger","==========================================")
gRestoreStateNU.members.forEach[item |
logInfo("Logger","Itemname laden: "+item.name)
logInfo("Logger","Itemname laden: "+item.state.toString)
item.postUpdate(item.previousState(false,"mapdb").state.toString)
]
logInfo("Logger","gRestoreStateCO-List")
logInfo("Logger","==========================================")
gRestoreStateCO.members.forEach[item |
logInfo("Logger","Itemname laden: "+item.name)
logInfo("Logger","Itemname laden: "+item.state.toString)
item.postUpdate(item.previousState(false,"mapdb").state.toString)
]
logInfo("Logger","gRestoreStateRS-List")
logInfo("Logger","==========================================")
gRestoreStateRS.members.forEach[item |
logInfo("Logger","Itemname laden: "+item.name)
logInfo("Logger","Itemname laden: "+item.state.toString)
item.postUpdate(item.previousState(false,"mapdb").state.toString)
]
logInfo("Logger","gRestoreStateDI-List")
logInfo("Logger","==========================================")
gRestoreStateDI.members.forEach[item |
logInfo("Logger","Itemname laden: "+item.name)
logInfo("Logger","Itemname laden: "+item.state.toString)
item.postUpdate(item.previousState(false,"mapdb").state.toString)
]
logInfo("Logger","gRestoreStateDT-List")
logInfo("Logger","==========================================")
gRestoreStateDT.members.forEach[item |
logInfo("Logger","Itemname laden: "+item.name)
logInfo("Logger","Itemname laden: "+item.state.toString)
item.postUpdate(item.previousState(false,"mapdb").state.toString)
]
SW_PresistenceWiederherstellen.postUpdate(OFF)
end
Why such a rule?
That’s what ‘restoreOnStartup’ does automatically.
If you just change item file restoreOnStartup will not do his job. You need to trigger thsi manually.
But there’s no need to restore any state when you change items (which you need to do rarely anyway if at all).
Changing items file does not change any of the existing item states.
thanks for all your replies! And thank you @HomeAutomation for supplying your rule… I will save it for the next restart I have to do
In my case if I change item file, all items are set to NULL. The z-wave batterie powered devices are stay at NULL until the device sends an update.
This is why I use this rule.
That should not be the case and isn’t so for others unless you delete/re-add items.
You should find out why it is in your installation instead of working around this (your rule)
Ramp up debug level, split your items file into multiple and experiment with different types of changes and track events.log to find out when it is actually resetting item states. Eventually there’s rules in effect causing this, too.
Clearly I wouldn’t recommend this workaround to others as it means to put your efforts into the wrong place.
You’re missing the point, so let me restate: item states don’t change across restarts unless your persistence setup is broken. You don’t need rules for that !
Better investigate your persistence configuration.
(hint: for permanent log level changes to take effect at startup time, edit /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg)
I tested it again with OH2.2 and it looks like my rule is no longer needed. persistance puts the values back to item after reload of item file.
@mstormi thanks for your patience… I will try to troubleshoot my persistence config to find out if it’s broken …