Delayed command for controlling presence modes

1

Hello,

i have a zigbee button with which i wanna control the current mode which can be HOME, SLEEP or AWAY

The current mode should later be represented by a certain color by a color bulb near my entrance.

The problem is, i have to make it foolproof because some of my roommates are just pressing it randomly several times since they may find “nothing happens immediately when i push the button” :smiley:

So, basically i wanna “log in” a certain state, wait a few seconds if nothing changed and THEN set it really.

To make it a bit more complex: The state itself could be changed immediately since i wanna for example change the state light immediately (to stop fools from further button pushing^^), but different other stuff like heating should be a bit more delayed like one minute or so …

is there a “built-in” mechanism to delay an items command trigger when its changed? How could this be solved?

Best

2

No.

There are lots of possible ways.

  1. Create a Timer in a rule. See the code in [Deprecated] Design Pattern: Debounce (even if the post is deprecated the example code is still good). Similar example in [Deprecated] Design Pattern: Motion Sensor Timer and [Deprecated] Design Patterns: Generic Is Alive. Note that all three of these are deprecated because they have rule templates you can install from the marketplace.

  2. Using the Debounce rule template, a proxy Item and two rules. The first rule triggers the rule that controls the light. The Debounce is configured to update a proxy Item after an amount of time. When the proxy Item changes that triggers a second rule to do the stuff that should be delayed.

Rule Templates can be installed from Settings → Automation. See Rules - Basic | openHAB for details.

3

As an automation engineer I recommend living alone.

Solution would be to change it from rolling scene change to push to scene or voice control.

4

Thanks a lot, i’ll both give a try :slight_smile:

5

Sorry, i don’t get it …

I installed the rule template and set up a group

Group g_Debounce_Home_Mode	"Home Mode Debounce Group"

Then i have my wallswitch to be debounced

String Sonoff_Mini_Switch_1_Button_State "Button" <wallswitch> (g_Debounce_Home_Mode) {channel="deconz:switch:homeserver:mini-switch-1:button",  debounce="Home_Operation_Mode"[timeout="2s", command="False"] }

And the item that shpould receive the deblunced item

String Home_Operation_Mode "Betriebsmodus" <home> (g_Flat) ["Setpoint"] {stateDescription=""[options="HOME, SLEEP, AWAY"]}

But all that happens is that

Item ‘Sonoff_Mini_Switch_1_Button_State’ changed from 1970-01-01T00:16:42.000+0000 to 1970-01-01T00:16:44.00

What do i miss?

6

And instantiated? Rules - Basic | openHAB

A Rule Template is just that, a template. You have to instantiate and configure a rule based on that template.

Also, why is this state published as a date time? given the name of the Item and the state, that’s doesn’t make much sense. I’m not sure how the stateDescription options will work.

Also, keep in mind the debounce is only in one direction, from Sonoff_Mini_Switch_1_Button_State to Home_Operation_Mode. Not the other way.

7

Yes, i added a new rule and selected there the debounce group

This item holds a string 1002, 1003 or 1004 ,… it represents the last button state …

I would expect, “sending” this to the proxy item, which is also a string … but instead, the debounce item gets “overwritten” with a date somehow …

8

Set the logger org.openhab.model.script.Rules.rules_tools.Debounce to DEBUG level in the karaf console or log4j2.xml file, or manually edit the logger statements in the script action of the rule itself to log at the INFO level so we can see what the rule is doing.

Something weird is going on with the state description for that Item or the binding or something else. It’s formatting it as if 1002 were 1002 seconds.

What type of Item does that Channel dictate should be used? You can’t just link a String Item to a Number Channel without errors or unexpected results.

9

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.