Home

Welcome to the Reactor wiki!

Reactor is a plugin for Vera Home Automation systems that addresses the shortcomings in the built-in logic for triggering scenes and events, adding powerful, user-configurable logic to drive automation.

What Can I Do with Reactor?

If you've ever wanted to do something with Vera/Luup where it's "if this is on and that's off and this sensor is tripped and that device is in this condition", then Reactor is for you. In particular, any time the word "and" appears in the conditions for an automation you are trying to set up, you may need Reactor.

Here are some examples of things you can do with Reactor (many of which would be difficult to do reliably or at all with Vera scenes and device triggers alone):

• Send a notification when the garage door is left open for more than 15 minutes between 10pm and 8am;
• Turn off outdoor lights at 11pm, unless your house is in "Party Mode" (as set by a VirtualSwitch you created);
• Reboot your Vera at 5am every Sunday;
• Temporarily run air conditioning if the humidity in your house exceeds 55%;
• Close the blinds and turn off your pool equipment if the current weather is "lightning";
• Put your Nest thermostat in "Home" mode when your house mode is "Away" but your caretaker uses their lock code to open the front door, and then later return the Nest to "Away" mode.
• Operation
• Reactor is the parent of a set of a ReactorSensors. Each ReactorSensor contains a set of logic conditions that when met, cause the sensor to trip (so, a ReactorSensor implements the SecuritySensor1 semantics). When the conditions are not met, the sensor is untripped. This basic binary output can be used to trigger scenes and other logic, even PLEG.

Reactor itself is a single-instance plugin, meaning all ReactorSensors in the system run from a single copy of the Reactor code, making it light on system resources even for large numbers of sensors and logic conditions.

Configuration

To read about creating and configuring ReactorSensors, click here.

Other Features

ReactorSensors, like any SecuritySensor1 device, keep a LastTrip variable (in service urn:micasaverde-com:serviceId:SecuritySensor1) which records the time that the sensor was last tripped. In addition, it keeps a LastReset variable (in service urn:toggledbits-com:serviceId:ReactorSensor) with the time at which the sensor was last reset (untripped).

They also keep a Runtime variable (in service urn:toggledbits-com:serviceId:ReactorSensor) which accumulates the total time (in seconds) that the sensor has been tripped. So, for example, if you created a ReactorSensor that tripped whenever your thermostat was heating or fan was running, you could easily get the runtime over a period to help cue filter changes or other maintenance. The runtime can be reset by directly writing a 0 to this variable in Lua, or using the ResetRuntime action (no parameters) in service urn:toggledbits-com:serviceId:ReactorSensor.

Reacting to Reactors Externally

ReactorSensors can be used in conditions by other ReactorSensors. Caution should be used, however, to avoid creating "loops" where two ReactorSensors alternately trip and untrip each other at machine speed. Reactor has built-in rate limiting of both the update frequency and trip-change rate, and will throttle the sensor if either rate exceeds set thresholds (default 30 updates or 5 tripped state changes per minute; configurable via direct variable access).