Luup.variable_watch latency?

Developer's Corner General Dev Discussions
#1

I’m wondering how long (min, max) it takes before a ‘watch’ that come active has it’s associated function called - both in Vera and openLuup.

#2

Depends entirely on what else the system is doing.

In openLuup, the callbacks are scheduled, rather than run immediately, so that control returns straight away to the caller of luup.variable_set().

Also in openLuup is an additional (sixth?) parameter to the watch callback function with the sub-millisecond resolution time that the variable actually was changed (rather than the one-second resolution returned by the luup.variable-get() optional return parameter.)

#3

ak - I think what you are saying is that:

  1. depending on the scheduler’s schedule and assuming no other watches need to be attended too - ie the watch of interest is at the top of the queue; it could be serviced immediately.
  2. However, the schedule runs every second, so you could just miss the watched variable changing and the delay would then be one second (assuming the watch is at top of queue)

so min, max = 0.0 &1.0 secs. 0.5 sec on average

And that openLuup can use a shorter scheduled time.

Have I got that right?

Best to describe the problem: I have an alarm panel polled every second using Luup,call_delay() (hence this question Luup.call_delay less than one second - General Dev Discussions - Ezlo Community). When the alarm poll recognises a zone has been opened or closed, the zone variable gets cleared/set and the watch being watched gets triggered and the called function takes action eg turn on a light, etc.

I’ve been using this with a polling of one second with Luup.call_delay() for about four years on openLuup with no problems (that I’ve noticed - thank you). However the latency is annoying (alarm zone trips but light is often slow to come on) and I would like to double the poll rate eg to say 0.5 second or even shorter if everything still works.

Presumably it suffers from both watch and call_delay latencies?

#4

Not sure what you’re meaning here? The ‘one second’ that you refer to is your polling delay? There’s no other one second delay in the system anywhere. If absolutely nothing is going on, then the system scheduler will enter a non-cpu blocking delay of 100ms, but that is curtailed if any incoming socket is ready.

#5

“The ‘one second’ that you refer to is your polling delay” - yes that’s the polling period. I would like to make it shorter, eg say every 0.5 sec. I thought the watch would incur some delay but apparently not (as long as all is quiet elsewhere).

#6

Have you tried zero, as @rigpapa suggested?

What’s actually inside the polling loop?

#7

A think zero may be a bit on the short side, with 100 msec being the suggested result. Basically the delay is the poll period of the alarm’s web page. The status of the alarm is scraped off the page every second, so each zone can be monitored for change. Here’s the code:

Paradox web page scraper

I’ve been looking at doing this differently, as the new method would cut down on the amount of data being shipped around each second.