Hopefully someone can help me with this. It appears that luup.variable_watch only triggers the callback when the variable changes oldVal <> newVal. I have tried adding the state variable to the S_ file with the allowRepeats=“yes” attribute to no avail. I had assumed that this wouldn’t make a difference but there are many mysteries associated with the values in this file to me. Truthfully, I have yet to make any entry in this file do anything except throw a parser error when not well formed.
I found an early post where someone was complaining that the watch was called even if the variable was unchanged so I have been trying to get that behavior to happen to no avail. It looks like someone determined that the behavior was actually a bug and fixed (broke) it.
Seems a bit silly since the old value and the new value are passed to the callback. If your function should only perform the action on value change then compare the old to the new.
Anyhow does anyone know of a way to trap an external variable set even if the value is not changing?
This function works find and is called ANY time someone called luup.variable_set on the variable.
Check over you call … The function must be global (special care is needed if calling from a .lua file) the device must be numeric.
If this did not work … PLEG would not work!
Thanks for the reply. I wonder if there is a difference when you are monitoring all variables for a service id? Or if the variable change occurs from an http request? I am sure the global scope for my callback is correct since I can change the variable and get it to call my callback. For instance, if the variable is 1 and I send an http request to set it to 0 my callback is called. If its currently 0 and I send a request to set it to 0 the callback isn’t called. The condition is the same if the values are reversed.
However, you give me hope that a bit of fiddling will make this work. I have hacked it by setting the variable to nil in my callback and ignoring nil for the new value. This actually works but gives me pause since I am not sure the calls are actually serialized.
Well I figured it out. It turns out that if you monitor all variables for a given service, the behavior is as I described. If you explicitly watch each of the variables it calls the callback function for each variable set… regardless of the current value. It does actually say this in the wiki but it probably wouldn’t be clear if you didn’t try it both ways.