forcing polling

Developer's Corner General Dev Discussions
#1

I know that this question has been used and abused so many times. I am trying to get the exact behavior that I normally get when clicking on “Poll now” from the user interface. This is mainly to avoid shadow reads.

I am trying the code below after figuring out the commands from UPnP device spy

luup.call_action(“urn:upnp-org:serviceId:HaDevice1”,“Poll”,35)

will this work to Force polling?

#2

IIRC, the service ID is [tt]“urn:micasaverde-com:serviceId:HaDevice1”[/tt].

… and you’ll have to insert an (emtpy) argument list, see [tt]http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_call_action[tt].

#3

AP15e, you are a guardian angel,

once again , you save the day.

#4

something weird is happening. I have created the following scene that will turn on 2 lights consecutively and return them back to the original state after some time

( i used the generic vera UI scene creator before , the event was working but left sometimes lights on because of polling issues)

When called manually, the scene behaves sublimely as expected. When I try to add an event for it, On Door Open ( Tripped = true) and open the door nothing happens.

luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”,“Poll”,{},14)
luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”,“Poll”,{},36)
os.execute(“sleep 2”)

local light1 = luup.variable_get(“urn:upnp-org:serviceId:SwitchPower1”,“Status”,14)
local light2 = luup.variable_get(“urn:upnp-org:serviceId:SwitchPower1”,“Status”,36)

luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“1” },14)
os.execute(“sleep 5”)
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“1” },36)

os.execute(“sleep 5”)
if(light1==“0”)
then
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“0” },14)
end

if(light2==“0”)
then
luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“0” },36)
end

any thoughts?

UPDATE when i open the door, i am getting visual confirmation on the UI4 that the lights are only turned off ( they are turned off already), when i test the scene manually everything works fine
UPDATE! I am starting to feel that os.execute(“sleep 5”) or luup.sleep(5) is getting ignored within a scene

#5

[tt]luup.sleep(x)[/tt] sleeps [tt]x[/tt] ms. You could add [tt]luup.log[/tt] statements and check the timestamps in [tt]LuaUPnP.log[/tt].

How to sleep:
[tt]http://lua-users.org/wiki/SleepFunction[/tt]

#6

Thank you for your answer, it seems the issue is in the sleep function itself when preceded by a force poll

when you test the scenario below manually by clicking on run , the scenario works just fine…

but when hooking it up to an event , sleep doesnt work correctly anymore

how to reproduce…

**NOT WORKING
luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”,“Poll”,{},14)
luup.call_action(“urn:micasaverde-com:serviceId:HaDevice1”,“Poll”,{},36)
luup.sleep(5000)

luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“1” },14)

luup.sleep(5000)

luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“1” },36)

WORKING***
luup.sleep(5000)

luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“1” },14)

luup.sleep(5000)

luup.call_action(“urn:upnp-org:serviceId:SwitchPower1”,“SetTarget”,{ newTargetValue=“1” },36)

#7

Strange results. According to http://forum.micasaverde.com/index.php?topic=5465.msg31525#msg31525 polling might be slow (but it shouldn’t matter whether the device is polled via ‘Run’ or via an event …). Try increasing the sleep time. Another approach would be to check the the job status of the poll command ([tt]luup.job.status[/tt]) to make sure that the poll has completed.

#8

did u get the same strange results? it doesn’t make sense since it is the same script being called

#9

Scene Luup:

luup.call_action("urn:micasaverde-com:serviceId:HaDevice1","Poll",{},5)
luup.call_action("urn:micasaverde-com:serviceId:HaDevice1","Poll",{},4)
luup.sleep(5000)

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },5)

luup.sleep(5000)

luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },4)

Scene Event:

A sensor is tripped / Yes

Results for Vera V1@1.1.1186:

[ul][li]Scene activated by ‘Run’ button: scene is working as expected.[/li]
[li]Scene activated by event: both lights come on simultaneously after 12-15 seconds.[/li][/ul]

Possible explanation:
The polls take significantly longer if the scene gets activated by an event (why?). In consequence, the [tt]luup.call_action/SetTarget[/tt] commands get queued until the poll jobs are complete. To test my hypothesis, you should watch the poll jobs via [tt]luup.job.status[/tt] (see http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_status)

Another idea:
Try increasing the sleep time. If the lights come on simultaneously after about the total sleep time if the scene gets activated by an event, that would be a strong indication that the calls to [tt]luup.sleep()[/tt] are blocking the execution of the polls and/or the execution of the [tt]SetTargets[/tt].

Very strange phenomenon indeed.

UPDATE:
I’ve come to the conclusion that the calls to [tt]luup.sleep()[/tt] are blocking the execution of the polls and/or the execution of the [tt]SetTargets[/tt] if and only if the scene gets activated by an event.

New bug report:
http://bugs.micasaverde.com/view.php?id=1480

#10

Depending on how these bits are implemented, this could be an OpenWRT artifact. Most Linux/Unix variants of “sleep” depend on SIGALARM for wakeup. If these other events you’re hoping for are also camping on SIGALARM (which we can’t tell under the hood), their event handlers may be getting pre-empted by the sleep handler. This is always one of those tricky things to program around in Unix threaded code that relies on signals.

–Richard