Restoring settings after a reboot for z-wave

  • Platform information:
    Release = Raspbian GNU/Linux 9 (stretch)
    Kernel = Linux 4.19.66-v7+
    Platform = Raspberry Pi 3 Model B Rev 1.2

I use the OpenHab to run most aspects of my house so I am pretty reliant on it working. Most items are z-wave. The issue I have is post reboot, caused by a powercut, or me just re-booting the system after and upgrade. When I do this all my modules apparently come back online, however they don’t work within any of the rules I have set. For example my Airsource heatpump is not signalled on from a rule that looks at water temperature and electricity costs. However is I manually turn the heat pump relay on from within OpenHab it seems to reset the logic and start working again with no issues. The same is true for motion sensors turning lights on. If I manually toggle the light switches in OpenHab just once they all start working correctly again. So is there a setting I’m missing or some trick I can use to get everything restored after a reboot ?
Tim Scott

I guess this comes from undefined status of all items after reboot.
The items themselfs do not know anything about the reboot so they do not post their status.
For the binding they are simply in a “undef” status.

You could use a persistence service and add a parameter “restore on startup”.
Hope this helps.

There’s a couple of things you would need to tackle to make it a smooth experience.

First, get decent hardware and software:
An UPS you attach your most important boxes (RPi, router, …) to. There’s also RPi hats.
Migrate over to openHABian, check out openHABian | openHAB and the auto backup feature in particular.

Second, use mapdb persistence (in addition to whatever you do. You failed to explain your SW setup)

Third, rework your rules to have a “init” rule that sets all relevant states to a starting default.
Trigger this rule on “System started” and manually if needed.

I agree with all the good advice above, and have only one thing to add. Take a look at your rules and try to figure out why they are not running under these conditions. As Christian points out, the items that are not working are probably in an undef or null state. A robust rule should be able to handle this. Depending on your rules it could be that the rule is not even triggering because you have a changed from condition on the trigger that does not include undef or null or maybe there are tests of the item states inside the rule that don’t take these possible states into account.