Reactor ver 1.5 Stable/Pre-Release

OK. The news of Vera/MiOS has clearly created a lot of distractions, and some very exciting discussion about what may be to come, but for the foreseeable future we still have to live with the hardware and software we’ve got, good, bad and otherwise, so I of course will continue to press forward delivering what I hope are useful features. And as I’ve said, hopefully some day, Vera will do an amazing job of its own scene logic and Reactor can quietly ride off into the sunset.

The current stable pre-release of Reactor has been updated and is installable from the AltAppStore directly, or from the stable branch on Github (for convenience, download the stable release ZIP file); see the README.md file for installation instructions.

New stuff:

First, Reactor will now run scenes directly. It is no longer necessary to use a device trigger on your scene that watches your ReactorSensor. There is a new “Activities” tab in ReactorSensor configuration that allows you to specify a “Trip” scene, and an “Untrip” scene. Reactor will run these scenes when the associated ReactorSensor becomes tripped or untripped, respectively. If you decide to let Reactor run the scenes itself (and I think you will when you’ve finished reading this), you should/must turn off your device triggers in the scenes used by Reactor, otherwise the scenes will be run twice (once for the scene’s native trigger, and again when Reactor runs it). Scenes used in the Activities tab should always use “Manual” triggering in the scene definition.

Second and more exciting, in my opinion, is HOW Reactor runs scenes when you let it. Reactor doesn’t simply call Vera’s [tt]RunScene[/tt] action, it runs the scene entirely itself, step by step, including any scene Lua that you’ve defined (and that works the same way–if your scene Lua returns false, the scene activities aren’t run, otherwise they run).

The most important benefit of Reactor’s scene runner is that scenes survive restarts of Luup for delayed activity groups. We all know too well that, normally, if a scene has a delayed activity group, and Luup reloads for some reason during the delay period, the timing is lost and the delayed actions never run. So since the earliest days of Vera, it’s been a frustration that a simple “turn the light off in five minutes” scene could never work reliably (at least, not without adding considerable complexity to help).

When Reactor runs the scene, however, the scene elements are scheduled and execution tracked by Reactor’s internal task scheduling. If Luup restarts, Reactor will simply resume running any scenes that were running prior to the event from where they left off, until all activity groups in the scene have completed. If a group’s scheduled time passes during the event, Reactor will run the “late” actions immediately on restart, in correct schedule order, and then all remaining activity groups will be run on time relative to the original start time of the scene. That is, if the delay for a group is 10 minutes, that means it will run 10 minutes from when the scene originally was started, on schedule, as if the reload interruption never occurred.

This improved scene runner is available to all scenes on your Vera when you have Reactor installed, including scenes you run from your own custom Lua or PLEG actions. Here’s how you use it:

[ul][li]For existing scenes that are triggered by device triggers or schedules on the scene itself, move those trigger conditions into a ReactorSensor, then remove the triggers from the scene, and configure Reactor to run the scene (on the Activities tab);[/li]
[li]For PLEG actions, use Reactor’s “RunScene” action instead of PLEG’s–select the Reactor (master) device, and choose the “RunScene” action and enter the scene number or name;[/li]
[li]In your custom Lua, just use [tt]luup.call_action( “urn:toggledbits-com:serviceId:Reactor”, “RunScene”, { SceneNum=string-or-number }, reactorDeviceNum )[/tt]. The “SceneNum” parameter takes a scene number or scene name.[/li][/ul]

An additional feature of Reactor’s scene runner is that you can stop a running scene. There is a “StopScene” action in the Reactor service that allows you to stop a single specified scene if it is running, or stop all scenes that Reactor is running (specificy SceneNum=0). This is also accessible from PLEG and your own Lua.

Finally, this version has some big improvements to the scheduling of most time/date-based conditions, to further reduce load on the Vera.

I plan on releasing this version in the Vera Plugin Marketplace over the weekend for access there on Monday. Until then, if you want to try this stuff out, Github is the way to go.

thanks again so much for this amazing plugin

reactor and delay light are huge life savers
they have removed the need for so many other apps and scenes
so much has been simplified
my controller runs so much more efficiently because of these 2 apps

not only are your apps great, you continue to improve them
i certainly hope you never abandon this platform

I’ve been trying to figure out a way to change my Reactor scene to have a longer timeout if the light is turned on manually. Is there a way to do that?

I attached my current On/Off Reactor.

Thanks!

That ends up being a subtly complicated problem, and I would recommend you use DelayLight with Reactor to solve it more simply. Use your “on” ReactorSensor as the “trigger” device for DelayLight. Put your lights in DelayLight’s “on” and “off” lists. Set the Auto and Manual delay times as desired. You should not need the “off” sensor any more as DelayLight handles the timing and turn-off.

Although you could make Reactor do all the work by “seeing” the light coming on and treating it as a manual start, your automatic timing also turns on the light, so Reactor would “see” the light coming on then also. DelayLight has built-in logic to recognize when a light is turning on due to the automatic trigger vs manual turn-on of the light (anything other than the automatic trigger), and know which timing delay to use.

Rigpapa, is Reactor UI5 compatible (1.4)?

Used PLEG for years (Great App) but struggled with it. Started to use Reactor last month and have been able to do things that I have not been able to get correct in PLEG, (endingstrife) such as the long manual light & door open 1 trigger for light. Nice to have the doors open without the yard light being on all the time.

The 1.5 version of Reactor posted yesterday, with the features mentioned in my prior post here (scene runner, primarily).

One of the new features specifically for VeraSecure is that it checks the AC/DC operating state of the system, and the system battery level. Since I don’t have a Secure yet (and Vera apparently isn’t offering the developer discount on them, so they’re pricey), I relied on help from another member (thank you @wilme2) to find the necessary tools and their responses for that implementation, but I need someone to test it live. If you have a Secure, you should have two state variables on the Reactor master device: SystemPowerSource and SystemBatteryLevel. You can use them in ReactorSensor conditions by using a “service” condition, selecting the Reactor master device, and then those variables. The SystemPowerSource is best checked with a “starts with” condition, testing against the strings “DC” (for utility power) or “Battery” (for loss of utility/on battery). The SystemBatteryLevel is simply a percentage (0-100).

If someone with a Secure could give these a look and get back to me, I’d appreciate it.

I’m currently replacing the combination switch with reactor, and i noticed something in the following setup:

I have a double lightswitch in the kitchen, one is for turning all lights on/off (5 units), and the other is for switching light modes. this second switch(on the same unit) is a regular on/off switch, which i use as an impulse switch by turning it off within the scene.

When all lights are on, I have a reactor that looks at:
Impulse switch =1
All Lights on=1
Ceiling light=1

When that’s tripped, a scene firstly turns Impulse Switch=0, then turns ceiling light=0.

Then I have a second reactor that looks at:
Impulse Switch = 1
All Lights on = 1
Ceiling Light = 0

When that is tripped, Impulse switch = 0, then ceiling light = 1.

This gives me a note that one reactor is “throttled!” (good function by the way), but why? Isn’t the scene details run in sequence? and if so, aren’t they time stamped?

I tried to add a second delay between impulse switch =0 and ceiling light = 1, didn’t help…

This setup worked OK with the combination switch plugin, not perfect though, didn’t fire every time…

Edit: The 1 second delay makes it work, but the “Throttled!” message still appears some times. And i would really like to remove that second of lag…

[quote=“Forzaalfa, post:8, topic:199805”]I’m currently replacing the combination switch with reactor, and i noticed something in the following setup:

I have a double lightswitch in the kitchen, one is for turning all lights on/off (5 units), and the other is for switching light modes. this second switch(on the same unit) is a regular on/off switch, which i use as an impulse switch by turning it off within the scene.

When all lights are on, I have a reactor that looks at:
Impulse switch =1
All Lights on=1
Ceiling light=1

When that’s tripped, a scene firstly turns Impulse Switch=0, then turns ceiling light=0.

Then I have a second reactor that looks at:
Impulse Switch = 1
All Lights on = 1
Ceiling Light = 0

When that is tripped, Impulse switch = 0, then ceiling light = 1.

This gives me a note that one reactor is “throttled!” (good function by the way), but why? Isn’t the scene details run in sequence? and if so, aren’t they time stamped?

I tried to add a second delay between impulse switch =0 and ceiling light = 1, didn’t help…

This setup worked OK with the combination switch plugin, not perfect though, didn’t fire every time…

Edit: The 1 second delay makes it work, but the “Throttled!” message still appears some times. And i would really like to remove that second of lag…[/quote]

So, is “ceiling light” the first switch (controlling the 5 units)? And where does “All lights on” come from?

Before doing a bunch of work to figure this out, how many times were you mashing the switches? The default change rate (number of times a ReactorSensor is allowed to change state before throttling) is just 5 times per minute, which I could readily see isn’t much if you’re playing with the switches to see if they work (basically, three attempts of your configuration within a minute will trigger throttling, so I’m betting this is it). If the throttle message on the ReactorSensor says “high change rate”, try moving the MaxChangeRate state variable higher. It could just be that you’re hitting my rather conservative default; I do this myself in testing all the time. The other throttle metric, MaxUpdateRate, is the number of device changes allowed per minute, which is 30 by default. You may want to move that one up as well.

If that doesn’t address it, open the control panel of one of your ReactorSensors and go the Test page. Then, go play with your switches and break it again (get Reactor to throttle). As soon as you break it, hit the “Plugin Status” link on the Test page, and PM me (or email, address on my profile) the entirety of the output. Reactor logs all of the state transitions, so I should be able to see, step by step, what was happening. We’ll go from there.

You’re right offcourse. :smiley:

I upped the two variables, and removed the 1 second delay in the scene. It works!

I’m not making disco lights here, so a restriction on how often it switches is no problem.

to clarify the example; “All Lights” is a switch for all 5 units, and the “Ceiling light” is the only one i’m turning off with reactor.
“All Lights” stay on as long as any of the lights are lit, in order to be able to turn them off with the “All Lights” wall switch.

[quote=“Forzaalfa, post:10, topic:199805”]You’re right offcourse. :smiley:

I upped the two variables, and removed the 1 second delay in the scene. It works!

I’m not making disco lights here, so a restriction on how often it switches is no problem.

to clarify the example; “All Lights” is a switch for all 5 units, and the “Ceiling light” is the only one i’m turning off with reactor.
“All Lights” stay on as long as any of the lights are lit, in order to be able to turn them off with the “All Lights” wall switch.[/quote]

Cool! I love it when it’s the simple answer! :slight_smile: What double switch are you using?

NEXA 605 433mhz through RFXtrx…

My next challenge is to add a second switch to my hallway light. In essence, it needs to be syncronized with the switch that is assciated to the light directly.

A forest of scenes and stuff would perhaps do it, can’t see a more elegant way…

It may not be Reactor related, so if anyone gets a lightbulb idea, send a PM! :slight_smile:

Is it not just sufficient to have a second switch simply toggle the state of the master switch?

Sure, but in order to turn on with one and off with another, they have to have the same state all the time…
If RFX plugin could indentify the NEXAs as 4 impuls switches this would be easy, but now they are on/off, and will not respond to Off if it is Off.

That’s one reason I changed to impulse switched most everywhere.

However, for your problem, it’s possible to use a regular switch (with a Zwave module) as a scene trigger (for any change of state) which then toggles the master switch?

I’ve done this in several places where the wiring would otherwise have been difficult.

I use Imperihome for my automation interface. It allows me to combine VeraPlus & other tools in one consistant view.
I use reactor to give a warning when a combination of devices are failing and visualise this in a virtual device. In the Vera interface is everithing ok, but reactor is not recognized as a device in Imperihome, so it is invisible.

[quote=“lvancauw, post:16, topic:199805”]I use Imperihome for my automation interface. It allows me to combine VeraPlus & other tools in one consistant view.
I use reactor to give a warning when a combination of devices are failing and visualise this in a virtual device. In the Vera interface is everithing ok, but reactor is not recognized as a device in Imperihome, so it is invisible.[/quote]

Most plugins do not show up in ImperiHome. Like Vera’s own mobile apps for Android and iOS, ImperiHome does not take full advantage of the information available to it to determine the nature of a device when choosing an interface to present to its user. This is an unfortunate shortcoming of an otherwise very useful and attractive app.

That said, I have with other plugins of mine abused ImperiHome’s ISS integration interface as a workaround, which is intended for integrating entire automation systems, not just a handful of devices in a system it already supports. This is an extremely inefficient way of getting the job done, in that it works to some degree, but it requires each plugin to implement and support special code just for ImperiHome, and a special setup process by the user, and despite its apparent popularity is still used just by a small minority of Vera users. It would be more efficient if ImperiHome would just fix what they’ve missed, in the same way Vera has been asked to fix their apps–it would work for almost all existing and future plugins. Since Reactor isn’t really an interactive plugin, I’m not really in a rush to provide the workaround.

Edit/follow-up: I’ve submitted a request to ImperiHome that they address this for the benefit of all plugins.

[quote=“rigpapa, post:1, topic:199805”]New stuff:

First, Reactor will now run scenes directly. It is no longer necessary to use a device trigger on your scene that watches your ReactorSensor. There is a new “Activities” tab in ReactorSensor configuration that allows you to specify a “Trip” scene, and an “Untrip” scene. Reactor will run these scenes when the associated ReactorSensor becomes tripped or untripped, respectively. If you decide to let Reactor run the scenes itself (and I think you will when you’ve finished reading this), you should/must turn off your device triggers in the scenes used by Reactor, otherwise the scenes will be run twice (once for the scene’s native trigger, and again when Reactor runs it). Scenes used in the Activities tab should always use “Manual” triggering in the scene definition.

Second and more exciting, in my opinion, is HOW Reactor runs scenes when you let it. Reactor doesn’t simply call Vera’s [tt]RunScene[/tt] action, it runs the scene entirely itself, step by step, including any scene Lua that you’ve defined (and that works the same way–if your scene Lua returns false, the scene activities aren’t run, otherwise they run).[/quote]

This is awesome, thank you so much! My Vera Scenes are now so much more reliable and they were pretty good already using reactor! 8)

Hi rigpapa, love your work mate. There is nothing that Reactor can’t do!!

I love the new feature of ‘Activities’ and can see the benefits as to why you have added it.

I’m just wondering if it’s possible for you to add direct control of devices in this tab as well?
Because reactor is so powerful, I often just have a Scene to turn a device on or off, so for each reactor I have a corresponding scene.
If reactor had direct control this would save time and complexity of having so many scenes.

What do you think?
Thanks.

A[quote=“bRock, post:19, topic:199805”]Hi rigpapa, love your work mate. There is nothing that Reactor can’t do!!

I love the new feature of ‘Activities’ and can see the benefits as to why you have added it.

I’m just wondering if it’s possible for you to add direct control of devices in this tab as well?
Because reactor is so powerful, I often just have a Scene to turn a device on or off, so for each reactor I have a corresponding scene.
If reactor had direct control this would save time and complexity of having so many scenes.

What do you think?
Thanks.[/quote]

Completely agree. As much as I’ve resisted duplicating the effort of building activities (i.e. “scenes”, because Vera already does it), I can’t resist the obvious convenience of doing it right there where the logic is, and combined with that complexity you mention of having to manage potentially dozens of scenes in Vera’s UI, I think it’s now inevitable that Reactor must do it. There are also some things I want to do in activities that would be massively kludgey to do in native scenes, and difficult for new Vera users to grasp quickly, but I could easily do if I was implementing the activities internally myself, such as using expressions and/or program logic to set a parameter to an action (e.g. have one activity that computes the right dimming level for a light being turned on, rather than needing separate scenes for off, dim and bright).

I’m very interested in hearing from you and the rest of the community any ideas you have about what it should look like, too.

Thanks for your kind words and suggestions!