Expressions and LuaXP Functions
-
Excellent explanations, thank you! I will adapt my own uses to the new scaled dimming levels instead of trying to deal with them as integers like the old days. For the moment I cannot think of a pressing case in which integers would be required, but I dare say someone else will come up with one soon, so your idea of implementing set_percent might make sense in the long run.
I look forward to your full documentation of the "new" lexpjs language. Just let me know when you are ready for me to hammer very hard on that and assist with updating any documentation.
-
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/
-
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.
-
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.
-
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"
-
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:
MinTempchanges
Set Reaction:
- Set Variable: service=
urn:upnp-org:serviceId:TemperatureSensor1, variable=CurrentTemperature, value =${{MinTemp}}
- Temp1:
-
-
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
)Author of Multi-system Reactor and Reactor, DelayLight, Switchboard, and about a dozen other plugins that run on Vera and openLuup.
-
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
)@toggledbits Thanks, I missed that the variable expression has been changed.
-
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
-
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?
-
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 = 2listN = ["red","green","blue"]findIt = listN[idx] // returns "blue" -
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.)
-
Correct. Not yet in conditions.
-
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.
-
That's a datalist control. You don't have to pick what's on the list. You can enter whatever you want.
-
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?
-
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?
