Before installing, here is what you need to know and do:
Please make sure you are currently running Reactor 2.5.
Make a backup of your current Reactor configuration. Use the Backup/Restore tab in your Reactor master device to make a backup. There’s also a link to download the backup file so you can store it locally, and I strongly encourage this practice. Version 3.0 configurations are not backward compatible with 2.x, so while 3.0 will automatically upgrade your configs to the new format, but if you later choose to downgrade back to 2.x, you will need to restore the backup you made above.
Please report any issues as replies on this topic only!
The big new feature in 3.0 is that condition groups are now a user-configurable tree (hierarchy), and each group can now have its logic operation (AND/OR/XOR) determined by the user as required. Aside from adding considerable flexibility to the logic, it eliminates (in most cases) the need to create separate ReactorSensors for different parts of the same logic project. It goes further, in fact, to allow users to create modular, reusable logic blocks that can be used within a ReactorSensor or across many ReactorSensors. This version also allows the creation of activities on a per-group/per-state basis, meaning each logic group can separately control a set of devices, rather than having the trip/untrip state of the ReactorSensor be the only place where actions are run.
Enhancement: Condition groups are now a hierarchical construct, and group logic is user-settable (AND/OR/XOR/NUL + 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: New “Group State” condition allows the user to condition upon the state of another group in the same or another ReactorSensor.
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: It is now possible to copy the contents of one activity to another.
Enhancement: POSSIBLE BREAKING CHANGE FOR SOME USERS As of this version, the evaluation order of expressions is explicitly sequential. Previously, the order was system-determined. By going to 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: Loading of action data from Vera now retries automatically–improves remote user experience.
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 that 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.
Installation Instructions (Vera)
Again, make sure you currently have Reactor 2.5 installed before installing 3.0 Beta. If not, install it first (via the App > Install apps menu).
Click the green “Clone or download” button and choose “Download ZIP”. Save the file.
Unzip the downloaded file.
Upload each of the unzipped files to your Vera using the uploader at Apps > Develop apps > Luup files. You can drag/drop them as a group; if you upload them individually, make sure you turn off the “Restart Luup after upload” checkbox and keep it off until you get to the last file–turn it back on before uploading the last file.
Do a hard refresh on your browser (CTRL-F5 for Chrome/Win, SHIFT-F5 for Firefox/Win, CMD+SHIFT+R for Macintosh).
This is excellent. Uniqueness concerns aside, it would be helpful if the intra-sensor condition group references used the user-defined names instead of the Reactor-generated/internal guids.
If the group IDs are leaking somewhere other than the Logic Summary (where it’s intentional), let me know, because that’s not user-friendly and I’ll fix it. At least, the group ID should not appear without the group name preceding it (e.g. “My Group Name <grp123456>”).
Also make sure you’ve set the group name, as the default name is the ID.
Oh… use a Group State condition rather than Device State and going after the Reactor implementation variable by name. I smoothed that out early on… 19083…
They should. It was not an area where we had any trouble at all in the beta. Just make sure you back up your configs on 2.x, and download and save them off-Vera (extra protection), before upgrading to 3.0. The process of going back to 2.x, if you need to, would be:
Reinstall 2.4 or 2.5 from Vera Plugin Marketplace, AltAppStore, or directly. Ignore the status of the ReactorSensors at this point.
Go to the “Backup and Restore” tab in the Reactor master device;
Select “ALL” for the source configs and “To device with matching name” as the target, and hit “Begin Restore”. This will restore the 2.x configs and restart each ReactorSensor, and they should immediately begin working.
These steps should take you less than five minutes, if you can fend her off that long. Mine responds well to a well-made Cosmopolitan, which buys me time.
@rigpapa, another 3.x question… Why aren’t Device State variables such as LoadLevelTarget, LoadLevelLast, etc. numeric operands enabling numeric comparison operators such as > ? Currently, the UI presents an error if you try to perform a numeric comparison on these variables.
As an aside, for those who are beta testing 3.0 - if you find that all your sensors have changed to “Can’t Detect Device” then your Vera has downgraded your Reactor plugin to the latest 2.x store version and you will need to reinstall the 3.0 beta. This has happened to me twice, once during the private beta and once today during the public beta.
I need you to more specifically clarify what you mean here, because as I read it as written, if I go write a device action condition against LoadLevelStatus on a dimmer, it allows me to choose any of the magnitude comparison operators (<, <=, >, >= are present in the menu and not disabled), and when I choose one of them it allows me to enter a numeric operand. It only gives me an error if I enter a non-numeric operand when a numeric/magnitude comparison operator is selected (which is correct behavior). Help me reproduce your results.
Ah, my bad. I never got past picking different operators from the popup - some operators presented errors, some didn’t. The trade-off between real-time validation and validation on save I guess. I realize no value is an error but it might be more intuitive if the “first” error check is deferred until the user enters a value other than the default (i.e. completes the initial definition by changing all default values in the condition).
This really only comes into play when new users create new conditions - i.e. once people get used to the UI and understand how it works, they’ll know what to do
Yeah, it is kind of a usability nit and not worth risking release stability.
That said, IMHO 3.0 is a huge leap forward to what was an already very powerful logic plugin and has been working great on my production Vera Plus running the Vera 1444 beta firmware. Thanks again for creating and supporting Reactor.
I’d like to commend you again for you work on this plugin, it is IMHO the biggest improvement to the VERA for as long as i’ve had one.
Can’t wait for the 3.0 updates. I considered doing beta testing, but as I only have one, and reactor practically runs all of it, it would be too big of a risk in terms of WAF.
+1 from me too - I almost bought a HomeSeer HAC but Reactor made my Vera actually useful!
I actually bought and paid for PLEG but, to be blunt, it’s a total UEX charlie foxtrot and I dont understand how anyone gets it to do anything useful! (and Im an IT guy who runs servers at home for fun)
I haven’t tried 3.0 yet either - my Wife would kill me if I broke our current setup!
Hey Patrick! Just wanted to say what an awesome job on Reactor Beta 3.0 you’ve done, I echo previous comments saying this is a huge leap forward on logic control, and love the ability to have logic groups trigger an activity (or activities) vs solely relying on the tripped or untripped state of a sensor.
The sub groups and ability to assign OR/XOR/AND to a group is also simplifying some of my logic, particularly where 1 condition needed to apply as an AND to to any one in a condition in a subgroup (OR)
