Variable Times for Triggered Events

[TurboSam]

I'm lost in time...

How can I set differing start and stop times for use with triggered events?

I have several rules tied to motion sensors and people counters that turn interior lights on and off during the day. Right now the events are triggered based on two triggers that both have to be true: sensors tripping AND a time that "IsInTimeRange" so the sensors don't trip the lights at night. The "IsInTimeRange" trigger is limited to hours and not minutes so I'd like a little more flexibility there to use minutes, but more importantly, I'd also like to have more ability to change the start and times via action commands when needed.

What I'd like to do is move the start and stop times into global or local start and stop variables (with appropriate IF statements) and put them in the triggered event action. I would then have the sensor as the only event trigger. I would also create separate actions to change the start and stop times by re-writing the variables. That way, while the event would trigger on each sensor violation, the lights would only go on and off during the revised time frames, and I could, for example, start or stop the automation later or earlier on a given day.

The best I have (conceptually) been able to come up with is to define start and stop fields in the Variables Driver, read them in as global or local variables in the triggered event action, and then have a way to write a HH:MM formatted daily time to these variable. I didn't get far on that since I was not sure what Variable Drivers data field to use (MEng.time?) and I couldn't figure out how to write a HH:MM daily start or stop time to the variable driver or to a global or local variable...

Is that the best way? Is this even possible?

Thanks!

[Dean Roddey]

You will have to deal with the weirdness of the rollover at midnight in your action. But, leaving that aside, probably the best bet would be to just use cardinal fields in the variables driver, into which you put (hours * 60) + minutes into. That's easy enough to do from an action, or from a screen where you let the user select an hour and minute.

In the action, get the current time values, create an (hours*60) + minutes value from those values, and compare the two to figure out if you want to do the action or not.

[TurboSam]

Thanks, Dean.

The midnight rollover is not generally an issue, since I'll typically want the lights on auto from early morning to evening when the house is occupied and people are awake. I'll play around with cardinal numbers.

I just found the SetTimeVar command and this post about it http://www.charmedquark.com/vb_forum/sho...hp?t=10401. I was able to use load it into with a Variables Driver with a MEng.time field.

But if I enter, for example, 08:15 as a start time variable in SetTimeVar is that just the value of the 100 nanoseconds since Jan 1 1970 at the time of entry so that in effect it won't work for any other day (e.g. tomorrow or the next day)?

[Dean Roddey]

You want to use System::GetTimeParts to pull the hours, minutes and seconds out of a time. So you can create a time variable and set it to the current time. Then you can pass it to GetTimeParts() to get the hours and minutes out. Multiply the hours times 60 and add the minutes to it.

That'll be the comparison value, which you can compare against a similar sort of value you've stored elsewhere, e.g. the variables driver.

[Dean Roddey]

You can use System::FormatTimeVal() to get the current time actually. Don't even bother to use the time variable. use [local] to get it to format the current local time. Use Raw as the pattern, to get it to format it out as a raw 100-ns value. You can then pass this to GetTimeParts().

[TurboSam]

Thanks, again, Dean.

I've been thinking about what I'm trying to do, and I think I have found an easier way.

I'm going to create a true/false field in the variables driver (e.g. AutoLights), and I'll turn it on (true) every morning at a set time by a scheduled event and/or by a triggered event when my Elk system is disarmed. I'll have a matching off (false) event scheduled every evening and/or a triggered event to turn it off when the Elk system is armed.

That way I can replace the IsInTimeRange trigger with an "Event Field Equals" trigger set to true for the AutoLights field, so the triggered event will "work" based on an occupancy sensor triggering only when the sensor fires and the AutoLights field is true. I'll then be able to use SetSchEvTime to change the scheduled on and off times for the AutoLights scheduled event, which will give me the flexibility to change the default occupancy sensor settings.

I've not done much in the way of pop-ups, but my goal is create one that would allow me to use a popup to input the time for the SetSchEvTime.

[Dean Roddey]

Actually, for the AutoLights, you'd want not to use the value in the incoming trigger, since you'd never trigger off of that field. You just want to do (in conjunction with the occupancy sensor filter) a simple check of the value of the AutoLights field, i.e. use the otherwise seldom every used one (field value equals, I think it is.) Well, it's not that it's that seldom used but it always needs to be used with something else, in this case "if the incoming occupancy sensor field value indicates movement AND the current value of the AutoTrigger field is true", then do something.

[TurboSam]

I think we are saying the same thing.

I was not planning on using the values in the trigger, and planned (as you noted) on using the "Fld Value Equals" as the second filter in the event To my mind it's similar to when I was using the IsInTimeFrame as my second filter since that also required the sensor trigger as the first filter and would not have worked by itself.

[Ron Haley]

Is there a way of controlling the order of triggered events that happen at the same time. e.g. End of day, end of week?

[Dean Roddey]

No, any event that is ready is spun up on its own thread and they could be running simultaneously, or in slightly different order depending on exactly when the check is done.

You could of course set up two global actions, end of day and end of week. Then just set up an end of day triggered event. It can invoke end of day and then check to see if it's a particular day and also invoke the end of week next.