We have moved at community.getvera.com

Author Topic: Deactivating hooks  (Read 4430 times)

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Deactivating hooks
« on: April 08, 2011, 09:31:23 am »
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?

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: Deactivating hooks
« Reply #1 on: April 09, 2011, 08:53:34 am »
Quote
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 startup ...

Edit:
And it doesn't seem to make a difference whether startup is false or true ... Does startup work at all?
« Last Edit: April 10, 2011, 12:33:37 pm by Ap15e »

Offline mcvflorin

  • Administrator
  • Hero Member
  • *****
  • Posts: 1755
  • Karma: +11/-3
Re: Deactivating hooks
« Reply #2 on: April 11, 2011, 05:13:35 am »
And it doesn't seem to make a difference whether startup is false or true ... Does startup work at all?

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

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: Deactivating hooks
« Reply #3 on: April 11, 2011, 05:16:22 pm »
Well, let's try finding out what startup 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 "norepeat": "0".

Let's make some earthquakes:

Code: [Select]
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 {9,   1}, {10,   1} - and norepeat doesn't seem to work at all (http://forum.micasaverde.com/index.php?topic=6004.msg35794#msg35794).

« Last Edit: April 11, 2011, 05:20:17 pm by Ap15e »

Offline mcvflorin

  • Administrator
  • Hero Member
  • *****
  • Posts: 1755
  • Karma: +11/-3
Re: Deactivating hooks
« Reply #4 on: April 12, 2011, 04:46:08 am »
Even with norepeat 0 the event doesn't fire if the variable gets updated with the same value as before.

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

I think this sentence explains all:

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.

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.

Offline Ap15e

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1998
  • Karma: +12/-0
Re: Deactivating hooks
« Reply #5 on: April 12, 2011, 05:31:00 am »
Quote
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 boolean, then ({9,true} and {10,true} do trigger the scene). Would you mind correcting the definition of the signature of luup.variable_set() in the wiki?

Quote
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 startup parameter) - and the event is declared as "norepeat": "0".

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 startup: 1 and then again without startup 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.
« Last Edit: April 12, 2011, 05:32:45 am by Ap15e »

Offline mcvflorin

  • Administrator
  • Hero Member
  • *****
  • Posts: 1755
  • Karma: +11/-3
Re: Deactivating hooks
« Reply #6 on: April 12, 2011, 11:35:16 am »
Maybe, but the startup argument isn't of type boolean, then ({9,true} and {10,true} do trigger the scene). Would you mind correcting the definition of the signature of luup.variable_set() 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.
Quote from: 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

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.
« Last Edit: April 12, 2011, 11:47:01 am by mcvflorin »