Set Reaction > Script Action

[toggledbits]

Every build includes the day's doc updates, if any. Get to that from the "Manual" link in the left nav.

Work in progress on the docs is often visible at https://reactor.toggledbits.com/docs/

[LibraSun]

Roger that. Meanwhile, out here in the weeds responding to your earlier interest why I'd want to keep something like dimming values granular/integer... it's because I sometimes base triggers off of a device's exact brightness level (e.g. when dim = 50). So I'll have to modify my thinking for when dim = 0.50. Trivial.

Having digested the docs for LEXPJS (https://github.com/toggledbits/lexpjs/blob/master/lexp.js), I can simply rely on the 2-argument ROUND instead of the 1-argument FLOOR and be done with it.

I'll keep an eye on those Docs as you suggest. Thanks again.

[toggledbits]

If you're looking at lexpjs on Github, better to look at the develop branch these days... master has not been updated in quite a while.

[Matohl]

Started to play around with expressions in the MSR. Comparing two temperatur sensor and passing the lowest into a virtual sensor in Vera. It seems that the value in not passed to the virtual sensor or most probably I do something wrong. I have two similar rules, if Temp1<=Temp2 (shown below) and one if the Temp2<Temp1. I am not sure about the "Set Reaction"

[toggledbits]

The MSR variable/expression replacement is ${{ expression or variable name }}. Try that. I fixed at least one substitution bug today, but I'm not sure if it would intersect your use in the reaction. You've got a device type in your service field for the set variable action, and I'm not sure what your conditions are meant to do. I think what you mean to do is something more like this:

Expressions:

• Temp1: getEntity( "vera>device_86" ).attributes.value_sensor.value
• Temp2: getEntity( "vera>device_88" ).attributes.value_sensor.value
• MinTemp: min( Temp1, Temp2 )

Condition:

• Expression Value: MinTemp changes

Set Reaction:

• Set Variable: service=urn:upnp-org:serviceId:TemperatureSensor1, variable=CurrentTemperature, value = ${{MinTemp}}

[LibraSun]

Gotta ask: What precisely causes the field(s) background under 'Set Reaction' to turn yellow? For example, if I wrote {levelLamp} it's not yellow, but if I type ${levelLamp} or ${{levelLamp}} (as I knew the proper syntax to be) it turns yellow.

[toggledbits]

Yellow means it will accept the value but it may be out of range for the field. I suspect that's a side-effect of the bug I fixed. You'll need to wait for today's build before playing more (at least, if you want it to work )

[Matohl]

@toggledbits Thanks, I missed that the variable expression has been changed.

[LibraSun]

Ah-ha, I see that you went with zero-based array indexing in LEXPJS, versus the ol' one-based indexing enjoyed back in LuaXP. Gonna make my transition to MSR a bit more challenging as I transcribe my umpteen array-centric Reactor routines, but c'est la vie.

Glad I noticed this before getting to use the Backup/Restore approach, since I doubt it does (or can or even should) attempt an auto-translation of such things. In my case, being one-off on my table lookups could have meant setting the wrong House Mode, etc. Fun! LOL

[LibraSun]

Also, I'm noticing that if you define in Expressions:

obj = {ani:bird, typ:bard}

that, in order to access the value of "bard", instead of obj.typ (which returns {name:bard}), one must instead construct:

type = obj.typ.name // returns "bard"

Maybe that's normal? I had to really think about it as a non-programmer.

NOTE: In the process I also learned that the 'keys' of an object cannot be numbers; they must begin with a letter.

More importantly, I am already missing the array function CHOOSE -- can it be imported into LEXPJS?

[LibraSun]

I REALLY LOVE how you can now do the following array index references with minimal effort (and that this probably obviates the need for the CHOOSE function I mentioned above):

Expressions

idx = 2

listN = ["red","green","blue"]

findIt = listN[idx]  // returns "blue"

[LibraSun]

Even with the release of 21072, it seems we are still waiting for "substitutions" to become allowable within Expressions. Is this correct?

For example, rather than this disallowed comparison in Triggers:

[Expression Value]  [acMode]  [ <> ]  [ ${{houseMode}} ]

where acMode and houseMode are both defined expressions within that Rule...

I'm using this workaround:

[Expression Value] [ modesMatch ] [ is FALSE ]

for which I created the Boolean expression

modesMatch := ( acMode == houseMode )

Gets me where I need to be, just slightly less elegant. (For now.)

[toggledbits]

Correct. Not yet in conditions.

[LibraSun]

Good to know. Meanwhile, I'm profiting from variable substitutions working awesomely down in Reactions!

Although I bumped into a case you may not have fully considered? Namely, in a Rule designed to alter House Mode to match the current mode of my ecobee Thermostat, I cannot use substitution with your "House Mode" plug-in, since it only permits any of four preset options from a pick list.

That is to say:

[Entity Action]  [ House Mode ]  [ x_vera_housemode.set ]  [ <mode> ]

does not let me select the mode dynamically, based on a variable; it's hard-wired.

Instead, I'm forced (as I always was in RFL) to execute Lua code against Vera herself:

[Entity Action]  [ Vera Plus ]  [ x_vera_sys.runlua ]  [ luup.call_action( "urn:micasaverde-com:serviceId:HomeAutomationGateway1", "SetHouseMode", { Mode = ${{acModeNum}} }, 0 ) ]

I thought this would work, but it does not appear to be substituting for acModeNum in place, the way RFL used to do for, say. Reactor.Variables.acModeNum.

P.S. Alternatively, if you could surface Vera's and/or Reactor's "House Mode" action in the following manner, I could use it in the reaction:

[ Entity Action ] [ Vera | Reactor ] [ ...setHouseMode ] [ ${{acModeNum}} ]

Standing by for guidance, and hope you find this food for thought in later MSR revisions.

[toggledbits]

That's a datalist control. You don't have to pick what's on the list. You can enter whatever you want.

[LibraSun]

Thanks, my bad! Didn't even think to try that. Would have saved me like 45 minutes of poking around, lol.

[LibraSun]

Meanwhile, I seem to have dug another small hole in the VARIABLE SUBSTITUTION workflow, and it's been vexing me for over an hour. This action
keeps sending a literal

${{houseModeTxt}}

to its target, instead of the substituted value:

houseModeTxt := away (string)

Did not want to post this as a PR, since I think it's unique to me. Took me a while to even notice that Vera was throwing a bright blue error on her Dashboard, with the ecobee plugin complaining of being sent an out-of-range parameter (expects one of "home", "away", "sleep" or "smart1").

Thoughts? Am I having a fatal stroke here?

[toggledbits]

Have you looked in reactor.log to see if any errors are logged? Also, is this a global reaction, or rule-based? Is the variable global, or rule-based?

[LibraSun]

This post is deleted!

[LibraSun]

This yanked from the REACTOR.LOG, showing latest attempt:

2021-03-15T00:24:20.517Z <VeraController:null> VeraController#vera enqueue task for Entity#vera>device_97 action x_vera_svc_ecobee_com_Ecobee1.SetClimateHold: task { "HoldClimateRef": "${{houseModeTxt}}", "DeviceNum": "97", "id": "action", "serviceId": "urn:ecobee-com:serviceId:Ecobee1", "action": "SetClimateHold" }
2021-03-15T00:24:21.231Z <VeraController:ERR> [VeraController:performOnEntity] action request failed
2021-03-15T00:24:21.232Z <VeraController:CRIT> Error: Request failed: 501 Error
Error: Request failed: 501 Error
    at /opt/reactor/server/lib/Controller.js:445:37
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:94:5)