Solved Problem Restoring Item After StartUp

[papa]

        Problem Restoring Item After StartUp

In this thread I documented a node jumper that could signal my being "away" so openHAB would implement programmed security measures. I wanted to use a hardwired jumper so the state would be restored if power to the node was interrupted & restarted. That worked. However, if openHAB was rebooted (Windows restart, rules edit, etc), openHAB set Away state to NULL so that rules based on Away=ON or Away=OFF did not trigger.

This problem happened even though I had persistence installed & the persistence was set to restore everything on Startup.  In the logs, I can see persistence restoring other values on startup but not the Away values.

Next I created a virtual AwaySw switch on the UI by defining the item:

      Switch AwaySw

Still, if openHAB was rebooted (Windows restart, rules edit, etc), openHAB set AwaySw state to NULL & rules based on the item state failed.

     Next Attempts at Solution

[papa]

        Researching Solutions ...

I found this thread that referred to the official documentation on persistence which mentions problems of persisted items not being restored after startup & possible workarounds.

The official persistence documentation warns "Persistence services and the Rule engine are started in parallel. Because of this, it is possible that, during an openHAB startup, Rules will execute before Item states used by those Rules have been restored. (In this case, those unrestored Items have an "undefined" state when the Rule is executed.) Therefore, Rules that rely on persisted Item states may not work correctly on a consistent basis."

That describes what happened for me & perhaps for some of you.

      Next, Testing a Workaround

[papa]

            Testing a Workaround

From the official persistence documentation, I tried Workaround 1 as follows.

I created a new item:
   Switch vPersistRestoreTimer { expire="15s,command=OFF" }

        I created new rules based on the Workaround:

rule "System start"
    when
        System started
    then
        logInfo("System", "System started (or a rule changed)");
        vPersistRestoreTimer.sendCommand(ON) // start timer
end

rule "vPersistRestoreTimer expired"
    when
        Item vPersistRestoreTimer received command OFF
    then
        logInfo("System", "vPersistRestoreTimer expired")
        AwaySw.postUpdate(if (AwaySw.previousState().state==ON) ON else OFF)
end

        Next, Log Results from Testing Workaround 1

[papa]

        Log Results from Testing Workaround 1

2019-12-09 13:52:53.780 [INFO ] [clipse.smarthome.model.script.System] - System started (or a rule changed)

2019-12-09 13:53:08.856 [INFO ] [clipse.smarthome.model.script.System] - vPersistRestoreTimer expired

2019-12-09 13:53:08.872 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'vPersistRestoreTimer expired': cannot invoke method public abstract org.eclipse.smarthome.core.types.State org.eclipse.smarthome.core.persistence.HistoricItem.getState() on null

Log entry 1 above indicates the system's restarting.  Log entry 2 catches the item expiring 15 seconds later as the item defined.  Log entry 3 indicates that Workaround 1 failed on a null value. Again, if openHAB was rebooted (Windows restart, rules edit, etc), openHAB would set AwaySw state to NULL & rules which use that switch would fail.

I experimented with the vPersistRestoreTimer item's expire parameter up to 59 seconds, but Workaround 1 still failed for me.

     Perhaps I could have made this work eventually, but I decided on ...

        Trying Another Approach

[papa]

        Trying Another Approach

The failure to restore the AwaySw value only happens when openHAB restarts so my new rule triggers when System started.

I always know the day I will leave & the day I will return. These values can be set in rule variables & at system startup, can be compared with what is obtained by now.getDayOfYear.

rule "Restore Away at System start"
    when
        System started
    then
            // See mistupid.com/calendar/dayofyear.htm for a day of the year calculator
        val Number startGone = 335 // day of Year that gone period will start, 12/1/2019 & same or similar date in other years
        val Number endGone = 339 // day of Year that gone period will end 12/5/2019 & same or similar date in other years

        logInfo("System", "System started (or a rule changed)");
        var dayOfyr = now.getDayOfYear //
        logInfo("time", " dayOfyr = " + dayOfyr)

        if(dayOfyr >= startGone && dayOfyr <= endGone) sendCommand(AwaySw, ON)
        else sendCommand(AwaySw, OFF)
end

Each time I will be gone, I can update the rule's startGone & endGone variables. This approach works:  When the system restarts, AwaySw is always restored to the value it should have.

        Takeaway Thoughts

[papa]

        Takeaway Thoughts

As warned by the official documentation for openHAB persistence, persistence may sometimes not restore item values after a system restart.

Perhaps in those occasions, we can successfully use Workaround 1 that is found in the official documentation for openHAB persistence.

However, as I did above, we may not have success with Workaround 1. In that case, we might look for a different approach to restoring item values after system restart.

Perhaps base a rule on something that openHAB can access (like day of the year), but that something will not be affected by a system restart.

[papa]

               Another Example of This Problem

            & a Workaround with a Different Approach

When my sump monitor node's microphone sensor detects activation of the sump pump, switchTrips increases by one. See more starting at this post. Like the Away item above, switchTrips is one type of proxy item. Thus, switchTrips data does not come directly from a sensor, but derives from an item that IS linked to a sensor AND from a rule that uses the sensed item data. Away is a binary switch item, but switchTrips is a numeric item.

After an openHAB restart, peristence does not restore at least two of my proxy items (Away & switchTrips). I believe I've seen this with another proxy item that I no longer use. The above shows how I created a workaround for Away. In posts starting here, I show my workaround for switchTrips.