Can Reactor react when a Vera scene is activated?
I have a Vera Scene that I activate manually, but can I set up a Reactorsensor to trip when this scene run?
I am not versed in Reactor but I have a similar setup in PLEG. My exterior lights are turned on/off via PLEG, but to ensure manual control, I created a Virtual Switch (VS). So I can manually turn on/off the lights. It is a trigger in PLEG that is monitoring the switch or setting the switch. I would think you could do something similar with the scene - using a VS, and having Reactor both monitor the VS and set the switch.
Luup does not provide an explicit event to notify that a scene is running. The workarounds suggested are the long-standing answer to this question for all applications.
I will add that usually when things like this come up, there’s an X-Y problem behind it.
You are of course right about the XY problem
Reason for my approach is that the scene is working fine, and I’m lazy and didn’t want to move everything in the scene to Reactor, but I want to add some more stuff depending on for example which weekday it is.
So to see this from a Z view instead, can I trip a Reactorsensor from a Flic button?
I am using Flic to trigger the scene today by some http stringystuff
Reactor conditions can respond to anything that can trigger a scene on Vera, you just need to find the secret sauce–you need to figure out which state variable in which service changes when the button is pressed. If it’s not obvious, what you can do is find the scene number (usually shown in grey right before the “Last Run” date in the web UI’s scene list), and then put that scene number and your Vera local IP address into the following URL (request that from a browser):
As for bringing your scene actions into a ReactorSensor, if you go to Activities, and edit the activity where you want to run your scene, there’s a “Run Scene” action you can use to run your existing scene. You can add more actions before or after as needed. In addition, once you select the scene, notice there’s button on the right side of the action row that becomes enabled–if you hover over it, it will show a tooltip that says “Import”–pressing this will copy the scene’s actions into the activity, if you want to take it that far.
The full name of a ReactorSensor activity, URL-escaped; for example, if you have a group named “Motion Night” and you want to run its “true” state activity, then you would specify Motion%20Night.TRUE (the space in the name has been URL-escaped);
If you know the group ID (shown after the group name in the Status tab, and in the Conditions editor), you can specify (for example) grp8f45fc.true to run its “true” state activity;
That’s correct. It’s telling you the job number the activity is running under. You can also use the “Logic Summary” events section (Tools tab of this ReactorSensor) to see general job status (or errors).
Hmm.
I am at work right now so can’t try again. But I didn’t see my sensor change to tripped.
Thought I would see it trip in UI so I didn’t add any Action when trying.
Your sensor will not change to tripped, it is only running the “true” activity associated with the condition group named “test6”, whatever that may be.
I now realise that this “http command” did not set my selected group (1) to TRUE but instead launch the actions connected to that condition group 1.
And of course because of this my other groups that shall react when group 1 became true does not react and perform their different actions.
My goal here is to make a “good night scene” that i can manually trigger by at http command when I go to sleep.
First a lots of lights etc should go off, then a Sonos shall play some music and set a sleep timer, but with different music depending on what weekday it is.
Easy in my mind
First in root group i set no conditions, and as Action kill all lights. (trigger manually)
Then I make one sub-group for each weekday, and set the different sonos for Action for each of the sub groups.
So here I forgot (what I actually knew )that each group are independent and and it didn’t require both root group and a sub group to be true.
So, next step was a new sub-group to use instead of root, move all light killing Action here (Thank You for “copy from” function) and then added Group State as an extra condition in each weekday group.
I guess this would have worked if I could manually trip a Condition group instead of Action group?
OK. So that’s a different problem. You cannot change the state of a condition group. It is the result of its evaluations, and that’s that.
However, there is a very common paradigm in the Vera world for things like this: use the HTTP command to manipulate a virtual switch, and extend your logic to accept the “on” condition of the virtual switch or your condition group as the trigger for whatever needs to happen.
The virtual switch can be the standard old-school VSwitch or it can be a Switchboard virtual switch, it really doesn’t matter. To turn the virtual switch on, just request http://your-vera-local-ip/port_3480/data_request?id=action&action=SetTarget&serviceId=urn:upnp-org:serviceId:SwitchPower1&newTargetValue=1&DeviceNum=virtual-switch-device-number
If you use Switchboard, you can set a timer in the switch options to automatically reset the switch after activating it. Otherwise, you’ll need to reset the switch in your activity’s actions.
So for next version you got a feature request.
Manually trigger a condition group, alternative, condition can detect when an action group is triggered.
It is just so neat if you don’t need extra plug-in