Reactor vs Multistring as trigger

MarkAgain · January 30, 2020, 6:49pm

I am getting ready to rebuild my system from scratch. I am presently using quite a few Multistring variables as triggers for scenes. I set a number in one of the Multistring variables, received from an IR remote through KiraRxt as a trigger. I have been using the Reactor plugin for a couple of small tasks and I think the Reactor plugin might be more suited to the task.

Would Reactor triggers be more efficient than using the Multistring variable change as a trigger?

I made a test condition and action within Reactor. When I change a variable in a device it causes a light to toggle. It takes as many as 5 seconds to complete the task after setting a variable within a device using “LuaTest 1.7”. Is this a normal amount of time to complete a simple task?

Any suggestions would be appreciated.
Thank you, Mark

rigpapa · January 30, 2020, 7:29pm

Can you post a Logic Summary (Tools tab) for your ReactorSensor? Also what is LuaTest 1.7 and how does that relate to Reactor? I’m not really clear on what you are describing your test.

MarkAgain · January 30, 2020, 8:41pm

Here is a link for LuaTest:
https://community.getvera.com/t/luatest-a-tool-for-testing-scene-lua-code/180205

I was previously using a test condition added to a existing Reactor. I created a new Reactor and the time to complete the actions was reduced substantially to 41ms. I am using the LuaTest to change a variable in the Shade1 vairable “ShadePreset” with the commands:
local dID = 212
local new_preset = 6
luup.variable_set(“urn:upnp-org:serviceId:Dimming1”,“ShadePreset”,new_preset,dID)

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.4 config 19226 cdata 19082 ui 19237 pluginDevice 190
    System: Vera version 1.7.4453 on Sercomm G450; loadtime 1580413805; systemReady 1580413834; Lua 5.1; JSON dkjson 1.2
Local time: 2020-01-30T12:33:05-0800; DST=0; San Bernardino, California United States
House mode: plugin 1; system 1; tracking off
  Sun data: 
  Geofence: not running
====================================================================================================================================
Trigger 1 (#215)
    Version 19082.5 01/30/20 12:30:07
    Message/status: Not tripped
    Condition group "Reactor Sensor 2" (AND)  false as of 12:31:27 <root>
      &-F-group "Shades" (AND)  false as of 12:31:27 <grpnhefe0b>
      |     &-F-service Shade 1 (212) urn:upnp-org:serviceId:Dimming1/ShadePreset update  [1580416233 => 1580416287 at 12:31:27; F/F as of 12:31:27/12:31:27] <condnhefvl6>
    Activity root.true
        Run Lua:
             1: local dID = 46
             2: local P_light = luup.variable_get("urn:upnp-org:serviceId:SwitchPower1", "Status", dID)
             3: luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{newTargetValue = (tonumber(P_light)+1) % 2}, dID)
    Events
        01/30/20 12:30:07 evalchange: newState=true, cond=grpnhefe0b
        01/30/20 12:30:07 condchange: newState=true, cond=root, oldState=false
        01/30/20 12:30:07 evalchange: newState=true, cond=root, oldState=false
        01/30/20 12:30:07 sensorstate: state=true
        01/30/20 12:30:07 startscene: scene=root.true, sceneName=root.true
        01/30/20 12:30:07 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        01/30/20 12:30:07 endscene: scene=root.true, sceneName=root.true
        01/30/20 12:30:07 condchange: newState=false, cond=condnhefvl6, oldState=true
        01/30/20 12:30:07 evalchange: newState=false, cond=condnhefvl6, oldState=true
        01/30/20 12:30:07 condchange: newState=false, cond=grpnhefe0b, oldState=true
        01/30/20 12:30:07 evalchange: newState=false, cond=grpnhefe0b, oldState=true
        01/30/20 12:30:07 condchange: newState=false, cond=root, oldState=true
        01/30/20 12:30:07 evalchange: newState=false, cond=root, oldState=true
        01/30/20 12:30:07 sensorstate: state=false
        01/30/20 12:30:33 devicewatch: device=212, old="6", name=Shade 1, var=urn:upnp-org:serviceId:Dimming1/ShadePreset, new="9"
        01/30/20 12:30:33 condchange: newState=true, cond=condnhefvl6, oldState=false
        01/30/20 12:30:33 evalchange: newState=true, cond=condnhefvl6, oldState=false
        01/30/20 12:30:33 condchange: newState=true, cond=grpnhefe0b, oldState=false
        01/30/20 12:30:33 evalchange: newState=true, cond=grpnhefe0b, oldState=false
        01/30/20 12:30:33 condchange: newState=true, cond=root, oldState=false
        01/30/20 12:30:33 evalchange: newState=true, cond=root, oldState=false
        01/30/20 12:30:33 sensorstate: state=true
        01/30/20 12:30:33 startscene: scene=root.true, sceneName=root.true
        01/30/20 12:30:33 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        01/30/20 12:30:33 endscene: scene=root.true, sceneName=root.true
        01/30/20 12:30:33 condchange: newState=false, cond=condnhefvl6, oldState=true
        01/30/20 12:30:33 evalchange: newState=false, cond=condnhefvl6, oldState=true
        01/30/20 12:30:33 condchange: newState=false, cond=grpnhefe0b, oldState=true
        01/30/20 12:30:33 evalchange: newState=false, cond=grpnhefe0b, oldState=true
        01/30/20 12:30:33 condchange: newState=false, cond=root, oldState=true
        01/30/20 12:30:33 evalchange: newState=false, cond=root, oldState=true
        01/30/20 12:30:33 sensorstate: state=false
        01/30/20 12:31:27 devicewatch: device=212, old="9", name=Shade 1, var=urn:upnp-org:serviceId:Dimming1/ShadePreset, new="8"
        01/30/20 12:31:27 condchange: newState=true, cond=condnhefvl6, oldState=false
        01/30/20 12:31:27 evalchange: newState=true, cond=condnhefvl6, oldState=false
        01/30/20 12:31:27 condchange: newState=true, cond=grpnhefe0b, oldState=false
        01/30/20 12:31:27 evalchange: newState=true, cond=grpnhefe0b, oldState=false
        01/30/20 12:31:27 condchange: newState=true, cond=root, oldState=false
        01/30/20 12:31:27 evalchange: newState=true, cond=root, oldState=false
        01/30/20 12:31:27 sensorstate: state=true
        01/30/20 12:31:27 startscene: scene=root.true, sceneName=root.true
        01/30/20 12:31:27 runscene: scene=root.true, sceneName=root.true, group=1, notice=Starting scene group 1
        01/30/20 12:31:27 endscene: scene=root.true, sceneName=root.true
        01/30/20 12:31:27 condchange: newState=false, cond=condnhefvl6, oldState=true
        01/30/20 12:31:27 evalchange: newState=false, cond=condnhefvl6, oldState=true
        01/30/20 12:31:27 condchange: newState=false, cond=grpnhefe0b, oldState=true
        01/30/20 12:31:27 evalchange: newState=false, cond=grpnhefe0b, oldState=true
        01/30/20 12:31:27 condchange: newState=false, cond=root, oldState=true
        01/30/20 12:31:27 evalchange: newState=false, cond=root, oldState=true
        01/30/20 12:31:27 sensorstate: state=false
    Devices
        Lutron RadioRA2 Gateway (211) urn:schemas-micasaverde-com:device:LutronRA2Telnet:1 (0/-1); parent 0; plugin 5096
        Shade 1 (212) urn:schemas-micasaverde-com:device:WindowCovering:1 (8/0); parent 211; plugin -

Thank you, Mark

rigpapa · January 30, 2020, 11:42pm

You can do this without Lua in Reactor. You can either use an expression variable to get the state so you can send the opposite in a Device Action with SetTarget, or you can use a ToggleState action in a Device Action, no fetching of the state/expression needed. That would likely be faster still.

The first time a Reactor Run Lua action is run, the code is loaded and “compiled” (tokenized is probably a more accurate term). So if you’re comparing timing, run the activity twice. The second and subsequent runs are more typical of “real” timing.

MarkAgain · January 31, 2020, 12:15am

Thank you for the quick response. I’m just toggling the light as a test. In reality I would be running about 30 lines of code in place of the toggle. What I am asking is should I replace my Multstring triggers with Reactor triggers? Sorry I might not be explaining this very well.

Thank you, Mark

rigpapa · January 31, 2020, 12:51am

I think most Reactor users would agree that Reactor activities start faster more consistently than native scenes. Reactor activities survive interruptions like surprise reloads or power loss. Reactor has more logic options. Reactor is a current plugin with active support. And really, they are kind of apples and oranges. But at the end of the day, the best tool is the one you are most comfortable with that addresses your needs.

MarkAgain · January 31, 2020, 1:21am

Thank you for taking the time to answer my questions. I need to make more notes and save some code. Then I can get started on the adventure.

Thank you, Mark

system · March 31, 2020, 1:22am

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.