1) Looking at various discussions on the forum I can see two different variants of syntax related to the createTimer method:
createTimer(now.plusMinutes(5)) [|
// some code here
]
and
createTimer(now.plusMinutes(5), [|
// some code here
])
Are both correct/possible, or only one of them? If both are “correct”, are there any differences to using one over the other?
2) Setting timer variable to ‘null’ after using cancel method.
When I want to stop a running timer I use the cancel method. I often see people setting the timer variable to ‘null’ as well. Is there any point in doing this, other than making sure I do not reference the timer later on?
3) Finally, a question about funny behavior (I think, at least).
I had a rule that triggered on both “received update” and “changed” conditions of the same item. In the rule “body” I created a timer. During debugging of some other stuff that did not work to plan, I added a log point after the timer was created, printing a message including the value of the timer variable. I was expecting the value of the timer variable to be unique for each timer created with a call to createTimer.
Now, when I was testing I changed the state of the item in question (using postUpdate) and this triggered the rule to run twice (since the state was being both updated and changed) and I was pretty surprised when I noticed that there were two log statement indicating creation of a timer - with the same value of the timer variable!
2016-02-20 20:05:09.523 [WARN ] [org.openhab.model.script.S04 ] - S04D001_tAlive created org.openhab.model.script.internal.actions.TimerImpl@1b88061
2016-02-20 20:05:09.585 [WARN ] [org.openhab.model.script.S04 ] - S04D001_tAlive created org.openhab.model.script.internal.actions.TimerImpl@1b88061
How can this be? I am sure there is a logical explanation for this, and I would be grateful in someone could point it out to me.
1: i don’t think its relevant. it must be one of the script “feature”
2: I only make the timer null to test it afterward. so, if timer == null then there is no timer running. that’s not necessary.
3: is it possible that recreating a new timer on the same var recycle the old one?
i did not test the script very much. i am using groovy instead. And in groovy, the openhab timer are persistent. if i do not cancel/delete them, they continue to live after putting something else in the var.
Hmm… there seems to be quite a few of these “features”,
That’s pretty much what I thought/expected, but good to have a second opinion.
Could be, although it sounds like pretty suspicious behavior to me.
Anyway, the main “problem” - or the thing I really do not understand - is the following:
Before the call to createTimer I have some code to check if the timer is active (i.e. not null) and in that case cancel it and set it to null before creating a new timer. I have several log points telling me that a timer exists, it has been cancelled, it has been set to null, etc. - and none of these are printed in the log!
So, to me it appears as there are two parallel execution threads each creating a timer with the same identifier/address/whatever at the same time.
Yes, rules execution can and will run in separated thread. you need to use the lock mechanism to prevent that.
This is extremely relevant to rule with timer
I sort of knew that (albeit, not well enough apparently, :-)), however, I was under the impression that a separate thread was created for each rule upon loading the rules (i.e. when openhab loads rules either at startup or when files have changed). In this case my rule would be running as one thread.
From your answer, however, I gather that a thread is created when the rule triggers, in which case my example would have two separate threads running more or less in parallel since the rule was triggered twice (by update and change). In that case I understand that the threads will be fighting over my one timer variable, and that this may create problem. Is this a correct understanding of how this works?
It is, i had the same problem with some of my rule before i understood this! Each time your rule are trigger, it create a new thread.
The first one check if the timer is null… true… it continue,
the second make the same test, true… continue,
the first create a timer,
the second create a timer in the same var… that’s where it start to crumble
You don’t have the control on the first timer anymore.
