[quote=“Andr, post:1, topic:200039”]So I start this new thread instead of pollute my Feture Request thread ([url=http://forum.micasaverde.com/index.php/topic,111066.0.html]http://forum.micasaverde.com/index.php/topic,111066.0.html[/url]) with this newbie questions.
The Feature request was hasty fixed by awesome rigpapa
What I want is to control my outdoor lightning as follows.
Start Scene outdoor light ON
- every day 5 min before nautical dusk
- every morning at 05.45am if it still dark outside (between dusk and dawn)
Start Scene outdoor light OFF
- every night at 00.00
- every morning 5min after nautical dawn
Here comes my questions/thoughts so far
Can I use only one reactor sensor? Is this what the un-trip scene thing is for? sensor untrips = lights off, sensor trips = lights on?[/quote]
That’s correct. A single Reactor sensor, and it can turn on the lights at the correct time when it trips, and turn them back off later when it untrips. The logic above keeps the ReactorSensor tripped throughout the “active” period–the period you want the lights on.
What I understand reactor works even if Vera happens to reboot at a time an event should start. Is that why I can't set a specific time like lamps on exactly 05.45am? It needs a time frame to work within?
That’s basically right. An “after xx:xx” time condition will run exactly at xx:xx if the Vera is up and running, so it is effectively an “at xx:xx” in that sense. But because it’s really a span test, it will also become true if the Vera is unplugged at exactly xx:xx and later gets plugged in and boots up. I suppose I could add an “exactly at” condition, but it seems redundant.
I don't really understand the answer [b]rigpapa[/b] gave in my other thread
[quote="rigpapa, post:6, topic:200035"][quote="Andr, post:4, topic:200035"]One question of lesser importance (I think)
In one group the I have two conditions,
- between dusk - dawn
- Time is between 05:45-05:50, here I basically just want to start my outdoor lightning scene if it is dark outside and time is 05:45, but I couldn't really see how to just set at specific time?[/quote]
Group #1:
Sunrise/sunset condition: after dusk <— this condition is true from dusk to midnight
Time condition: after 17:45 <— this condition is true from 17:45 to midnight
Group #2:
Sunrise/sunset condition: before dawn <— this condition is true from midnight to dawn
The first group’s conditions will trip the ReactorSensor and trigger your “lights on” scene at the later of dusk or 5:45pm (it’s “AND” within a group, so both conditions need to be met). These conditions automatically reset at midnight. To prevent that reset from untripping the ReactorSensor and running your “lights off” scene too early, the second group’s single condition becomes true at midnight and stays true until dawn. So at midnight the first group goes false, but the second group goes true in the same instant, so the ReactorSensor stays tripped. At dawn, that lone condition in the second group goes false, and at that point both groups are false, so your ReactorSensor untrips and runs the “lights off” scene.[/quote]
Why is “before dawn” in a separate group?
An “after” or “before” condition with time only (no month, day, year date) resets at midnight. It’s really like one would normally think about time, I think. If you want to do something after 4:00 in the afternoon, then a person thinks like this: (a) 8:00am is too early–it’s not time yet; (b) 2:00pm is too early–it’s not time yet; (c) 4:15pm–I should be doing it! (d) 9:00pm–I still should be doing it; (e) 1:00am–it’s a new day, and so it’s not time yet. Reactor thinks this way as well.
Put another way, and “after xx:xx” condition is a synonym for “between xx:xx and midnight”, while a “before xx:xx” condition is a synonym for “between midnight and xx:xx”.
Now look at the logic I suggested. The first logic group has two conditions. For a logic group to be TRUE, all the conditions in it have to be true (that’s the “AND” logic of a group). The first condition in the group is our sun test–is it now after dusk? That condition will be true from dusk to midnight. The second condition in our test, is it after 17:45, will be true from 17:45 to midnight. So by "AND"ing them together, the group is only true when both are true, and this has the effect of being true only when it is both after disk and after 17:45, so therefore true at the later of the two time events, logically. With the ReactorSensor set up with a “trip scene” to turn on the lights, the lights will be turned on at that time.
So, the first group will turn on the lights at the right time. The problem, though, is that if we do nothing else, both conditions will go false at midnight; this will reset the group to false, and the ReactorSensor itself will then see no group is true, so it will untrip. If you have set the “untrip scene” to turn off your lights, your lights will go out at midnight. That’s too early, so we need to fix that with some additional logic.
The second group in the ReactorSensor has the single condition “before dawn”. Using the rules above, it means that this condition will be true between midnight and whatever time dawn is calculated to be. So at midnight, this condition becomes true. Because it is the only condition in the group, the group becomes true as well (all group conditions are true), so the ReactorSensor wants to be tripped.
There are two groups in this ReactorSensor. That means the sensor’s overall state will be the “OR” of the two groups–if either group 1 OR group 2 is true, the sensor will be true/tripped. So let’s just step through time to see what happens. For this example, I’ll assume that dusk comes later than 17:45, but it doesn’t really matter…
Event 1: 17:45 rolls around and Reactor determines that the second condition of group 1 is now true. The first condition (after dusk) has not yet been met, however, so group 1 is still false. Group 2 is also false. Reactor knows there’s nothing more to do on this ReactorSensor until either dusk or dawn, and dusk is coming sooner, so it schedules its next update for that time.
Event 2: At the calculated dusk time, Reactor determines it’s now dusk, so the first condition of group 1 now goes true; both conditions are now true, so Reactor sees that its overall state is untripped, so it transitions to tripped state and runs the “tripped scene”. The lights are now on. Job done, Reactor knows there’s nothing more to do until either dawn or midnight, so it schedules itself for an update at midnight and gets some rest.
Event 3: It’s midnight. Reactor wakes up and evaluates the group 1 conditions, and determines both of them to be false, so group 1’s state becomes false. It then evaluates the single group 2 condition (“before dawn”) and determines it to be true, so group 2’s state becomes true. Reactor then sees that a group is true (group 2), so it needs to be tripped. But it’s already tripped, and it only reacts to changes in state, so it doesn’t do anything more (it doesn’t re-set tripped state or re-run the “tripped scene”). The lights are still on, because event 2 turned them on. Reactor determines that the sensor’s next event will take place at dawn, so it goes to sleep until then.
Event 4: Dawn! Reactor wakes up, and now determines that group 2’s condition is false, so group 2 goes false. Now, there are no true groups, so Reactor now wants its overall state to be untripped, but it knows it’s in tripped state, so it transitions to untripped, and runs the “untripped scene”, which turns off the lights. Job done. It now determines that the next time event will be at 17:45 that day, so it goes to sleep until then (and at that time, it starts over at event 1).
So, the first group takes care of the period before midnight. The second group takes care of the period after midnight. The net effect is that the ReactorSensor is tripped from the later of dusk or 17:45 to dawn–it’s tripped throughout the period we want the lights ON. So then, it’s just a matter of setting up the scenes to turn the lights on when the ReactorSensor trips, and off when it untrips. These scenes can run by Reactor directly (recommended, use the Activities tab), or by Vera’s scene triggers (using the ReactorSensor’s tripped state as the trigger).
Also note that at Event 3 an important feature of Reactor is at play. Reactor reacts to changes in state. In this event, one group goes false, and the other goes true, but the result of the OR logic between the two groups still produces the same result. That is, before event 3, the logic is TRUE (group 1) OR FALSE (group 2) ==> TRUE (overall target state). At event 3, it shifts to FALSE (group1) OR TRUE (group 2) ==> TRUE (overall). The overall state doesn’t change, even though the groups have changed. But because the overall state hasn’t changed, Reactor doesn’t do anything more–it doesn’t re-trip or run any scenes. I like to say that Reactor reacts to “edges” not “states.” The same is true at every condition: if you have a single temperature condition in a ReactorSensor that is true when an outdoor temperature sensor reports a temperature below 10C, and the sensor reports 9C, the condition is true, and if it was previously false, Reactor responds to it (trips). Then, if the temperature sensor later reports that it’s now cooled further to 8C, the condition is still true, but that’s not a change from its previous state, so it doesn’t perform any actions in this case. You can see the value change on the condition in the status tab, but that doesn’t change the condition’s result state, or the group’s result state, or the ReactorSensor’s tripped state.
Another detail to note: Reactor schedules its re-evaluations of time conditions (including sunrise/sunset) intelligently. If you use an “after 17:45” condition, for example, it does not re-evaluate that condition every minute leading up to it, or every minute after, to see if the condition is met or not. It determines the time “edges” from the condition values and operator, and schedules the update for the soonest next possible event. So if it’s currently 2:00pm and Reactor is looking for your “after 17:45” condition to be true, it won’t evaluate that condition until exactly 17:45. It’s asleep until that point. This is one of the reasons Reactor is light and fast on the older Vera hardware, a big requirement of mine.
Let’s rewind a moment…
The whole thing got more complicated because you introduced the idea that you wanted the lights on at the later of 17:45 and dusk. If you just wanted the lights on from dusk to dawn, a single condition would do the job:
- sunrise/sunset - between dusk and dawn
That’s all that’s needed. But, because you also needed a specific time for which the lights should not come on any earlier, we had to split the condition logic up. Why can’t we just add the time to the condition as you originally tried? Let’s see… if we add “after 17:45” to this condition, our one and only condition group now becomes:
- sunrise/sunset - between dusk and dawn
- time/date - after 17:45
If we run this in time (again assuming dusk is later than 17:45), the progress of events is: (1) 17:45 arrives, so condition 2 is true, but condition 1 is false, so the group is false, no action; (2) dusk arrives, so condition 2 is now true, condition 1 is already true, so everything in the group is true and Reactor trips the ReactorSensor and runs the “lights on” scene… so far so good, right? well… (3) midnight rolls around and now condition 2 goes FALSE, so the group goes false… and the ReactorSensor untrips and runs the “lights off” scene. At midnight. Too early. So the purpose of splitting the “between” into separate “before” and “after” conditions in two groups was to address this fault.
Another way to fix it would be to use a “between” condition on the time. Let’s say you want the lights on no earlier than 17:45, but also no later than 7:00 in the morning. You can make your conditions like this:
- sunrise/sunset - between dusk and dawn
- time/date - between 17:45 and 07:00
That “between” time condition is a game-changer. That second condition will remain true across midnight, and go false after 7am. The two conditions are now working together, and the lights will stay on between (a) the later of 17:45 and dusk, and (b) the earlier of dawn and 07:00. So that’s a different way of solving your original problem, but by adding a condition you didn’t originally make (lights on no later than 7am). If you didn’t want to restrict the morning period, you could also make that a ridiculously out of range time (a time later than any dawn in your location), like 11am, so that the dawn test is really the only controlling condition for the morning.
[quote="Don Phillips, post:7, topic:200035"]Using PLEG, and I suspect it would work with Reactor, I read weather conditions and offset the sunrise/sunset by 15 minutes for overcast and 30 minutes for precipitation.
...[/quote]
This is a great idea!
How do I get Vera/Reactor to interact with weather data?
I know I can see weather on dashboard, but i have never seen some way to interact on it.
You need a weather plugin to get the data. Reactor can then see the plugin device’s data and do its logic with it. There are several solutions out there. I myself use SiteSensor and just query a weather API directly, but that’s my plugin, so of course that’s my solution.