Reactor 3.0 Release

rigpapa · May 5, 2019, 3:46pm

Everyone:

I will be releasing Reactor 3.0 today to the Vera App/Plugin Marketplace (expected availability tomorrow Monday 5/6/19; it will continue to be Beta on openLuup, as I still have some testing to complete there). This release has been the product of over six months of work, including contributions by many volunteer beta testers and early adopters, both on these forums and off, to whom I am truly grateful.

Reactor 3.0 takes its condition logic to the next step, a step I have planned since its original version. Before 3.0, you could only create Reactor condition groups at the “root” (top) level–it was flat, and there were no subgroups. Reactor 3.0 changes the model to a hierarchy of groups. It also removes the limitation that the groups be constrained to “AND” logic (where all conditions must be met for the group to be true) and the “OR” logic being at the ReactorSensor’s top/root level. Now, you can assign the logic operation for each group. Additionally, each group can have its own set of activities (actions it performs when it becomes true or false).

The combination of these important changes in the model makes Reactor’s conditional logic capability powerful with sacrificing ease of use. In fact, it enhances ease of use by removing logical restrictions that previously would require you to use two or more ReactorSensors for one task.

A side-effect of this is that, with some care in your approach, your system logic can be made modular. It is now possible, for example, to create a condition group within a ReactorSensor, and have the state of that condition group be an input to another condition group in the same ReactorSensor or any other ReactorSensor. This means you can reuse pieces of logic without duplicating the logic element itself, and by so doing, if your devices change or you need to tweak the logic, the changes are effective across all other logic that uses the reusable condition group. (If your eyes are glazing over at this point, don’t worry, I’m going to start making YouTube videos to explain all of this.)

Reactor 3.0 will automatically load and upgrade all of your configurations to the new form. It will also back up your 2.x configuration automatically. But, of course, I urge you to make your own backup as soon as possible. All features of 2.x are upward compatible. The upgrade will not change your group structure, but once on 3.0, you can begin changing your group structure using its new capabilities any time you wish. The only thing you will most certainly need to do is a hard-refresh of your browser, which (as many of you know) I always recommend and think we Vera-ites don’t do often enough.

There are some changes specifically in the way that expression/variables are evaluated and the results stored that may cause breaking for some users. However, I believe that few users use this feature as yet, and those that do that would intercept a breaking change will be small in number–and I’ll be right here to help them get it sorted as quickly as possible. Sometimes to take things forward, they just have to change.

Reactor 3.0 also introduces a number of other new features to further extend its reach and power. Here’s the full CHANGELOG for the release:

Enhancement: The device-defined conditions normally seen in the Vera scene editor are now offered as shortcuts for creating conditions;
Enhancement: Loading of action data from Vera now retries automatically–improves remote user experience.
Enhancement: New “Delay reset” option allows false state of condition to be delayed by the specified number of seconds (this can be used to debounce device states, or as an “off” delay for motion sensing, for example) [issue #16];
Enhancement: Activities are now collapsable, and since the number of activities is equal to the number of groups plus two, it’s possible to hide unused groups as well (this is a persistent state/choice that operates plugin-wide) [issue#24];
Enhancement: New “Group State” condition allows the user to condition upon the state of another group in the same or another ReactorSensor.
Enhancement: Reporting of errors (such as reference to a device or scene that no longer exists) in conditions and activities is improved through the use of the (notification-capable) Trouble state variable. Related diagnostic information is written to the Logic Summary events list. A new icon with a yellow warning triangle superimposed calls attention to ReactorSensors reporting trouble.
Enhancement: The new expression function trouble( msg [, title] ) has been added to allow expressions to signal trouble for any purpose. The msg argument is written to the Logic Summary event list, along with the optional title. The default title is simply “trouble()”.
Enhancement: The finddevice() expression function now takes an optional second boolean argument that determines if an error is thrown (and thus trouble is reported) if the referenced device is not found. If not provided or false, null is returned (the legacy behavior); if true, an eval error is thrown and trouble is signalled.
Enhancement: The getstate() expression function now takes an option fourth boolean argument that determines if an error is thrown (and trouble is reported) if the referenced device is not found. If not provided or true, an error is thrown and trouble is signalled (the legacy behavior); if false, null is returned.

Note: The default legacy behaviors (i.e. when the new optional argument is not provided) described above for getstate() and finddevice() are different; this is intentional and consistent with their operation prior to this enhancement (so the behavior of existing expressions does not change). The new argument is, however, consistent, in that when a device cannot be found and true has been explicitly passed, an error will be thrown and trouble signalled by both functions, or if false is passed, null will be returned by both functions.
Enhancement: The status display now highlights errors and changed values.
Enhancement: The expressions editor now shows the most recent sensor evaluation result for each expression.
Enhancement: POSSIBLE BREAKING CHANGE As of this version, the evaluation order of expressions is explicitly sequential. Previously, the order was system-determined (to the user, basically random). By going to deterministic, sequential evaluation, it is possible for variable to store the previous value of another (e.g. by the expression “OldVal=Val” preceding the expression/calculation of “Val”). In addition, the values stored in state variables are no longer the primary values used in evaluations. Now, the actual returned values from LuaXP are stored on the ReactorSensor state and saved between sensor updates, and across restarts and reboots (that is, they are now persistent).
Enhancement: Condition groups are now a hierarchical construct, and group logic is user-settable (AND/OR/XOR + NOT). This adds considerable flexibility to the condition logic for users, at the expense of some complexity in the UI (implementation/operation is not significantly different).
Enhancement: Users may now create Activities for each condition group, not just the over trip/untrip of the sensor.
Enhancement: It is now possible to copy the contents of one activity to another.