Reactor/trip tables

First, there is a way in Reactor activity Lua to detect which groups going true have triggered the activity–in the activity Lua is a global table called Reactor , and within it is another table called trip that has as its keys the ID of every group that is tripped. But I don’t think this is going to be as useful as it might be in this instance.

@rigpapa, found the above comment from one of your old replies, and those tables seem to be what I would need, in an inverse way. So how are these tables used in Lua code? I’d need to find out in a single activity which group condition(s) were not satisfied and then send a message based on that information.

I guess another option is to save group status as an (exported) expression variable and then read these with “luup.variable_get” commands.

Using state variables will give you group states, but not condition states. It’s the “old school” way anyway, and it will be deprecated in a future release (if the current firmware lives long enough to see that day).

The Reactor context has tables groups and conditions that can be used to examine the states of things, if you know their IDs. For the root group, which always exists, you can examine Reactor.groups.root.state to see if it is currently true or false. You can use Reactor.groups.root.since to get the timestamp of when that state took effect. The same applies for conditions.

What isn’t in the context is an association between groups and conditions, so you can easily do something like for k,v in pairs( Reactor.groups.root.conditions ) do ... end and test each condition state within a group. That seems useful, and I’d be happy to add it for you (in fact, it has enough merit on its own that I’m going to toodle off and do it right now, available in 3.9 stable later this morning)…

Related Reactor Docs:

Tip: when debugging Run Lua actions, if you use print() statements instead of luup.log() the output will go to both the LuaUPnP.log file and the ReactorSensor’s events stream (which is visible in the Logic Summary in the Tools tab, and much easier to get to).

1 Like

OK. The Run Lua enhancement is done. Updated documentation can be found here:

Run Lua Action (version 3.9 version-specific docs)

The update is in the Github stable branch. To install:

  1. Go to the stable branch on Github;
  2. Download the package by clicking the green “Code” button and choosing “Download ZIP”
  3. Unzip the downloaded archive.
  4. Open the uploader in the Vera web UI at Apps > Develop apps > Luup files
  5. Drag the files from the unzippped archive (no folder(s)) to the “Upload button”
  6. Hard refresh your browser after the reload (automatic when the upload completes).
1 Like

…if there’s not too much trouble, could you add a subkey “name” for conditions? When using this structure, “id” is not very informative, but name could readily be used.

Also noticed that comment type of conditions are also included when the following example code is used

for id,cond in ipairs( Reactor.conditions.grp_jednkh.conditions ) do
    if ( not cond.state ) then
        print("Condition", cond.id, "is false!")
    end
end

If the condition is a group (.type), it will have a .name. Regular conditions do not have names.

Yep, noticed that, but would be helpful if conditions had name. Also I think that the code above should not include comments as they can’t be true or false.

Best Home Automation shopping experience. Shop at getvera!

© 2021 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules