MSR UI on a mobile browser

[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)

[toggledbits]

OK, but before that.

[LibraSun]

This post is deleted!

[toggledbits]

A one-step play of an action will not do variable substitution. The variable substitution is only done by the Engine when running the full reaction.

[LibraSun]

Ah, I follow you, thanks. Will circle back to this issue (if legit) tomorrow. Was called away for several hours, in which time I've decided this workflow is not worth the complexity. I intend to replace it with simple IF A THEN B logic tomorrow.

[toggledbits]

I may have to re-route how that function works. Right now, it sends the request via the websocket to the WSAPI, which asks the entity to perform the action on itself. It will take a bit of plumbing, but I can probably redirect that process to the Engine, where the sub can take place. The trick is rule-based, because they set up context very differently from global, and the rule sets up context for the engine (so if I'm asking the engine to do something for the rule, the context hasn't been established... yeah, going to take some noodling...).

[LibraSun]

◄— this guy effed up
I was entirely mistaken about MSR not substituting variables correctly in my workflow. The problem, alas, was entirely of my own making (e.g. not grasping that running internal portions of a Rule manually would NOT invoke substitution(s) the way I had surmised). Secondly, I had crafted entirely too complex a workflow for a simple task; namely, instructing Vera to match the A/C "Mode" to the current House Mode, and vice versa.

My crazy construct involved arrays and indexes (to prevent illegal Mode values), lookup tables (to cross-reference integers (2) with words ("away")), time delays (to ward off bouncing/throttling), Global Expressions (to track device states and act as Triggers), boolean flags (to test parity and serve as a Constraint in Rules), etc., etc.

Think I'll stick with a simpler set of Rules, one for each case (Home on Vera ► Home on A/C; Away on A/C ► Away on Vera, etc.) and be done with it. MSR gives you so much more breathing room than the Vera environment, why not utilize it?

Sorry @rigpapa for the unnecessary back-and-forth above, and for not having the time required for ME to diagnose my own issue(s) last night.

[toggledbits]

Well, I think you hit on an important issue, which is that the "trial run" (of an individual action in a reaction) doesn't run in full context (the trial run of the full reaction, however, does). It may be that it can't (I can't imagine, it's really just a matter of if the squeeze is worth the juice), but I'm completely on board with the idea that it should. So I'll be looking into that today.

[LibraSun]

This post is deleted!

[toggledbits]

I honestly can't wrap my head around what you are telling me. It sounds as if you think the values home, away, etc. are different from the strings "home", "away", etc. and somehow that's a problem, but all parameters in Vera are strings, even the numbers. There is no such construct as a "keyword" and no non-string special values for home or away etc. If you want to send away to the Ecobee thermostat on the Vera, the only way to do it is by sending it a string.

It sounds to me like you need to (a) look at the MSR log to see what MSR is sending to the Vera, and (b) look at the Vera LuaUPnP log to see what is being received and what it's doing with it.

[LibraSun]

This post is deleted!