Deactivating hooks

[Ap15e]

Is there a way to temporarily deactivate hooks to UPnP variables?

Scenario:
Luup device with a periodically updated data set consisting of several UPnP variables, some of them are hooked by event evaluation.

There is no problem, if only one variable is hooked: update the hooked variable after updating all other variables to keep the data set consistent (from the viewpoint of the event evaluator).

But what if there is more than one hooked variable in the same data set? Is there a way to keep the data set consistent?

[Ap15e]

function: variable_set

parameters: service (string), variable (string), value (string), device (string or number), [startup (bool)]

returns: nothing

The UPnP service+variable will be set to value for device, which if it’s a string, is interpreted as a udn, and if it’s a number, as a device id. If there are events or notifications tied to the variable they will be fired.

Optionally, you can add an argument ‘startup’. If startup is true, this change will be considered a startup value, and if the variable is set to it’s existing value, events and notifications will not be fired.

What would be needed is an argument that would disable the firing of events and notifications - regardless of the new value.

But to be honest, I don’t understand the description of [tt]startup[/tt] …

Edit:
And it doesn’t seem to make a difference whether [tt]startup[/tt] is [tt]false[/tt] or [tt]true[/tt] … Does [tt]startup[/tt] work at all?

[mcvflorin]

@Ap15e

And it doesn’t seem to make a difference whether [tt]startup[/tt] is [tt]false[/tt] or [tt]true[/tt] … Does [tt]startup[/tt] work at all?

It should work, though I cannot tell what it really does.

[Ap15e]

Well, let’s try finding out what [tt]startup[/tt] is supposed to do:

Install the latest version of DAD, create a scene with an event ‘Magnitude of earthquake is greater than’ ‘6’.
The magnitude event is defined as [tt]“norepeat”: “0”[/tt].

Let’s make some earthquakes:

earthquakes = { {7,false}, {7,false}, {8,false}, {9,true}, {9,true}, {10,true},
                {7,    0}, {7,    0}, {8,    0}, {9,   1}, {9,   1}, {10,   1}  }

for i=1,#earthquakes
 do
  luup.variable_set( 'urn:upnp-ap15e-com:serviceId:DAD1', 'EarthquakeMagnitude', quakes[i][1], 4, quakes[i][2] )
 end

Results:

The only earthquakes that don’t trigger the scene are [tt]{9, 1}, {10, 1}[/tt] - and [tt]norepeat[/tt] doesn’t seem to work at all (http://forum.micasaverde.com/index.php?topic=6004.msg35794#msg35794).

[mcvflorin]

@Ap15e

Even with [tt]norepeat 0[/tt] the event doesn’t fire if the variable gets updated with the same value as before.

@Ap15e

The only earthquakes that don’t trigger the scene are [tt]{9, 1}, {10, 1}[/tt] - and [tt]norepeat[/tt] doesn’t seem to work at.

I think this sentence explains all:

@Wiki

If startup is true, this change will be considered a startup value, and if the variable is set to it’s existing value, events and notifications will not be fired.

So, [tt]{9, 1}, {10, 1}[/tt] don’t trigger the scene because their new value is considered the startup value.

@Ap15e

Even with [tt]norepeat 0[/tt] the event doesn’t fire if the variable gets updated with the same value as before.

In this case, the second part of the above sentence applies: if the variable is set to it’s existing value, events and notifications will not be fired.

[Ap15e]

Quote from: Wiki If startup is true, this change will be considered a startup value, and if the variable is set to it's existing value, events and notifications will not be fired.

So, {9, 1}, {10, 1} don’t trigger the scene because their new value is considered the startup value.

Maybe, but the startup argument isn’t of type [tt]boolean[/tt], then ([tt]{9,true} and {10,true}[/tt] do trigger the scene). Would you mind correcting the definition of the signature of [tt]luup.variable_set()[/tt] in the wiki?

Quote from: Ap15e on March 21, 2011, 01:40:40 am Even with norepeat 0 the event doesn't fire if the variable gets updated with the same value as before.

In this case, the second part of the above sentence applies: if the variable is set to it’s existing value, events and notifications will not be fired.

Maybe, but setting a variable to its existing value doesn’t fire the event (even without the [tt]startup[/tt] parameter) - and the event is declared as [tt]“norepeat”: “0”[/tt].

What would be needed is documented at http://bugs.micasaverde.com/view.php?id=1445. You would set all hooked variables to their new value with [tt]startup: 1[/tt] and then again without [tt]startup[/tt] to the same value to provide a consistent UPnP data set from the event evaluator’s perspective.

Conclusion:
You currently cannot implement a Luup device with more than one variable hooked by the event evaluator, because there is no way to temporarily disable the hooks to make the data set consistent.

[mcvflorin]

@Ap15e

Maybe, but the startup argument isn’t of type [tt]boolean[/tt], then ([tt]{9,true} and {10,true}[/tt] do trigger the scene). Would you mind correcting the definition of the signature of [tt]luup.variable_set()[/tt] in the wiki?

It doesn’t work because the function used to get the startup parameter is lua_tonumber instead of lua_toboolean. I’d rather change the function definition to use lua_toboolean, but only if Aaron agrees.

Edit: Aaron agreed, so I modified the function to use lua_toboolean.

@Lua Manual

Like all tests in Lua, lua_toboolean returns 1 for any Lua value different from false and nil; otherwise it returns 0.

/Edit

@Ap15e

Maybe, but setting a variable to its existing value doesn’t fire the event (even without the startup parameter)

Well, I think that’s a mistake in the documentation, and this behavior is not related to the startup parameter.

Anyway, until the new firmware is released, no change in the behavior will be made, because this requires a lot of testing to make sure that nothing broke, and we don’t have the time.