Run rule on dimmer change?

[toggledbits]

Since the project is evolving, there will always be something somewhere that is being deprecated, so I thought it might be handy to have a list. I'll try to keep this post up-to-date:

• The list() function in expressions; remains for portability from Reactor for Vera. Replacement is [ item, item, ... ] syntax (direct array declaration).
• The Interval condition in relative to condition TRUE mode. On Reactor for Vera, this functionality has long been supplanted by the pulse output mode (under Condition Options). But, I neglected to formally deprecate that feature in Reactor for Vera (so far; I will for 3.9). It is officially deprecated in MSR, and remains only for portability of rules imported from Reactor.

Note: all deprecated features will be removed from a future release, so the intent is that this list motivates action on your part to replace any use of the deprecated feature with its replacement. The date at which any function is finally removed will be published once scheduled; if no date is posted, the feature is deprecated, but will remain and a date will be planned later.

[LibraSun]

Would I be correct in mentioning that:

lookup( list , index )

is also being replaced by:

array[ index ]

[toggledbits]

Hmmm.... there is no lookup() function in LuaXP or Reactor for Vera. Array member access syntax is the same for both Reactor for Vera (LuaXP) and MSR (lexpjs): array[ index ].

[LibraSun]

Wow, you're right. I think Daylight Savings Time brain fog had me thinking of Google Sheets formulae, lol! Probably meant CHOOSE( ) for picking indexed item from a list.

Delete!!

[toggledbits]

Ah, yes, OK... that's very different in lexpjs/MSR: first item in array-of-objects with match-expression

rain=[ { date: 1234, rainfall: 10 }, { date: 4567, rainfall: 11 } ], 
first entry in rain with entry.rainfall > 10

would return { date: 4567, rainfall: 11 }

Another possibility would be each entry in rain: entry.rainfall > 10 ? entry : null which would return an array of all matching entries.

Clarification:

each ... in ...: ... is an iterator; it loops over each member of the given object, performing the given expression; an array of result values is constructed, but nulls are not put in the array.

first ... in ... with ... is a search; it works similar to each but stops at the first thing where the expression result is "truthy" (boolean true or can be coerced to that).

Both work on arrays or objects/dictionaries.

[LibraSun]

UPDATE: The advice shown below is NOT required as of Build 21074+ of MSR.

In furtherance of the first..in..with construct, let me forewarn users that the non-optional boolean-expression may require parentheses. For example, working off the following object (defined in Expressions):

houseModes := {home:{hm:1,ac:"home"},away:{hm:2,ac:"away"},sleep:{hm:3,ac:"sleep"},smart1:{hm:4,ac:"smart1"}}

you would look up the first element matching a value of 1 in key 'hm' using:

first mode in houseModes with (mode.hm == 1)   // trailing boolean grouped
// returns array or object

Without this encapsulation, the entire statement may be evaluated as a boolean, resulting in a trival always-false condition:

first mode in houseModes with mode.hm == 1   // boolean ungrouped
// always returns boolean value of FALSE (since null !== 1)

Likewise, if you wish to reference a nested key within the resulting object, another outer set of parentheses would be required, as follows:

(first mode in houseModes with (mode.hm == 1)).ac 
// returns "home"

which, in turn, is functionally equivalent to:

first mode in houseModes with (mode.hm == 1) ? mode.ac : "no match"
// returns "home" since 1st object matched expression

This latter formulation is likely preferred since it handles null situations more gracefully:

first mode in houseModes with (mode.hm == 5) ? mode.ac : "no match"
// returns "no match" (string) since test yielded (null)

(edited)

[toggledbits]

I'm not getting this example. Maybe shows the value for hM as well, so we can see what's being tested?

[LibraSun]

I just amended the example above for clarity.

[toggledbits]

I see. That's just a precedence issue, confirmed. I can fix that easily.

[kfxo]

@toggledbits Should prob add Reset Latch. From the Manual:

"Reactor for Vera offered a variety of ways to unlatch a condition, but this was often abused and caused more problems and confusion than it was worth. MSR only unlatches conditions under the conditions described above, and the Reset Latch action is not available."

[LibraSun]

NOTE TO @toggledbits the official docs (e.g. http://[MSR_IP]/docs/Expressions-%26-Variables/#expression-language-syntax) reference FIRST .. OF .. WITH (instead of IN), leaving me scratching my head as to which is the correct syntax.
EDIT: The correct keyword is 'in', not 'of'.

[toggledbits]

Fixed in 21307 docs. Could/should have been in Mantis?

[LibraSun]

@toggledbits said in Deprecated Features:

Fixed in 21307 docs. Could/should have been in Mantis?

Technically yes, it was among the very 1st three things I reported to you, but as "notes" in Github rather than Mantis (which wasn't yet on my radar at the time). Thanks!