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.
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.
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.
uid: alert_widget
tags: []
props:
parameters:
- 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
config:
style:
background-color: "=(items[props.item].state == props.alert_on) ? '#FFACAC' : 'white'"
slots:
default:
- component: f7-row
config:
class:
- padding
slots:
default:
- component: Label
config:
text: =props.title
- component: oh-button
config:
action: rule
actionRule: 9a64cb5c4d
actionRuleContext:
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];
item.postUpdate(newState);
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.
# Doesn't work
- context: rule
default: 9a64cb5c4d
label: Rule to run
name: ruleid
required: true
type: TEXT
[...]
- component: oh-button
config:
action: rule
actionRule: =props.ruleid
actionRuleContext:
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:
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?
