Mapdb: storing UNDEF or NULL

Add-ons Persistence Services
,
1

I have mapdb configured to persist all Items, along with restoreOnStartup.

I have some temperature sensors that occasionally fail, so I’m using the Expire binding to set these Items to UNDEF if they don’t receive an update at their expected interval (this avoids having erroneous values showing in sitemaps).

However, I’ve found that these UNDEF values aren’t being stored in mapdb, so when restoreOnStartup is called, I get the last decimal value. Example here:

$ curl localhost:8080/rest/items/Test_Item | jq .state
"1"
$ curl localhost:8080/rest/items/Test_Item/state -X PUT --header "Content-Type: text/plain" -d NULL
$ curl localhost:8080/rest/items/Test_Item | jq .state
"NULL"
# restart/reload openhab to force restoreOnStartup
$ curl localhost:8080/rest/items/Test_Item | jq .state
"1"

This appears to be intentional behaviour. Does anyone else have this use case, or a better way of doing this kind of thing?

My only thought is a dummy value that Expire binding sets that will be persisted, then a rule that detects that value and sets it to UNDEF.

Alex

2

This isn’t overly helpful but why don’t you fix the sensors? If it were me, I would put the effort there instead of compensating for their failure. To me, an unreliable sensor is not worth having.

Your projected dummy value and rule is definitely an option. Why not simply not restore it on startup… that would default it to UNDEF until it successfully reports in right?

3

I agree, this is a case where it makes no sense to restoreOnStartup.

Beyond that, you can create a System started rule and postUpdate the restored state to those items which will reset the expire binding.

4

Thanks both for your replies.

@Moxified Oh absolutely I’ll fix the sensors, I just want to ensure I gracefully handle any failure that may occur in the future.

One of the reasons I’m doing this is to more easily spot if/when they do fail (battery exhaustion usually). Using UNDEF seems to work very elegantly, except this persistence issue. Do you know of a better way of doing this, generally?

@rlkoshak Thanks for the System started rule suggestion. I wonder if that rule could go further than that and check lastUpdate itself to avoid waiting for the Expire binding to trigger.

Alex

1 Like
5

What type of sensor is it? Can you use some form of heartbeat on it such as network monitor if it is ip based?

6

You can do pretty much anything you want to.

I would not restoreOnStartup. You already have to deal with the fact that the Items might be NULL at some point, so I would leave them as NULL until you get a valid reading. This ensures that you are not acting on stale and incorrect data. When the Item has a value you know that the Item value is valid and recent.

For my sensors, I implement what Moxified describes as well.

7

The sensor in question is an Jeenode board sending data into OpenHAB via the Serial binding, but I was planning to apply the same principles to various Z-Wave Fibaro sensors.

I figured the great thing about checking the value is up to date is that it would detect various kinds of failure.

8

Ok cool I’ll give this a go. Thanks!

9

Absolutely. If you need to generate an alert or suchlike, it should work to put all relevant Items in a Group with an OR aggregation. A rule can watch for the Group changing to UNDEF

EDIT (years later!) - you can now trigger from a Group using member of ... changed to UNDEF to spot timeouts