OpenHAB 3.1 expire command does not always work

[mjeshurun (Miki Jeshurun)]

Hello Friends,
I require some assistance configuring Expiration Timers for a few Items controlling Z-Wave switches.
I recently had to format my Raspberry Pi OS, so I took the opportunity to update my OpenHAB system to version 3.1 as a fresh install (building everything anew).
The system is installed on a Raspberry Pi 4 4GB running Raspberry Pi OS with Desktop.
I added a few Z-Wave Things and created corresponding Items to control the Z-Wave switches.
I would like two Items to automatically turn OFF after 1h0m0s, and one Item that needs to automatically turn OFF after 1h30m0s.
I defined the Items in OpenHAB and added the Metadata for the Expiration Timer, but the Items don’t turn OFF when the timer was supposed to finish.
The weird thing is, I tested all three Items configured with an Expiration Timer of 0h5m0s and the three of them turned OFF properly.
Am I doing something wrong?
Any help would be much appreciated.

[rossko57]

See

Expiration timer sometimes fails

Permanently powered zwave device make periodic status reports. You won’t be able to use a long ‘expire’ directly, because the periodic update restarts the timing.

[mjeshurun (Miki Jeshurun)]

Thank you very much, @rossko57, for pointing me to the cause of the problem
I’m sorry for not understanding the proper way to solve this issue, but could you explain how I should proceed?
Do I need to create a separate rules file?
What commands should I include in it?

[rossko57]

Yes, use rules with a Timer. Your choice of rules language (except Blockly has no timing functions yet). Many examples in this forum.

[mjeshurun (Miki Jeshurun)]

Thanks. I’ll try it tomorrow

[ubeaut (Greg)]

You can still use the expire if you set up a virtual/dummy switch as it will not be affected by the z-wave updates.
I use this method all the time.

[Andrew_Rowe]

@ubeaut

You can still use the expire if you set up a virtual/dummy switch

Also a great suggestion
Here is a design pattern which explains the concept by our own illustrious Rich Koshak

Design Pattern: Unbound Item (aka Virtual Item)

Problem Statement Sometimes one needs to create a flag, control, switch, or some other control that is not bound to a device or channel. For example, a Switch to override presence detection. Concept Create an Item that does not have a binding configuration. Simple Example Switch VirtualItem "label" <icon> (groups) // No binding config See the Sensor Aggregation Design Pattern for a more complicated example. The Virtual Item is Override_Presence in that example. Advantages and Limitations V…

[mjeshurun (Miki Jeshurun)]

Thank you friends for the good advice.
Can someone suggest how I should go about writing a script in the UI Rule creator?
Previously, when I used OpenHAB 2.5.11 I had a rule file (in /etc/openhab2/rules) for automatically turning off the water boiler, but when I paste the full text I had in the file into OpenHAB 3.1 Rule DSL (v1) it does not work.
Am I doing something wrong?

rule "Turn Off Water Boiler"
when
         Item Boiler_Switch changed from OFF to ON
then
var Timer myTimer = createTimer(now.plusMinutes(60), [ |
    logInfo("rules", "Timer activated")
    sendCommand(Boiler_Switch, OFF)
])

end

[Andrew_Rowe]

I’m not sure because not using OH3 yet but I think in a UI create rule, you don’t put the ‘rule’ ‘when’ or ‘then’, you only paste into the script box the portion of the rule between then and end
the UI takes care of the when part and rule name ect.

[ubeaut (Greg)]

You just need the code for the then part as you have already coded the event of when changed from off to on in the UI.

[rossko57]

Or if you are comfortable using text rules, continue to use text rules. Paste the whole show into a xxx.rules file and stuff works as it did in OH2.

[mjeshurun (Miki Jeshurun)]

This worked. Thanks for the tip

[mjeshurun (Miki Jeshurun)]

Many thanks to all of you for the help

[mjeshurun (Miki Jeshurun)]

Good day everyone,
Small question, is the timer feature limited to 60 minutes maximum?
I defined one DSL rule to turn off one item automatically after 60 minutes, and it works great.
Rule 1, Item 1:

var Timer myTimer = createTimer(now.plusMinutes(60), [ |
    logInfo("rules", "Timer activated")
    sendCommand(Boiler_Switch, OFF)
])

However, when I defined a second DSL rule to turn off a second item automatically after 90 minutes, the item actually turned off after 30 minutes.
I used exactly similar commands in both cases, except for the timer length.

Rule 2, Item 2:

var Timer myTimer = createTimer(now.plusMinutes(90), [ |
    logInfo("rules", "Timer activated")
    sendCommand(Bathroom_Switch1, OFF)
])

[rossko57]

This has nothing to do with the expire feature, the topic of this thread.

@mjeshurun

is the timer feature limited to 60 minutes maximum?

No.

Note that if your rule runs once, it will create a timer.
If it runs again, it will create another independent timer, but not cancel or destroy the first one. That will still go off 90 minutes after the first run.

However, I would guess you have fallen into the “orphaned timer by file editing” pitfall.

Timer causing error on "Cancel"

When you’re editing rules that spawn long-running timers, beware orphaned timers. If you edit/reload a rules file while a timer is waiting, it doesn’t go away. It will still execute at the appointed time but usually fail because the context was destroyed by rules reload.

[mjeshurun (Miki Jeshurun)]

@rossko57

This has nothing to do with the expire feature, the topic of this thread.

You are correct, I apologize. Next time I’ll ask a question, I’ll double check it directly relates to the thread topic. If not, I’ll search for the right thread to post the questions on.

@rossko57

If it runs again, it will create another independent timer, but not cancel or destroy the first one. That will still go off 90 minutes after the first run.

Thank you. This explains why my item would stop after inconsistent times. I wasn’t aware timers work independently of the item itself.
I guess it’s time for me to learn how to use the virtual/dummy switch suggestion.

[rossko57]

Or learn how to use rules-managed Timers. They can be cancelled or rescheduled.

[Deprecated] Design Pattern: Motion Sensor Timer

There is now a rule template in the marketplace that implements this. See below for instructions on how to set it up for this DP. Please see Design Pattern: What is a Design Pattern and How Do I Use Them for details on how to use DPs. Problem Statement Many motion detectors only report ON when they detect motion but do not send a corresponding OFF after no motion has been detected after a period of time. In addition, often one wants to control a device like a light for a certain period after …