How to update state of contact when the state is out of sync

I have a Z-wave door sensor with a contact point for open/closed. Occasionally, the door event state does not update when the door is closed. It might be a missed event, or something physical at the switch, but the reason doesn’t matter. I get an alert that the door is open when it is in fact closed.

I’d like to be able to force the state of this back to “CLOSED” via the UI, basically clearing the false positive, so I don’t have to physically open and close the door to fix it (esp if I am not at home, which makes that option inconvenient).

Unfortunately, contacts can’t take commands, so I can’t fire off a rule or use a toggle UI element or whatnot to force the state. I tried to link the item as a switch instead of a contact, but then it won’t auto-update (I have tired mapping the OPEN/CLOSED commands to ON/OFF with no success).

What am I missing here? Or is there a better way to do this?

EDIT: I aware that there is an underlying reliability issue that needs to be addressed. This is a temporary fix while I figure out what is wrong.

The state update should not have been missed. Solve the problem by figuring out why the status update didn’t reach openhab. Signal strength issue?

You can override and update the contact state manually as a last resort, not ideal. To do this just send an update to the contact item with your overridden state. I never had to do this in my system. It’s masking the problem and it’s not automation.

I think I figured out a way to do this. I map an item as a switch, but need to use the MAP profile and use this mapping:


Then I can use metadata to have it display “Open” or “Closed” instead of on/off.

But I’d still like to know if there’s a better way to do this.

The state update should not have been missed. Solve the problem by figuring out why the status update didn’t reach openhab. Signal strength issue?

I am fully aware that this is masking the problem and that the update should not be missed.

Solving that problem is a lot harder. I actually have two switches that are giving me grief: one is a hardwired contact sensor attached to a Z-wave relay, and the other is a Z-wave tilt sensor for the garage door.

I get what you are saying, but mechanical devices are not reliable like electronics. Sometimes a mechanical switch sticks. Replacing the tilt sensor is probably the right answer here (the other garage door doesn’t exhibit the issue), but changing out the hard-wired door sensor? That is a tougher nut to crack. I need a band-aid until I can get this figured out.

I understand why you are resorting to this, because you can send a command to a switch item whereas you can’t send a command to a contact item.

But you can update (not command) the state of a contact item thus should achieve the same result without adding complications

But you can update (not command) the state of a contact item thus should achieve the same result without adding complications

How do I do that through the UI, though? Ideally, I’d have a custom widget that displays my alert items. I tried the oh-toggle component, but that sends commands, not updates. I then tried oh-button, but the list of actions does not include “update”. It can run a rule, though. I’m shaky on Rule DSL so if this is the answer some tips would be appreciated.

Someone more familiar with the UI might chime in later. In the mean time, you could create a script, and call that script from your widget.

The script can be done using Blockly, like this:

Looks promising. I will try that out. Thank you!

OK. Here’s what I ended up with. The widget:

uid: alert_widget
tags: []
    - description: Label
      label: Title
      name: title
      required: false
      type: TEXT
    - context: item
      description: Item to display
      label: Item
      name: item
      required: true
      type: TEXT
    - description: Item state when alert is off
      label: Normal state
      name: alert_off
      required: true
      type: TEXT
    - description: Item state when alert is on
      label: Alert state
      name: alert_on
      required: true
      type: TEXT
timestamp: Jan 15, 2024, 12:31:31 AM
component: f7-card
    background-color: "=(items[props.item].state == props.alert_on) ? '#FFACAC' : 'white'"
    - component: f7-row
          - padding
          - component: Label
              text: =props.title
          - component: oh-button
              action: rule
              actionRule: 9a64cb5c4d
                itemName: "=props.item"
                newState: "=props.alert_off"
              outline: true
              text: =items[props.item].displayState

And the rule, using the JavaScript add-on:

var item= items[itemName];

One surprise here was that the actionRule parameter had to be the script’s uid. You can’t use a script name. Presumably that is because the rule action is used to run both rules and scripts, and using only a name would be ambiguous.

It’s because uid is fixed whereas you can change the rule’s name.

Maybe. One thing I experimented with was this:

# Doesn't work

    - context: rule
      default: 9a64cb5c4d
      label: Rule to run
      name: ruleid
      required: true
      type: TEXT


          - component: oh-button
              action: rule
              actionRule: =props.ruleid
                itemName: =props.item
                newState: =props.alert_off

That gave me a rule and script browser, similar to how a context of item gives you an item browser. But using various forms of “props.ruleid” didn’t work and I couldn’t find a function to turn a script name into a uid. (That being said, this isn’t documented anywhere that I could find, so I didn’t expect it to work, but I still found it odd that the UI supports it–unless I was doing something wrong).

Harcoding the uid is obviously fewer steps and more convenient, but it is a bit more obscure.

Why not? You can postUpdate from a rule. A MainUI element can call a rule directly. So you can create a rule that updates the Item and configure the UI element to call that rule.

Tried how? A transform profile with a mapping going both ways should work just fine.

Note, if you send the command REFRESH to the Item, the Zwave binding will attempt to get the current state of the device. However, it can’t really poll a battery powered device so if this sensor is battery powered that won’t really do anything for you.

Doesn’t even need to be Blockly.

Create the Rule, add an Item Action to update the Item to CLOSED. In the code tab it’ll look something like this:

configuration: {}
triggers: []
conditions: []
  - id: "1"
      itemName: FrontDoor_Sensor
      state: CLOSED
    type: core.ItemStateUpdateAction

You should make the rule to call a parameter too. You figured this out.

Scripts, Schedules, and Scenes are just special cases of rules. The name of a rule is not guaranteed to be unique but the rule UID is guaranteed to be unique. When you create the rule, I recommend getting into the habit of changing that random string to something more meaningful.

But that selection dialog will show you the rule name, but set the property to the rule UID.

The selection dialog will set the property to the rule UID, not the name so it’s not clear why it’s not working as expected. Not every property in a widget supports expressions. I would expect the actionRule to do so though.

What happened when you tried this? Anything in the logs?