Author Topic: Interval timers  (Read 327 times)

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 746
  • Karma: +40/-7
Interval timers
« on: July 11, 2017, 03:58:43 am »
Hello akbooer

Looks like a slight problem with the interval timers. I'm sure timers are your favorite thing? Using the latest demo code from GitHub:

I have a timer that is meant to run every 20 minutes and it does. However, if I do a luup engine restart, two things happen:
1) the next pending timer execution time, before the luup engine restart, is ignored. Looks like any pending interval timer timeout is ignored.
2) the next execution time is changed, as seen on the Console-->Scheduler-->Jobs page, to:   luup_engine_restart_time + (2*timer_Interval). This screws some of my hardware, as it expects a poke every 20 minutes and that doesn't happen if a luup engine restart occurs.

AltUI shows the expected pending timer execution time, before the luup engine restart occurred and then updates once the 40 minutes is up.

Happy to test any code updates.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 4954
  • Karma: +211/-67
  • "Less is more"
Re: Interval timers
« Reply #1 on: July 11, 2017, 06:18:30 am »
I have a timer that is meant to run every 20 minutes and it does.

Yes, good!

Quote
However, if I do a luup engine restart, two things happen:
1) the next pending timer execution time, before the luup engine restart, is ignored. Looks like any pending interval timer timeout is ignored.

Yes, expected that.  If the time has passed, what else would be 'correct'?  Suppose you waited several days until restarting the system - would you want actions for each of the intervening 20-minute periods to be executed?  I don't think so.

Quote
2) the next execution time is changed, as seen on the Console-->Scheduler-->Jobs page, to:   luup_engine_restart_time + (2*timer_Interval).

Not quite as designed.  Since the code which sets up the timers runs at restart, you would expect luup_engine_restart_time + timer_Interval.  I would need to look into why it's not doing that.

Quote
This screws some of my hardware, as it expects a poke every 20 minutes and that doesn't happen if a luup engine restart occurs.

AltUI shows the expected pending timer execution time, before the luup engine restart occurred and then updates once the 40 minutes is up.

If there is a restart, I assume you have forced it, since openLuup simply does not do the Vera-like thing of restarting randomly.  To me, if you do that, then all continuity with the previous run, in terms of timing, is lost.  If the restart occurred just before one of your 20-minute pokes, then, if things were working as I would have expected, the next one will not be for another 20 minutes.  So, worst case, if you need to prompt something every 20 minutes, and you do restarts, and you still want it to work, then you should schedule a 10-minute timer.

Quote
Happy to test any code updates.

No doubt one in due course, but it will not enforce continuity across restarts.

Whilst all the above should apply to both plugin use of timed action and scenes, I take it your actually talking about scene timers in this case.

Yes, I do love timers  ;)  It is probably the most difficult part of the system (with the possible exception of the HTTP server.)
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P.
Razberry, MySensors Arduino, HomeWave, AltUI, DataYours, openLuup, ZWay, ZeroBrane Studio.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 746
  • Karma: +40/-7
Re: Interval timers
« Reply #2 on: July 11, 2017, 10:18:26 pm »
Quote
"the next pending timer execution time, before the luup engine restart, is ignored. Looks like any pending interval timer timeout is ignored."

Yes, expected that.  If the time has passed, what else would be 'correct'?

If the time is still pending ie has not passed by (which is the case here), then I would expect the code to be executed. It seems this is what happens for other timers. eg I have other timers that occur once a day and they still work fine, even if a Luup Engine restart has occurred in between. But yes, if the timeout is pending but the programmed time had passed, then one must do what can be done to get the timer back on track.

Quote
If there is a restart, I assume you have forced it, since openLuup simply does not do the Vera-like thing of restarting randomly.
Arrhh yes, I miss the spontaneity of the Vera 3 restarts :-\ I have indeed forced the engine restart: I have a whole lot of code that runs my set up, as part of the "Start up Lua". I make adjustments to it from time to time and this requires a Luup engine restart.

Quote
I take it your actually talking about scene timers in this case.
Yes.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 4954
  • Karma: +211/-67
  • "Less is more"
Re: Interval timers
« Reply #3 on: July 12, 2017, 06:46:01 am »
If the time is still pending ie has not passed by (which is the case here), then I would expect the code to be executed. It seems this is what happens for other timers. eg I have other timers that occur once a day and they still work fine, even if a Luup Engine restart has occurred in between.

Ah yes, the secret here is that you are using different types of timer callbacks. : Type is 1=Interval timer, 2=Day of week timer, 3=Day of month timer, 4=Absolute timer.  What works as you expect, are type 2, since the time of day is specified.  However, type 1 are offsets from the time that the first call is made, so could be any time.  Blame the inconsistent definition of Luup timer calls for this one.

I get around this in the openLuup plugin itself by 'synchronising' my first call to a certain time (say, an even number of minutes) using luup.call_delay() and then calling the interval timer.  What's missing in Luup is an interval timer that says something like 'every hour, on the hour', or 'every ten minutes synchronised to clock time.'  It wouldn't matter then what time you made the initial call.  Incidentally, Homeseer does have this type of delay.

3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P.
Razberry, MySensors Arduino, HomeWave, AltUI, DataYours, openLuup, ZWay, ZeroBrane Studio.

Offline RichardTSchaefer

  • Master Member
  • *******
  • Posts: 9432
  • Karma: +716/-133
    • RTS Services Plugins
Re: Interval timers
« Reply #4 on: July 12, 2017, 07:54:31 am »
PLEG also uses "Smart" interval timers.

If you have a 1 Hr interval, it will run it on the Hour.
If you have a 10 minute interval, it will run it on  0, 10, 20, ... 50 after the hour


Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 4954
  • Karma: +211/-67
  • "Less is more"
Re: Interval timers
« Reply #5 on: July 12, 2017, 09:00:48 am »
PLEG also uses "Smart" interval timers.

If you have a 1 Hr interval, it will run it on the Hour.
If you have a 10 minute interval, it will run it on  0, 10, 20, ... 50 after the hour

Makes sense... I may make scene-based schedules work that way.  Although, it did occur to me, that would potentially mean a number of process-intensive actions needing to be scheduled at exactly the same time.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P.
Razberry, MySensors Arduino, HomeWave, AltUI, DataYours, openLuup, ZWay, ZeroBrane Studio.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 4954
  • Karma: +211/-67
  • "Less is more"
Re: Interval timers
« Reply #6 on: July 12, 2017, 11:19:23 am »
Happy to test any code updates.

Updated version 17.7.12 in development branch.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P.
Razberry, MySensors Arduino, HomeWave, AltUI, DataYours, openLuup, ZWay, ZeroBrane Studio.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 746
  • Karma: +40/-7
Re: Interval timers
« Reply #7 on: July 13, 2017, 08:08:38 pm »
OK that's fixed the doubling of the interval time. EDIT but introduced some other problem - see next post.

However, I'm wondering whether one could make use of the "next_run" variable in the user_data.json:

Code: [Select]
if ((now() + luup_engine_restart_period) < next_run) then
     -- use
     next_run
else
     -- use
     now() + interval
 end

Where luup_engine_restart_period would contain a hefty margin. I'm "assuming" most interval timers would be longer than the engine start up time. The interval timer would be unaware a restart occurred. However this may make things appear flaky as the start of the new interval would not necessarily be consistent as it is now. But as you say, in my case I can set the timer shorter than needed ensuring my hardware gets poked as often as needed. Regardless the way you have it at the moment should work OK.
« Last Edit: July 13, 2017, 11:59:06 pm by a-lurker »

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 746
  • Karma: +40/-7
Re: Interval timers
« Reply #8 on: July 14, 2017, 12:16:20 am »
I have two identical temperature servers, which now malfunction. They use luup.call_timer('pollOWServer', 1, tostring(SamplingPeriod), ""). Note they both call the globally defined function pollOWServer - hopefully the scope is contained to each plugin, so they don't trample on each other. They have worked perfectly in the past.

In the console the scheduler says:
   1  2017-07-14 13:51:55        11     Delay    -1s :callback   
   2  2017-07-14 13:51:55        10     Delay    -0s :callback   

The log says:
Code: [Select]
2017-07-14 13:48:04.411   luup.watch_callback:: 136.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature function: 0x1fa6040
2017-07-14 13:48:04.425   luup.watch_callback:: 129.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature function: 0x1fa6040
2017-07-14 13:48:04.628   luup.variable_set:10: 10.urn:upnp-org:serviceId:OWServer1.Devices was: 17 now: 17 #hooks:0
2017-07-14 13:48:04.629   luup.call_timer:10: interval: time=600, days={}
2017-07-14 13:48:04.859   luup.variable_set:11: 11.urn:upnp-org:serviceId:OWServer1.Devices was: 21 now: 21 #hooks:0
2017-07-14 13:48:04.860   luup.call_timer:11: interval: time=600, days={}
2017-07-14 13:48:05.058   luup.variable_set:10: 10.urn:upnp-org:serviceId:OWServer1.Devices was: 17 now: 17 #hooks:0
2017-07-14 13:48:05.059   luup.call_timer:10: interval: time=600, days={}
2017-07-14 13:48:05.352   luup.variable_set:11: 11.urn:upnp-org:serviceId:OWServer1.Devices was: 21 now: 21 #hooks:0
2017-07-14 13:48:05.353   luup.call_timer:11: interval: time=600, days={}
2017-07-14 13:48:05.542   luup.variable_set:10: 10.urn:upnp-org:serviceId:OWServer1.Devices was: 17 now: 17 #hooks:0
2017-07-14 13:48:05.542   luup.variable_set:10: 118.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 16.5 now: 16.5 #hooks:1
2017-07-14 13:48:05.543   luup.variable_set:10: 114.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 15.9 now: 15.9 #hooks:0
2017-07-14 13:48:05.543   luup.variable_set:10: 111.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature was: 15.3 now: 15.3 #hooks:1

Gets repeated endlessly and the CPU usage percentage went through the roof. Second server didn't get a mention and other plugins never got a look in.

When the all is working (using old timers.lua) then scheduler says:
   12  2017-07-14 14:16:42        10     Delay   600s :callback   
   13  2017-07-14 14:16:42        11     Delay   599s :callback

May be related to how the plugin initialises the timing interval.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 4954
  • Karma: +211/-67
  • "Less is more"
Re: Interval timers
« Reply #9 on: July 14, 2017, 07:59:28 am »
Apparently an unfortunate race condition caused (I believe) by a precision mismatch in a differential time calculation.  I've also taken the opportunity to guard against negative delay time parameters.

v17.7.14 in development may fix this, but I'm sure you'll let me know.  These things are excruciatingly difficult to test for (since, by their nature, they are time-dependent) but I will try to beef-up the timer unit tests.  There is, at least, one error in the monthly timer with a pathological set of parameters that I am writing a test for anyway, so need to fix that too.

« Last Edit: July 15, 2017, 07:10:35 am by akbooer »
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P.
Razberry, MySensors Arduino, HomeWave, AltUI, DataYours, openLuup, ZWay, ZeroBrane Studio.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 746
  • Karma: +40/-7
Re: Interval timers
« Reply #10 on: July 17, 2017, 12:26:37 am »
Still a bit of a problem. The negative numbers are gone but in the console the scheduler still indicates zero delays:
   1  2017-07-14 13:51:55        11     Delay    0s :callback
   2  2017-07-14 13:51:55        10     Delay    0s :callback

If this code was in a plugin, then it's seems it may not work:

Code: [Select]
function pollServer()
    luup.log('Hello testing',50)
    luup.call_timer('pollServer', 1, "3", "")
end

function initialise()
    luup.call_timer('pollServer', 1, "15", "")
end


Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 4954
  • Karma: +211/-67
  • "Less is more"
Re: Interval timers
« Reply #11 on: July 17, 2017, 02:55:11 am »
Don't understand it.  My test system is riddled with tests like this and they all work fine.  I try your code too, but something's odd.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P.
Razberry, MySensors Arduino, HomeWave, AltUI, DataYours, openLuup, ZWay, ZeroBrane Studio.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 4954
  • Karma: +211/-67
  • "Less is more"
Re: Interval timers
« Reply #12 on: July 17, 2017, 07:46:09 am »
DO understand it now... previous fix introduced untested (and incorrect) code branch.

Fixed in development branch v17.7.17.

This is not doing my credibility any good at all,  sigh.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P.
Razberry, MySensors Arduino, HomeWave, AltUI, DataYours, openLuup, ZWay, ZeroBrane Studio.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 746
  • Karma: +40/-7
Re: Interval timers
« Reply #13 on: July 19, 2017, 07:21:38 pm »
Your credibility remains in tact. 8) All working OK now. Thank you for your efforts on this one.