Help with turning off dimmer when light hits 1%

In view of everything you very kindly laid out here, might it become possible to grant Reactor the ability to “look directly at the target device” and enumerate all of its Advanced > Variables, so that we could more directly read/set their values?

(Similar to, and perhaps an extension of, Expressions and ‘Set Variable’ … only for things external to Reactor instead of internal.)

Can you tell I’d do anything not to have to write or include Lua code whenever possible?? :slight_smile:

P.S. By now, you’ve surmised that my aim all along was simply to modify the value of ‘LoadLevelLast’ to basically force a light to turn on initially at this new dim level instead of whatever it happened to be dimmed to at last turn-off.

  • Libra

Yes, that’s exactly what it does. Already.

I must be missing something obvious, then, cuz this is where I’ve been looking (with no sign of ‘Dimming1:LoadLevelLast’ in the Device Action drop-down list, and I know ‘Set Variable’ is just for Expressions):

I’ll keep poking around. In the meantime, the Lua script someone posted above is setting the variable nicely, so all is working.

LoadLevelLast is a state variable on the device. It is not an action. That is why there is no action listed called “LoadLevelLast”. There is also no action associated with that variable.

You would have to set that variable using luup.variable_set() in a Run Lua action.

Right, we’re on the same page. I just thought it would be neat if Reactor could intrinsically present and set a device’s State Variables in a manner similar to “Set Variable” (without resorting to Lua code).

In the UPnP model, it is generally not the case that you tamper with state variables directly (i.e. you can read but you don’t write). If you want to change a thermostat setpoint, for example, changing the variable does nothing. You have to call an action, which does two things: communicates with the device, and sets the variable. Many actions will also modify other variables in the course of their work, or as a result of some change in operating state of the device (which may be spontaneous).

So changing state variables directly is actually a rare need, and very often the wrong thing to do, which is why it’s not a “first class” action in Reactor.

2 Likes

That must explain, too, why these changing State Variables do not appear as “watched items” under Tools > Device Spy. Because I’m constantly amazed how many times one is expected to modify those variable directly to make something function correctly, despite them being treated as Read Only the rest of the time.

I had been wondering about that, and now understand things more deeply. Thanks!