My old timers don't seem to be running

I’ve had rules like the one listed below since I started my foray into OH. I created these to turn off lights left on by other members of my family.

I just happened to notice that the rules did not seem to be firing…and I tested one and nothing happened.

These rules were created in the early 2.0 days…now I’m running 2.5.2

Has something changed that would disable this functionality?

The reason for the multiple var statements at the top as I have multiple timers in one rule file…just did not post them all.


var Timer zclosettimer
var Timer mcloset
var Timer zsconcetimer
var Timer ubath
var Timer laundryt
var Timer pbatht

rule "Zanes Closet Lights Left On"
	Item ZaneCloset changed to ON or
	Item ZaneCloset changed to OFF
	if(zclosettimer !== null) {
        zclosettimer = null
    if(ZaneCloset.state == ON){
		zclosettimer =  createTimer(now.plusMinutes(5)) [|

No, there is nothing that changed with Timers.

But this rule is not really necessary. You can use the Expire binding (which is not part of core in OH 3 so there is no upgrade problems when you choose to move to OH 3).

Based on my understanding of OH3, did you mean “is NOW part of core in OH 3”

Yes, as of OH 3 M4 Expire has been added as part of the core. I just can’t seem to type on this new phone. Grr.

Sorry…hit the return button too quickly…

I know I could use the EXPIRE binding/function when the switch is turned on by OH, but how would I invoke with a physical button press which would be the main point of activation?

A virtual switch (expire) for the timer & use the rule to set the switch.

How do you do that now? The Rule triggers when the Item changes to ON or OFF. When it changes to ON it will send command OFF after five minutes.

So expire=5m,command=OFF on ZaneCloset Item will wait five minutes after ZaneCloset changes to any state other than OFF and command the Item back to OFF. If it changes back to OFF, the expire is cancelled.

That is exactly what your rule does. The only minor difference is Expire will also send command for NULL and UNDEF but that likely is not a problem here.

It’s all based on Item state so if your rule works now with the physical switch, Expire will too. If not, then expire isn’t going to fix it.

The rules were working fine and then seemed to stop…hence that is why I asked the question if something had changed with timers.

Here’s the item for Zane’s closet…

Switch ZaneCloset "Zane Closet" [ "Switchable" ] {channel="zwave:device:xxxxx:node13:switch_binary"}

Are you saying that if I add the expire code (which I use in other places) to this ITEM, it will get invoked with a physical button press of the ZWAVE wall switch? I didn’t think it worked that way.

The ZWAVE wall switch is mains powered and connected to the fixture, so it turns on the light directly.

If the Item changes state when the physical button is switched. Expire only works on and only sees Item states. The fact that your rule worked, which also depends on Item state changes, there is no reason why Expire won’t work too. It’s all about the Item, as it should be. It doesn’t know or care that it’s linked to a Zwave device.

Ok will give it try.

And my WiFi switch doesn’t care much about you either!!! :stuck_out_tongue_winking_eye:

So I updated the item to read as follows:

Switch ZaneCloset "Zane Closet" [ "Switchable" ] {channel="zwave:device:xxxxxx:node13:switch_binary",expire="5s" }

and then triggered the zwave switch manually, waited over 30 seconds and the light did not switch off.

Did you envision implementing it differently?


I have not tried it on a linked item but I thought tmypu needed an expire command so the binding knows what to do.


The expire command is included at the end of the item after the channel info.

Not quite.


There’s no command here. See the example in Rich’s post (though he’s missing the surrounding " " after expire=), or the docs.

1 Like

You are absolutely correct!

I was in a hurry and did not copy the entire EXPIRE command from what I had used previously, this is only a portion of what is required.

Thanks for pointing it out…now I’ll go test it! :slight_smile:


Happy to report the EXPIRE binding/function (once properly formatted) worked like a charm. I have since added it to all of the items I had rules for and have archived my rules file.

Many thanks to @rlkoshak and @hafniumzinc for getting me pointed in the right direction.

I run into the same problem.

Timers are working well (OH 2.5.8 runtime 2 weeks) but suddenly no timer is running anymore. Restart of rule engine via console does not fix it. I restart OH and the problem was gone.

This leads me to my question, how to check if a timer is really firing at the end? I never had this on OH 2.4 since over 1 year. But in OH 2.5.8 I got it.

Big time typo. Someone else said it better.

Make the first line of the lambda passed to the timer be a log statement and watch for the log statements. OH 2.8 has been out for a number of months, as has 2.10. All the Timer code has remained unchanged from the release of OH 2.5.0 so essentially the Timer code has remained unchanged for nearly a year. This is the first there has been any reports of Timers not working in all that time so it there is a problem, it is caused by a very rare combination of settings and such.

In short, this is going to be exceptionally difficult to reproduce and therefore to fix.

I don’t have a lot of things I can offer for how to go about debugging. KidSquid was able to use the expire binding and therefore sidestep the problem. Perhaps that’s an option for you too. If not you’ll have to go back to first principles. Are the timers in fact being created? Are the events you expect happening? Add tons of logging to find out. Then you need to experiment. Also look for other related behaviors being off. For example, are your Astro timers working (every day Astro creates timers to trigger the sunrise/sunset events)?