Switch value changing to Null. Why!?

Setup, Configuration and Use Scripts & Rules
1

Hi,

I’m relatively new to OpenHab2 so appologies if this is a daft question.
My requirement is fairly common, to implement presence detection such that I can arm / disarm my house alarm, set random lights etc.
I’ve seen a lot of examples and for the most part I’ve got this working. I’m using a simple (unbound) Switch item (Life360_IsSomeoneHome) to indicate if anyone is home. Changes in the switch are triggered as follows:-

  1. Family members all have the Life360 app on their phone (uses location based services / geofencing)
  2. When Life360 senses the phones have moved either within or away from our home, I use IFTTT to send a command to MyOpenHab (“Life360_IsSomeoneHome = ON” or “Life360_IsSomeoneHome = OFF”) - there’s logic built into Life360 that can tell if the last family member leaves, or the first family member arrives.
  3. MyOpenHab then communicates this to my OpenHabian install on my Raspberry Pi
  4. I then have various rules that are triggered when Life360_IsSomeoneHome changes from OFF to ON, or from ON to OFF.

For the mostpart this is all working fine. However, on occasion the value of Life360_IsSomeoneHome gets set to Null (which stops the rules from firing) - I can’t work out why this would be. It seems to happen when I run the OpenHab app on my iPhone (where I have the Switch item visible) although I don’t alter the value of the Switch through the UI, and even if I did I could only set it to ON or OFF. None of my rules set the value of Life360_IsSomeoneHome to be false. My Raspberry Pi isn’t restarting.

I appreciate there’s a lot of possibilities here, can anyone give me some hints on where to go next / how to debug?

  • Is there a good log category to turn on / monitor?
  • Is this anything to do with Persistence?
  • Could it be to do with how myopenhab communicates with my OpenHabian install on my Raspberry Pi? Can I turn on logging for this?
  • Any other thoughts?

Thanks in advance
Steve

2

The usual suspect is after editing items file or after a reboot (if persistence is not configured). After an items file is edited all values (at least the ones in the item file) are reset.

If it’s not related to this you should try checking your events.log file and see when the item status changed and what happened at that specific time.

3

Hi,

Thanks for the info. I’ve certainly been editing the Items file a fair bit. A couple of follow-up questions if you don’t mind:

  1. So if I put this item in it’s own .item file, will that potentially fix the problem?
  2. There’s an implication in your answer that if I implement persistence this could solve the issue too, is there a link you can point me to, to help here?

Many Thanks
Steve

4

No. All items are reloaded when any items file is modified.

Yes, persistence with a restoreOnStartup strategy will set items back to their previous state, which should resolve your issue. It looks like the 2.x documentation is lacking Persistence info, but you can follow the reference link to the 1.x Wiki. The setup info will need to be interpreted for a 2.x setup (install/configure through PaperUI, or modify your addons.cfg and runtime.cfg). If you are planning to use persistence just for restoring the value at startup, MapDB is probably best/simplest. Which ever you use, you will need to build your *.persist file and specify the strategy. It may be a bit daunting when first reading about setting it up, but there’s not much to it really. Try it and report back if you have questions. There are plenty of posts here about setting up persistence.

5

An alternative/short term solution would be to add a rule at startup that assumes you are present after a restart:

rule "System started"
when
    System started
then
    Life360_IsSomeoneHome.postUpdate(ON)
end

This will also fire after saving an items file or the rule file it is in.

6

Thanks - That’s really helpful, appreciated

7

For me this is not the “short term solution”.

I think it is important to realize, that there are multiple situations where your Items can be uninitialized. After saving a file, after restarting openHAB, after rebooting the system, after restoring a backup, …

Every good setup should hence have measures to make sure important items are correctly initialized. Your rule is a good first step but should be conditional. Your rule will set the presence to ON, even though, this might not be the case. This might have unwanted effects (rule execution trigger or persistence storage) or might mislead the end user (wrongful data on UIs). I’m using a slightly tuned rule, that even found its way to the documentation:

http://docs.openhab.org/configuration/rules-dsl.html#system-based-triggers

I’d recommended to implement two strategies in your rules to cope with not yet initialized Items:

  1. Conditional initialization of Items (often Virtual Items):

    rule "Kodi init"
when
    System started
then
    createTimer(now.plusSeconds(30)) [|
        if (Kodi_Summary.state == NULL || Kodi_Summary.state == "") Kodi_Summary.postUpdate("unknown")
    ]
end

  2. Conditional rule execution if a subset of Items might not be initialized yet:

    rule "Kodi Summary update"
when
    Item Kodi_PlayerState changed or
    Item Kodi_Title changed
then
    if (Kodi_PlayerState.state == NULL || Kodi_Title.state == NULL) return
    //Actual logic follows here
end
1 Like
8

Just to add my two cents… I agree with Thom. In this case, it is important to think about the impacts of blindly initializing the Items. It is far better to be deliberate and treat the NULLs as a special case in the rules that care IsSomeoneHome.

If you are certain that there are not impacts, then I would at least initialize IsSomeoneHome to OFF rather than ON. I think it is much better for the automation to come up in its most locked down state (i.e. assume everyone is away) than wide open.

And even when using restoreOnStartup you can be in a situation where the state of the Items changed while OH was down. So where possible, even when using restoreOnStartup, it is better to have a System started rule that actively is able to figure out what the true state of the Items should be (see the Time of Day DP for an example).

Depending on how the Items are being used, it might be better not to restoreOnStartup or blindly initialize Items and treat the NULL as a special state. Other times restoreOnStartup may be a great choice. Still other times blindly initializing the Items to some state may be acceptable. It all depends on context.

And despite the argument Thom and I had the other day where I kind argued against what I’m about to say, if you want to only use one approach and cover all your bases, take into account the NULL Items in your Rules will never let you down. With the other two approaches, you have to be very careful to review all your rules and take the Item’s initialization into account for any new rules you write.

1 Like