Using Nodon Soft Remote Button Values as Reactor Triggers

If you intend to use your Nodon Soft Remote to trigger Reactor routines directly, instead of (or in addition to!) assigning a “House Mode or Scene” to each button (under Soft Remote device’s “Select Scenes for Device Buttons” settings), then you will need to monitor two specific variables – sl_CentralScene & sl_CentralSceneAttr – watching for the values indicated below.

NOTE: I’ve created two lookup tables here, one for 7.0.29 firmware and another for 7.0.31, since the keypress values appear to have changed since the upgrade. (Likewise, the “Select Scenes” feature mentioned above has been expanded from 8 button assignments to 12, although the Soft Remote is supposedly capable of controlling up to 16 distinct scenes if you include ‘Release’ states, explained later.)

Each of the Soft Remote’s 4 buttons (let’s call them ‘Dot’, ‘Plus’, ‘Circle’, and ‘Minus’) generates 4 different pairs of keypress values, depending on whether you Single Tap, Double Tap, Long Hold, or Release it (this last type being the least documented and most difficult to reproduce). These value-pairs can then be used to trigger a Reactor routine based on the button pressed.


First, let’s summarize the values as transmitted by the remote.

‘SLC’ stands for the sl_CentralScene attribute
‘SLA’ stands for the sl_CentralSceneAttr attribute

(For use with Vera firmware >= 7.0.31)

KEY          PRESSED        SLC        SLA
Dot          Tap 1x          1          0
Dot          Tap 2x          2          3
Dot          Hold            3          2
Dot          Release*        1          1
Plus         Tap 1x          4          0
Plus         Tap 2x          5          3
Plus         Hold            6          2
Plus         Release*        2          1
Circle       Tap 1x          7          0
Circle       Tap 2x          8          3
Circle       Hold            9          2
Circle       Release*        3          1
Minus        Tap 1x         10          0
Minus        Tap 2x         11          3
Minus        Hold           12          2
Minus        Release*        4          1

*NOTE: ‘Release’ is equivalent to ‘long press then let go’.

(For use with Vera firmware <= 7.0.29)

KEY          PRESSED        SLC        SLA
Dot          Tap 1x          1          0
Dot          Tap 2x          2          3
Dot          Hold            1          2
Plus         Tap 1x          3          0
Plus         Tap 2x          4          3
Plus         Hold            2          2
Circle       Tap 1x          5          0
Circle       Tap 2x          6          3
Circle       Hold            3          2
Minus        Tap 1x          7          0
Minus        Tap 2x          8          3
Minus        Hold            4          1

I use these same values in the Reactor setup shown below – using a method (not entirely sanctioned or condoned by the creator of Reactor) that relies heavily on Expressions – to react to each keypress type. (Observe how with pre-.31 firmware it was impossible to distinguish which physical button had been pressed using only sl_CentralScene, since those values were not unique; whereas the later .31 revision smartly assigns the numbers 1-12 to the twelve most-used keypresses, greatly simplifying things.)

NOTE: Subsequent time trials reveals no appreciable difference in execution times between this “Expressions” approach versus testing the “Device States” within each subgroup. (See Reply #5, below)


Create a separate Reactor Sensor exclusively for use with your Nodon Soft Remote, due to the need for numerous Expression variables and Conditions, and for easier editing in the future.


This approach requires the following variables be assigned under Expressions, as follows, inside the Reactor Sensor you created:


SLC            :=   getstate( ###, "urn:micasaverde-com:serviceId:SceneController1", "sl_CentralScene" )

SLA            :=   getstate( ###, "urn:micasaverde-com:serviceId:SceneController1", "sl_CentralSceneAttr" )

where ### is the device number of your Soft Remote device.

VARIABLE          VALUE (for use with firmware 7.0.31 and later)

btnDot1x     :=   (SLC)==1 && (SLA)==0
btnDot2x     :=   (SLC)==2 && (SLA)==3
btnDotH      :=   (SLC)==3 && (SLA)==2
btnPlus1x    :=   (SLC)==4 && (SLA)==0
btnPlus2x    :=   (SLC)==5 && (SLA)==3
btnPlusH     :=   (SLC)==6 && (SLA)==2
btnCircle1x  :=   (SLC)==7 && (SLA)==0
btnCircle2x  :=   (SLC)==8 && (SLA)==3
btnCircleH   :=   (SLC)==9 && (SLA)==2
btnMinus1x   :=   (SLC)==10 && (SLA)==0
btnMinus2x   :=   (SLC)==11 && (SLA)==3
btnMinusH    :=   (SLC)==12 && (SLA)==2

After upgrading to firmware revision 7.0.31, you may also want to define the following four additional variables, which correspond to the ‘Release’ (that is, long hold and then let go) keypress type for each of the remote buttons.

VARIABLE          VALUE (for use with firmware 7.0.31 and later)

btnDotR      :=   (SLC)==1 && (SLA)==1
btnPlusR     :=   (SLC)==2 && (SLA)==1
btnCircleR   :=   (SLC)==3 && (SLA)==1
btnMinusR    :=   (SLC)==4 && (SLA)==1

WARNING! Apparently the Soft Remote does not consistently issue these last four values (for example, after long-holding and releasing the ‘Plus’ button, my remote sets the values SLC=6 / SLA=2 but never updates them to SLC=2 / SLA=1, so I cannot reliable trigger Reactor based on a btnPlusR event).

IMPORTANT — For Vera firmware 7.0.29, use the values below instead!

VARIABLE          VALUE (for use with firmware 7.0.29 and earlier)

btnDot1x     :=   (SLC)==1 && (SLA)==0
btnDot2x     :=   (SLC)==2 && (SLA)==3
btnDotH      :=   (SLC)==1 && (SLA)==2
btnPlus1x    :=   (SLC)==3 && (SLA)==0
btnPlus2x    :=   (SLC)==4 && (SLA)==3
btnPlusH     :=   (SLC)==2 && (SLA)==2
btnCircle1x  :=   (SLC)==5 && (SLA)==0
btnCircle2x  :=   (SLC)==6 && (SLA)==3
btnCircleH   :=   (SLC)==3 && (SLA)==2
btnMinus1x   :=   (SLC)==7 && (SLA)==0
btnMinus2x   :=   (SLC)==8 && (SLA)==3
btnMinusH    :=   (SLC)==4 && (SLA)==1

NOTE: Under 7.0.29, I was unable to identify any values for ‘Release’ keypress types.


Under Conditions, after changing the outermost sensor mode to NUL, begin creating 1-12 subgroups (one for each keypress type you would like to react to), and give them appropriate labels. Add two conditions within each subgroup, set to AND mode, as follows:

Subgroup 'Hold Circle Button'
[Expression Variable]   [btnCircleH]   [is TRUE]
[Device State]  [Soft Remote]  [sl_CentralScene]  [updates]

In this example, the Subgroup labeled ‘Hold Circle Button’ will be triggered when – you guessed it – the ‘Circle’ button is held on the Soft Remote.

Use the same setup consistently within the other subgroups. Profit!

Is there a saving in creating the expression, over just having two AND conditions in each sub group?

1 Like

No saving; quite the opposite. Expressions are parsed every time they are evaluated, so using expressions is a bit less efficient than using equivalent conditions; with this number of expressions, the differential is likely to be quite high, as the impact would be proportional to the number of expressions being evaluated. That said, what else does the Vera have to do? It probably still all goes by in a second or two on a mostly-idle system, so the practical impact is probably low. But where user feedback is concerned (i.e. user expects light to come on very quickly after button is pressed), I would always choose the fastest approach.

There is also no equivalent operator to updates in expressions, which is typically part of the pattern in testing scene controller buttons, so I’m betting that this approach isn’t able to detect consecutive re-presses of the same button in the cases where “SLA” is 0, and possibly others. It depends on how the variables transition in detecting press vs hold vs double-tap.

1 Like

Thank you good info to know.

Good eye, guys. I had neglected to include the third

[Device State]  [Soft Remote]  [sl_CentralScene]  [updates]

Condition within the subgroup. Have edited the OP accordingly.

As for why I prefer this “Expressions” method versus having dual “Device State” conditions in each subgroup, it’s because:

  • In case the value assignments ever change again, I only have to update them in the Expressions;
  • It’s easier for me to discern (or change) which button goes with each Condition;
  • I can also use the {btn} variables elsewhere, such as in Restrictions;

Hope this makes sense. As @rigpapa points out, the savings is not so much computational, but more about the user’s brainspace. :slight_smile:

UPDATE: I conducted a speed test to compare the time for each of the following subgroups to trip (i.e. become TRUE), and found their timestamps to be consistently identical (not to mention very fast, well within 1 second of actual button presses):

SUBGROUP 1 - ‘Device States Method’ (AND)
[device state] [soft remote] [sl_CentralScene] [updates]
[device state] [soft remote] [sl_CentralScene] [equals] [11]
[device state] [soft remote] [sl_CentralSceneAttr] [equals] [3]

SUBGROUP 2 - ‘Expressions Method’ (AND)
[device state] [soft remote] [sl_CentralScene] [updates]
[expression variable] [btnMinus2x] [is TRUE]

I should note, too, that it’s far easier for me to input copies of the latter subgroup type, since it involves fewer clicks of the mouse.

  • Libra
1 Like

Did you remove the expression from the dual AND condition test?

Also i don’t think you need to check updates in subgroup 1 , as the conditions will stay true till they change values.

Good question, and the answer is “No, I didn’t”, but since the response time was already within the same second that I pressed the remote button, there’d be no way to “clock” it any more precisely.

While testing, I would begin double-pressing the ‘Minus’ button at, say, 12:22:40 (according to Vera’s clock), then check the timestamp when [updates] went (false) in both subgroups. The result was consistently 12:22:41.

Retesting after deleting the three unneeded Expression variables, and Disable-ing the corresponding subgroup, changed nothing. Timing results remained the same.

And while it’s true what you say about the conditions persisting, I generally want to detect when the same button has been pressed a 2nd, 3rd, 4th, etc. time, which can only be accomplished using [updates].

1 Like

The LuaUPnP log file entries have milliseconds on their timestamps, so you can get a good feel for actual timing, if you’re interested. If you turn on debug, you also get more things to look at, at the expense of a little extra overhead, but I don’t think that overhead is significant enough to worry about, and if you’re doing side-by-side comparisons of approaches with debug on in both cases, it’s an apples-to-apples comparison anyway.

Okay, you made me stay inside even longer on this gorgeous Spring-like day to conduct further testing, and here’s what I discovered:


TRIAL 1 of 2

16:03:30.000 (began long pressing Circle button)
16:03:30.507 (device variable sl_CentralScene updates)
16:03:31.000 (activity complete, test light turned on)
            1.000 Total elapsed time (s)
TRIAL 2 of 2

16:15:50.000 (began long pressing Circle button)
16:15:50.562 (device variable sl_CentralScene updates)
16:15:51.533 (activity complete, test light turned on)
            1.533 Total elapsed time (s)

Average of 2 trials = 1.2665s per execution


TRIAL 1 of 2

16:26:50.000 (began long pressing Circle button)
16:26:50.572 (device variable sl_CentralScene updates)
16:26:51.373 (activity complete, test light turned on)
            1.373 Total elapsed time (s)
TRIAL 2 of 2

16:30:40.000 (began long pressing Circle button)
16:30:40.384 (device variable sl_CentralScene updates)
16:30:40.931 (activity complete, test light turned on)
            0.931 Total elapsed time (s)

Average of 2 trials = 1.152s per execution


It just doesn’t matter! (or… maybe ol’ @LibraSun’s way is faster??)


Brand new Reactor sensor containing only one Conditions subgroup at a time. Per earlier discussion, Method 1 had no Expressions set, while Method 2 required 3 Expressions. No remote buttons were pressed between trials, nor was any other Vera action initiated.

All times derived from active luaUPnP log. Any trials interrupted by system delays were scrapped. No animals were harmed during testing.

1 Like

The 3.6 stable branch release has sensor update timing with millisecond resolution published to the Logic Summary events log now, if you’d like to try that. That will eliminate a lot of variables from the tests and concentrate the timing a bit more into measuring the difference in evaluation processing of the two methods. The catch that remains is scheduling the light change (i.e. calling the Luup action to turn on the light), which isn’t deterministic, but I think a sufficient number of attempts should boil enough of that out to make it safely ignorable.

Oh, and I also made another change to make it even faster in some cases… (applies to all evaluation methods, so still apples-to-apples).

One more thing–the first eval is always expected to take longer. And, you should restart the sensor before doing the first eval (restarting actually will do the first eval–just discard that result).


No Sun for @LibraSun then!

1 Like