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. 
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.
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! 
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!
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!
Thanks rigpapa for replying.
In terms of ideas, I think it would be awesome if there was a set of conditions to turn a device on.
Then a set of conditions to turn that device off.
Plus your excellent idea on a condition or expression to control the brightness/dimming.
You have a knack and skill within this app to have a clear and easy to use interface which is evident by the popularity and uptake.
Thanks for your continual work and commitment to this app, you are making the lives of all us poor Vera users so much more flexible, productive and better off.
[quote=“rigpapa, post:7, topic:199805”]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.[/quote]
i can confirm that for
“DC” (for utility power)
the string is actually “utility” when powered on and not on battery
also the battery level is returning blank/null
but that could be because its currently powered
that being said, the battery level is always listed within the system even when plugged in
as vera has encorporated some battery management to allow the battery to last longer
they cycle the last 10% so it can go as low as 90% while plugged in
i will see what happens when unplugged and get back to you
however i can confirm there is already a system service/variable called verasecure
and it has an item called battery level
this does work and returns the battery level, wether on dc or on battery
there is also an item called status which currently returns a value of 0
i will see if it returns 1 when on battery
if theese both work you will not need these items under the reactor service
[quote=“charettepa, post:22, topic:199805”]i can confirm that for
“DC” (for utility power)
the string is actually “utility” when powered on and not on battery[/quote]
That’s correct, my bad. The strings will be “utility” or “battery” as appropriate. Forgot I remapped those (I thought “DC” was confusing because battery is DC power, too, ya know).
also the battery level is returning blank/null
I see why. In my match expression to parse it out, I used a JavaScript regex pattern (“\d”) instead of the Lua form (“%d”), so it wasn’t going to match anything and just produce blank results, as you are seeing. If you care, you can pull the current stable branch version of L_Reactor.lua (right-click link, Save as…) and upload it to your Vera (Apps > Develop apps > Luup files). I think that will fix it.
[quote=“rigpapa, post:23, topic:199805”][quote=“charettepa, post:22, topic:199805”]i can confirm that for
“DC” (for utility power)
the string is actually “utility” when powered on and not on battery[/quote]
That’s correct, my bad. The strings will be “utility” or “battery” as appropriate. Forgot I remapped those (I thought “DC” was confusing because battery is DC power, too, ya know).
also the battery level is returning blank/null
I see why. In my match expression to parse it out, I used a JavaScript regex pattern (“\d”) instead of the Lua form (“%d”), so it wasn’t going to match anything and just produce blank results, as you are seeing. If you care, you can pull the current stable branch version of L_Reactor.lua (right-click link, Save as…) and upload it to your Vera (Apps > Develop apps > Luup files). I think that will fix it.[/quote]
i can confirm they now function as you describe