Hi,
after every start/restart of openhab2.service the state of my Fibaro FGK-101 door/window sensors is NULL. I need to manually open all sensored windows once in order to receive a valid state like OPEN or CLOSED.
My items are defined like this:
My rules are only acting if “windBad.state == CLOSED” or “windBad.state == OPEN”. An undefined state like NULL causes no code to be executed, which is what I want.
But how can I force the sensors to report a valid state after startup?
For example, use Mapdb persistence service and persist your items or all items and you will have the last state restored after startup.
Example for a mapdb.persist file:
// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
// if no strategy is specified for an item entry below, the default list will be used
default = everyChange
}
/*
* Each line in this section defines for which item(s) which strategy(ies) should be applied.
* You can list single items, use "*" for all items or "groupitem*" for all members of a group
* item (excl. the group item itself).
*/
Items {
// persist all items once a day and on every change and restore them from the db at startup
* : strategy = everyChange, everyDay, restoreOnStartup
// additionally, persist all temperature and weather values every hour
Temperature*, Weather* : strategy = everyHour
}
I thought about persistence but kept away from this kind of solution, because a persisted state is probably not the actual state. What if a window has been opened after shutdown and before start? I will receive “CLOSED” from the database while the correct state should be “OPEN”. This will lead to a wrong behaviour of my rules.
If they’re battery operated devices you can’t do anything about it but adjust the wake up time interval of the nodes but that would impact battery life. Persistance is the way to go IMO, the system should always be on anyway?
In my early days of OpenHAB’ing, what you describe above was something that bothered me quite a lot as well. I wanted my system to have correct state on all items “immediately” after being started, and I could not get my head around why this was not simply happening.
After cooling down a bit, and getting a better understanding of how Z-Wave works, in particular when it comes to battery operated devices, I realized that I was putting too much focus on the “immediately”-part of the above.
A battery operated device will eventually report the correct state - it is just that it may take some time, depending on the configured wakeup interval. I believe that for Fibaro devices, the normal wakeup interval is 1 hour (3600 seconds) from factory.
As indicated in another post, you can lower the wakeup interval, but this is proably not a good idea since it will negatively impact the battery life.
Using persistence (as suggested in another post) has the obvious drawback (as you already pointed out), that you may reload the incorrect state since the physical environment may have changed during time your system was out of service.
My current approach to this is the following:
Use MAPDB persistence with “restore on startup” (on virtaully all items).
Try no to restart the system unless really needed.
When system is indeed restarted, understand that it will need some time (maybe an hour or two) to restore correct state.
The main reason for using MAPDB persistence (with restore on startup) is to quickly recover from the cases where I modify an items file. When an item file is reloaded, the item states go back to undefined, and then persistence will restore the last state. Since this is happening very quickly the chance of someone opening or closing a window (in your case) at that exact time is slim, so the state will be mostly correct.
If I bring down the system, however, there is a much bigger chance that some phsycial attribute has changed while the system was down, so in that case I mostly regard the system as “initializing” for the next hour or two.
I came from z-wave.me where - seemingly(!) - none of the exact same devices never had an undefined state upon startup within the last 2 years. So I thought I had to change one of the device parameters within HABmin for a betteer communication between the devices and z-wave binding. But maybe z-wave.me had some internal persistence or just rolled a dice upon startup
@KjetilA: Most of the fibaro sensors were set to a wakeup interval of 16777216 seconds which is more than half a year. Some others (maybe bought a bit later) showed up with 4000 seconds wakeup time. I thought none of both kinds were reporting a valid state after a whole night. But maybe I mixed that up a bit.
You are right. Restarting brings down the system for just a few seconds where the chance of some manual operation is very small.
Alright, I will implement where you three guided me to
