OH3: prevent item.state == UNDEF or NULL

Setup, Configuration and Use Items & Sitemaps
1
  • openHABian 3.4.3 on rPi4 with 4GB

Background

I experienced UPS power outage for my openHABian Raspberry Pi.
As a result I lost persistence data since the last reboot, which was in August 2023.
At the time it did not occur to me to use the mirrored SD card as primary, which supposedly contains the persistence data, hours up to the failure.

Generic problem

Post the above event I have 1,234 items, of which 7 are UNDEF and 296 are NULL. (How I got these numbers.)
Irrespective of what causes these states; be it a power failure, disk corruption, or a simple restart… Is there a way to prevent these states?

Options?

I have map.db to restore all values?!
I have rrd4j to restore number values?
I don’t want to include “or condition is NULL” in every conditional rule
I can set all of these on system startup (cumbersome)

Understanding that mapdb restores all types of values, should I use it exclusively to restore last known values?

Any hints appreciated.

2

I have configured restoreOnStartup for all items in mapDB persistence only.
Never had an issue with missing values on startup.

1 Like
3

Thanks… I just removed restoreOnStartup from rrd4j.persist and and kept it in mapdb.persist.

4

I use the following approach to restoreOnStartup with the caveat that I am running on a VM with an UPS attached. I’ve never suffered a data loss due to an unexpected loss of power.

  1. MapDB: everyChange, restoreOnStartup
  2. rrd4j: everyChange, everyMinute

Both work on all Items (rrd4j on only number Items of course).

This works great for me.

In the past I’ve had an init rule. I added init metadata to Items I want to come up with a specific value and a rule with the following couple lines of code (translated from the original Jython to JS Scripting):

items.getItems().filter( i => i.getMetadata('init'))
                .forEach( i => {
                  i.postUpdate(i.getMetadata('init').value);
                });

But I don’t use that any more (hence the need to translate it above). But if you need to initialize some Items to something other than what restoreOnStartup sets it to that would be a good approach. I’ve thought about making that into a rule template but it’s so simple I don’t know if it’s worth it. It’s utility is relatively low as well since restoreOnStartup handles 99% of all the cases.

One important thing to realize though is that system startup is not the only time that an Item can be set to NULL and UNDEF is a similar state that the Item might get set to. Even though it’s more work, this is really the only correct answer. Your rules should be robust enough to give meaningful errors when the Items are in unusable states.

You probably don’t need it on all rules for all Items, but it should be on enough rules and Items used by those rules to make it reasonable to detect what’s going on and recover.

1 Like