Triggers - A Device's Value Is..

[randy]

Now we’ll look at triggers based on “A Devices Value is…”. In the screenshot below the dropdown is expanded and gives all of the choices


When you select the Trigger type you will be prompted for a Device



When you select the Device, you will be prompted for a Status or Value to Trigger on



You simply choose the Device's Status on which you want the Trigger to become True.


In addition to a Value or Status, you can trigger on an Invalid or Error State. This is covered in the Virtual Devices Forum here.


This trigger is the first to offer a choice that can lead to a runaway event. You will note that all of the choices except one are based upon the Value of a device being changed or set or at a Value for a specific period of time. These are all a “moment in time” type of trigger and will trigger only once each time the device is set or changed. Below is an example of the one trigger that presents a “gotcha” – "This device has been for at least…"



The problem with using this as a trigger is that it will continually trigger (about once a second) as soon as the First Floor Kitchen Overhead Light has been on for more than 15 minutes. This event will trigger until the light is turned off. If this trigger were to turn the light off it is a very safe trigger, but if you are using it to control another device or to speak something, it will continually do so until the light is turned off. There is an event option that will keep an event from running again for a fixed period of time that will be covered a little later in this thread. As a preventative measure, it is always good practice to set that option on any event that could continually trigger. There are not many triggers allowed that will present this hazard, but we will point them out on all of the core triggers. The lesson to be learned is to think clearly about what will cause a trigger to be true and make sure that it is a “moment in time” or that the event itself makes the trigger false.

The second choice of a Device Value and time is "This device has been/for exactly..." is a much safer option.


This Trigger is only true at the exact period of time. It will only trigger once.

The rest of the Triggers are based upon the Value of the Device being “Set” or Changing. There is in important distinction between the two. A device value is “Set” when it is commanded to be a value, either by local control or by HS control. The value does not have to change. For example if a light switch is On and it is commanded to be On, the value doesn’t change, but it has been “Set”. This is a very important distinction when triggering off of a Central Scene or remote control. On these devices, you may press a button to perform an operation. You may press the same button again hours later. The second press will not result in a change of value, but the value will be Set. When you use the trigger “This Device had its value set to…” it will be true any time the device value is set, but not necessarily changed.

[NeilsenRM]

Can't Find a trigger that does what I want

I want to turn on a green light on my multi sensor when all my windows and doors are closed when I'm home. Kind of a all is closed and well. I want to check all 10 windows and doors for closed and a virtual device for "home" then turn on the light. I need to be able to check the current status not "the status just changed to" because all might already be closed. The first IF seems to offer only a if just changed condition. I can't figure out how to do this with out doing 11 different events each with a different first device device and that would only report the status once. I'm using the option to not run the event more than every 10 minutes so I don't get a loop condition. I also wait 9 minutes and 59 seconds and turn the light off. Would have been nice to have a else then but I can work around that.

I'm new to this and would like some ideas on how do this kind of EVENT.

Thanks

[Uncle Michael]

If you use a recurring trigger (once a minute is probably safe, but you could run it more frequently if you wanted to), then you can add a series of 'And If' conditions, one for each door and window, one for home, and one for the status of the light. If the value of each door and window is 'Closed' and if the value of the home device is 'Home', and the green light is 'Off', then turn the green light on.

For turning the green light off, I'd opt for 11 events. If any door or window opens or if the home device changes and becomes 'Away', then turn the green light off. Making the events is actually pretty easy. Do it once, then copy it and change the trigger to the next device to check, rinse and repeat.

[jhearty]

You should still try to have an initial trigger that is a moment in time to start things off. There's really no reason to keep checking over and over again, just check when something changed like a window or door opening or closing.

I have two events to check windows closed. One has a bunch of Or If triggers (each a moment in time when a given window is closed) looking for ANY window to be closed. If any of those Or Ifs are true, the Then action is to run a second manually triggered event with a bunch of conditions to check if ALL windows are closed. In my case the Then action of this second event turns on the heat.

I then have a second event to handle the opposite of any single window open and condition of heat on to turn off the heat.

John

[Uncle Michael]

You should still try to have an initial trigger that is a moment in time to start things off. There's really no reason to keep checking over and over again, just check when something changed like a window or door opening or closing.

I'm not sure it matters. To know when something changes, HS has to monitor every device all the time. As long as there is a check on the state of the light, the event will only run if the light is off.

It would be interesting to get an authoritative response, but AFAIK the checking happens whether or not an event exists.

[jhearty]

I'm not sure it matters. To know when something changes, HS has to monitor every device all the time. As long as there is a check on the state of the light, the event will only run if the light is off.

It would be interesting to get an authoritative response, but AFAIK the checking happens whether or not an event exists.

Every device is represented by a software object, and any time something signals HS3 of a change, HS3 updates the object. So when a security system sends data to HS3 indicating a window/zone opened/faulted, HS3 updates the object for that window/zone. That happens whether or not there is an event for that trigger. At the time of the state change, HS3 should be checking if there are events built with triggers for that state change. If so they continue on to check any conditions in the events to decide if the Then actions should run.

My point was, he wants to turn the light green when all doors and windows are closed and the Home virtual device is set on. To do that, he should only turn the light on once the last window/door is closed, then off when any window/door opens. Those are moments in time that the check can be made to see if all doors/windows are closed. More importantly, if done periodically like every 10 minutes, the light may not represent the desired state for the period of time between the last door/window closing and the 10 minute check. If the check is done each time a door/window closes then the light will always represent the desired state.

Edit: Here's a post showing the events to check for all windows closed:
http://board.homeseer.com/showpost.p...59&postcount=8

[Uncle Michael]

My point was, he wants to turn the light green when all doors and windows are closed and the Home virtual device is set on. To do that, he should only turn the light on once the last window/door is closed, then off when any window/door opens. Those are moments in time that the check can be made to see if all doors/windows are closed. More importantly, if done periodically like every 10 minutes, the light may not represent the desired state for the period of time between the last door/window closing and the 10 minute check.

Good point. I misunderstood your earlier post. I like your event, and by changing the test from 'Normal' to 'Faulted', the same structure could be used to turn the light off when any door or window is opened!

[NeilsenRM]

Thanks

I got thinks working based on the first reply and learned a bunch.

I need to read in detail and think about the other suggestion. I like not running Events over and over. I have a programming background and the Event structure is a adjustment.

[randy]

John's (jhearty) suggestion has the advantage of being instant, but the disadvantage of not being able to synchronize easily if the state of a door/window changes while HomeSeer is down. The suggestion Uncle Michael gave has the advantage of verifying the state of the windows on a recurring basis, thereby staying in sync. It will have a delay based upon the recurring frequency. You could add a recurring trigger to John's second event that would go through and verify the state of the windows on a recurring basis, yet still call it from the primary event for instant evaluation if any window changes state. An event with a recurring trigger can be called from another event and run manually, just as a manually triggered events. Even when you check "Run only if other event conditions are true", the trigger is ALWAYS ignored, even though the conditions are honored.

[Uncle Michael]

I like not running Events over and over.

Just to be clear, recurring events with conditions only run if the conditions are met, even though the conditions are checked 'over and over'. That is what an event engine does all the time. The variable overhead comes from executing event actions, and avoiding needless repetition of event actions is a way to improve performance.

[Uncle Michael]

John's (jhearty) suggestion has the advantage of being instant, but the disadvantage of not being able to synchronize easily if the state of a door/window changes while HomeSeer is down. The suggestion Uncle Michael gave has the advantage of verifying the state of the windows on a recurring basis, thereby staying in sync. It will have a delay based upon the recurring frequency. You could add a recurring trigger to John's second event that would go through and verify the state of the windows on a recurring basis, yet still call it from the primary event for instant evaluation if any window changes state. An event with a recurring trigger can be called from another event and run manually, just as a manually triggered events. Even when you check "Run only if other event conditions are true", the trigger is ALWAYS ignored, even though the conditions are honored.

This discussion contains an important lesson: Almost every problem can be solved in more than one way. The procedure - or combination - you ultimately choose depends on the details of what you want to accomplish . . . and your level of OCD.