Updating thing erroneously triggers rule

Setup, Configuration and Use Scripts & Rules
1
  • Platform information:
    • Hardware: Celeron N3160, 4G RAM, 120G SSD
    • OS: CentOS 7.7
    • Java Runtime Environment: 1.8.0.232
    • openHAB version: 2.5.0~RC1-1
  • Issue of the topic: Thing updates, setting it’s status to null when it should be 0

I’ve got a garage door sensor that lately gets updated daily (or close to it). When that happens it’s status goes to NULL and then shortly after to 0. When it’s 0 it means the garage door is closed and that triggers a rule. All this happens while the garage door doesn’t move at all, actually it’s been happening about 3AM each day.

2019-12-27 03:10:19.493 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:2eebb52b:node31' has been updated.
2019-12-27 03:22:52.316 [vent.ItemStateChangedEvent] - zwave_device_2eebb52b_node31_barrier_state changed from NULL to 0

I have a rule that detects the door closing by triggering when the state changes to 0:

rule "Wife leaving the house"
when
Item zwave_device_2eebb52b_node31_barrier_state changed to 0
then
  sendTelegram("telebot", "Garage door closed, image to follow.")
  sendTelegramPhoto("telebot", "http://cam03/snapshot/view4.jpg", "Garage cam-sent from openHAB")
  sendTelegramPhoto("telebot", "http://cam04/snapshot/view0.jpg", "FYard cam-sent from openHAB")
end

Is there a better way to detect the door closing or ignoring the thing update status? It’s not a big deal just a little annoying to see the notifications.

The normal sequence of state changes when the garage door opens and then closes is:

2019-12-26 04:54:57.888 [ome.event.ItemCommandEvent] - Item 'zwave_device_2eebb52b_node30_barrier_state' received command 255
2019-12-26 04:54:57.895 [nt.ItemStatePredictedEvent] - zwave_device_2eebb52b_node30_barrier_state predicted to become 255
2019-12-26 04:54:57.906 [vent.ItemStateChangedEvent] - zwave_device_2eebb52b_node30_barrier_state changed from 0 to 255
2019-12-26 04:55:03.828 [vent.ItemStateChangedEvent] - zwave_device_2eebb52b_node30_barrier_state changed from 255 to 254
2019-12-26 04:55:09.800 [vent.ItemStateChangedEvent] - zwave_device_2eebb52b_node30_barrier_state changed from 254 to 255
2019-12-26 04:55:54.608 [ome.event.ItemCommandEvent] - Item 'zwave_device_2eebb52b_node30_barrier_state' received command 0
2019-12-26 04:55:54.610 [nt.ItemStatePredictedEvent] - zwave_device_2eebb52b_node30_barrier_state predicted to become 0
2019-12-26 04:55:54.655 [vent.ItemStateChangedEvent] - zwave_device_2eebb52b_node30_barrier_state changed from 255 to 0
2019-12-26 04:56:12.516 [ome.event.ItemCommandEvent] - Item 'zwave_device_2eebb52b_node30_barrier_state' received command 0
2019-12-26 04:56:12.536 [nt.ItemStatePredictedEvent] - zwave_device_2eebb52b_node30_barrier_state predicted to become 0
2019-12-26 04:56:19.410 [vent.ItemStateChangedEvent] - zwave_device_2eebb52b_node30_barrier_state changed from 0 to 252
2019-12-26 04:56:34.731 [vent.ItemStateChangedEvent] - zwave_device_2eebb52b_node30_barrier_state changed from 252 to 0

That’s my garage door that’s triggered open and closed with a zwave keyfob, my wife does not use a keyfob, just the normal clicker that came with the garage door opener.

2

You’re confusing things here. Your rule triggers upon an item state, not a thing state.
The rule ignores all changes to the thing already so why do you ask how to ignore that ?
You quote 2 totally unrelated messages, first about a thing, second about an item. Which of them do you feel to be annoying ?
Either way it’s good to have these because they just show what’s going on.
If you dislike them, why don’t you simply ignore them ?
If you rather meant to say by that “seems I have not understood how that works” and feel annoyed about that then that should be your wording, too. And you would need to provide the relevant details of your setup (controller model, thing and item(s) definitions etc).

In fact if you notice the item to change from NULL to 0 every night then yes, something in your setup is seriously wrong as an item will only ever be NULL after you restart OH or parts of it which you should definitely not do every day (and I assume you don’t).

3

While it is true that something is amiss if you get Item state changes to NULL during normal running …

You can improve your rule.
Trigger can be “changed from xx to yy” but perhaps that doesn’t help here if xx might be one of several values.
You can however examine the implicit variable previousState in your rule, and ignore if it was NULL
That will also stop nuisance reports at system boot.

4

The annoyance is when the thing “zwave:device:2eebb52b:node31” updates each day that sets off a chain of events. The state goes to null, then 0 which causes the rule to get triggered and send the images via telegram. Then my phone chimes at 3AM.

I’m not restarting the system on any schedule, it’s got 6 days of uptime and the openhab java process has been running that whole time.

5

You can check in your rule if triggeringItem.previousState === NULL then exit.

But what you really need to investigate is why the device was NULL.
OH does not do that all by itself. You must have setup something weird that results in this to happen.
Check the zwave parameters of node 31.
Check zwave and other OH debug messages around the time that happens.