Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
Hello,
We are testing out the EnableTimer for a timer and it doesn't seem to work.
According to this article, DisableTimer or EnableTimer allow manual enablement reflected by property Enabled. We tried executing in the Thing itself and calling it by a separate service. Neither seem to work. Is there something we're missing or there a bug with this service?
Just to note... According to this article, it says that having "Automatically Enable Timer on Startup" disabled, every time after saving the Thing, Enabled property will be set to false. This says it's for Thingworx platform 6.0 and we're running ThingWorx 9.0.2 but just wanted to add it here incase it's relevant.
Thank you for the help!
Solved! Go to Solution.
Ah, good thing you found it
But the observation is correct: When the timer starts, directly the first event is fired and then each <configured interval> ms.
If you want to 'skip' the first run you could add a boolean property "isFirstRun" with default value true to the timer. In the timer event subscription you check pseudocode if(me.isFirstRun) {me.isFirstRun = false;}else{ ..logic.. +disableTimer }. Before starting the timer again you want to reset the property to true.
Can you add more information on how do you see that it does not work? I tried with 9.1.1 and it seems to work fine when executing the services directly in Composer (did not try via script yet):
- Calling service EnableTimer will get back "no result". Property Enabled is true.
- Calling service DisableTimer will get back "no result". Property Enabled is false.
Like stated in the article you shared the "automatically start timer on startup" will en-/ or disable the Timer like stated (also in 9.1.1) when the entity is saved. But the service calls (Enable/DisableTimer) will not save the entity.
One common issue with Timers/Schedules is that the runAsUser needs to be set. Otherwise it will not run. If the user is not set also an error is thrown when the Enable/DisableTimer servies are used.
Sure thing. Thanks for the help.
To start, I have "Automatically Enable Timer on Startup" is disabled since I want to enable/disable this timer with other code in my system. The property Enabled is false.
- Calling service EnableTimer will get back "no result". Property Enabled is false right after. If I refresh or save, property is still false.
Maybe I'm confused on the "Automatically Enable Timer on Startup". Can you not have this disabled and then use services to enable/disable the Timer and then use the timer (use Event Timer, etc)? I've noticed some Things you don't need to save to make changes. Like adding properties via scripting or adding alerts, you can just restartThing and have the changes on the entity be made. Are timers not the same?
This seems weird. I can execute Enable or Disable service on the timer and the property will show enabeld/disabled directly. Maybe you need to refresh properties to see the change (but you mention you already did..)? You don't have to "Save" the entity after the service calls.
I may be able to test with 9.0.2 Thingworx version later. Maybe the version behaves differently...
Believe I found the issue but may have found another... I had a subscription fired on Event: Timer. In this subscription I have some code to run a service and then disable the Timer afterwards. I didn't think about this because I have my Update Rate set to 1800000 (30 minutes). Once I commented out the DisableTimer(), the Timer stayed enabled.
if (...) {
Things[...].service();
me.DisableTimer(); //once I commented this out, Timer stayed enabled
} else {
me.DisableTimer(); //once I commented this out, Timer stayed enabled
}
I would have assumed enabling the Timer would start that 30 minute timer. After 30 minutes, the Timer event is trigged. Then the subscription would run which would disable the Thing. Am I wrong in my thinking?
Ah, good thing you found it
But the observation is correct: When the timer starts, directly the first event is fired and then each <configured interval> ms.
If you want to 'skip' the first run you could add a boolean property "isFirstRun" with default value true to the timer. In the timer event subscription you check pseudocode if(me.isFirstRun) {me.isFirstRun = false;}else{ ..logic.. +disableTimer }. Before starting the timer again you want to reset the property to true.
That was my exact issue! I appreciate the pseudocode, that worked perfectly for us.
Thank you for all the help!
This information that the timer triggers the Timer Event the first time it is enabled helped me solve a issue today.
I also needed a subscription to disable the timer after its first loop for a desired feature.
Thank you very much!