Actions - Run Another Event

[randy]

The purpose of this Action is to call and run another event. Like many actions there are some advanced options, we will go through those as well. In its simplest form the event would look like this:





The event to be called would normally be an event that is designed to me manually triggered such as:




It becomes more complicated if the event you are calling has conditions in it. Below is an event that has a simple condition that it will only run at night and if the switch is already off.





It is important to note that by default HomeSeer will ignore conditions in events that are called from another event. Conditions are also ignored when an Event is run from HSTouch. This is the normal behavior. The event above will always run when called from another event, regardless of the value of the switch or the time of day. This is where the first of the advanced options comes into play. As in other actions if advanced options are available there is a little red icon letting you know there are advanced options available. As with all events you can enable this option by default on all events within a group by clicking on the icon in the row of icons at the top of the event group.

It is also very important to remember Conditions are ALWAYS ignored when an event is run from HSTouch, IFTTT, Google Home, Echo or manually triggered from the "Run" button. It is also important to note that any event run from any means other than self triggering will ignore the Trigger. The only time Conditions are honored is when specifically directed in the Event Action calling it.




Once you have clicked on that icon, you are presented with two advanced options, the first we will cover is the checkbox "Run Only if Other Event Conditions are True".





If you select that checkbox any conditions in the event you are calling will be honored. Without it selected they will be ignored.




With that box selected the event with conditions above will only run at night when the light is off.

It is also important to note that prior to version 3.0.0.170 of HS3, when you select the box "Run Only if Other Event Conditions are True" despite it not explicitly stating so, the event trigger was also necessary to be true in order for the event to run. Not a big deal on a manually triggered event, but rendering virtually any event with a standard trigger useless when the box is selected. For example the event below could not be run from another event with the box selected, because you would have to call it at the exact moment that motion was detected, which is likely never to be true.




With version 3.0.0.170 and later this behavior has changed. Beginning with this version the check box behaves explicitly as it is described "Run Only if Other Event Conditions are True" - it only looks at conditions and ignores the trigger, meaning that the above event will run if called from another event as long as the conditions are true. The trigger will still be ignored.

This means that if you expect to manually call an event that is triggered by a device action, you should also put a condition based upon the value of that device being true. Below is an example of an event that can trigger on its own or be run after the fact by being called from another event. It seems a little redundant, but is much easier than creating a compound event that allows for either a manual trigger or a specific trigger, sharing the same conditions and actions.

[randy]

There is another advanced option to allow a delay in the action of running event. It can also be run in conjuntion with other advanced options. Below, for illustrative purposes I have added a 1 hour delay to the action.



I manually triggered the event and like Delayed Device Actions it creates a new event and places it in a group called Delayed Events. If the group does not exist, it will be created. Since I manually triggered the event at 1:02:50 PM, the new event is created with a time based trigger of 2:02:50 PM. You will note that the new Delayed Event still is set to run the Event Conditions are true. If one of the conditions is true when the Delayed Event is created and becomes false during the delay - the event will not run. In other words, the event conditions are evaluated at the time it is run.




The check mark beside Options means that an option is selected. In this case the option is "Remove this Event After Triggering". Once the event runs, it will be deleted. If it is the only event in Delayed Events group, the group will also be deleted.

[Gunneyk]

Randy,

I am a bit confused as to your conditions in the demo for the Dusk to Dawn value. Isn't the second condition redundant with the first? If the Dusk-Dawn value changes and becomes ON then whey do you need to test for a value = to ON?

[randy]

Randy,

I am a bit confused as to your conditions in the demo for the Dusk to Dawn value. Isn't the second condition redundant with the first? If the Dusk-Dawn value changes and becomes ON then whey do you need to test for a value = to ON?

If you read the text above the event:

"This means that if you expect to manually call an event that is triggered by a device action, you should also put a condition based upon the value of that device being true. Below is an example of an event that can trigger on its own or be run after the fact by being called from another event. It seems a little redundant, but is much easier than creating a compound event that allows for either a manual trigger or a specific trigger, sharing the same conditions and actions."

That is only if you build a standard triggered event that you may want to call from an action from within another event. In the example I posted, the event is triggered by the Dusk-Dawn virtual device being changed to ON. Lets say the event fails to trigger for some reason and you want to run that event as a cleanup after the fact, that redundancy makes the event still respect the value of Dusk-Dawn.

It just provides an example of how you can create an event that has a standard trigger with conditions that can also be run manually. The way it was before, checking the box "Run Only if Other Event Conditions are True" for an event that had anything other than "This Event is Manually Triggered" (there are a few exceptions) would result in an event that would never run.

Let's say I have a battery check that runs at 8:00 AM every morning:

IF The time is 8:00 AM
AND IF the Device Downstairs Thermostat Battery is less than 20%
THEN Send pushover notice

Now let's say I want to run that event or a group of events at some time other than 8:00 AM. The way the "Run Only if Other Event Conditions are True" worked before is that event would run regardless of the time of day and regardless of the battery level if the box was unchecked. If the box was checked, it would never run, because you would have to call the event at the same microsecond as the time became 8:00 AM which is impossible.

[Gunneyk]

Ah yes you did explain it to begin with, I apparently just didn't read that well enough. Makes sense now. Thanks as always.

[randy]

Ah yes you did explain it to begin with, I apparently just didn't read that well enough. Makes sense now. Thanks as always.

The change is subtle, but it does expand the possibility of calling events other than "This Event is Manually Triggered" from within another event. There are not a lot of times you might use this, but it does open up some new possibilities. It still operates as it always did on manually triggered events.

Here is an example of an event that I was unable to use before, it is triggered by the change of a virtual device "Extreme Cold Offset".



Each event is also affected by the change in two other devices. I can now call this event by events triggered in changes of the other two devices and still have the conditions honored.

To be quite honest, it could be left as a manually triggered event then triggered to run by changes in any of the three involved devices, but when I filed the Bugzilla last year I wasn't as comfortable with event structuring as I am now.

Another user "U5tabil" had a couple of compound events that were designed to run manually or by trigger. I'm guessing he wanted to be able to run them in case one of the events missed its trigger.



After the change in the program, they no longer needed to be compound events.

[Gunneyk]

OK Randy I seem to be missing something simple here. I have read thru many of your event posts (multiple times) and this one in particular is exactly what I am trying to do but having no luck at it. I have an initial Motion event that is set up to first call another normally disabled event with the advanced feature set to honor conditions in the other event. It then sends a text and sets a light on a HSM200.

The motion gets triggered and it calls the other event and it goes on to send the text etc. However as you can see from the normally disabled event I have a condition for the light to be above 5 LUX and for the light to be off and it always turns the light on even though the current LUX is 1000 (very bright out).

So why is this not honoring the other conditions in the event it is calling even though I have that option checked?

As a side rant I wish I could simply do this logic below without having to call another event. It just seems so natural.

IF some trigger happens
THEN
Turn on this
Turn off that
THEN
IF some other conditions are true
THEN
Turn this on

[randy]

OK Randy I seem to be missing something simple here. I have read thru many of your event posts (multiple times) and this one in particular is exactly what I am trying to do but having no luck at it. I have an initial Motion event that is set up to first call another normally disabled event with the advanced feature set to honor conditions in the other event. It then sends a text and sets a light on a HSM200.

The motion gets triggered and it calls the other event and it goes on to send the text etc. However as you can see from the normally disabled event I have a condition for the light to be above 5 LUX and for the light to be off and it always turns the light on even though the current LUX is 1000 (very bright out).

So why is this not honoring the other conditions in the event it is calling even though I have that option checked?

As a side rant I wish I could simply do this logic below without having to call another event. It just seems so natural.

IF some trigger happens
THEN
Turn on this
Turn off that
THEN
IF some other conditions are true
THEN
Turn this on

You can always submit a Bugzilla for enhancement requests, but Rich has said that making events more complicated by nesting is not something that would be good for the vast majority of HomeSeer users. Their goal was to make it simple. Like it or not the the current event structure will do anything you need, changing the way you do it is just structure.

Anyway your problem in the second event is that Motion is a trigger. As I wrote in the first post above

With version 3.0.0.170 and later this behavior has changed. Beginning with this version the check box behaves explicitly as it is described "Run Only if Other Event Conditions are True" - it only looks at conditions and ignores the trigger, meaning that the above event will run if called from another event as long as the conditions are true. The trigger will still be ignored.

To explain why this is an absolutely necessary behavior think about this: since motion is a trigger, the calling event would have to run this event at the exact millisecond that motion is triggered - something that has an infinitesimal chance of happening. So, if your second event is a dual purpose event, you will need to convert it to a different trigger, such as a recurring trigger and make motion a condition -or- create a duplicate of it where it is manually triggered with motion as a condition.

[Gunneyk]

Anyway your problem in the second event is that Motion is a trigger. As I wrote in the first post above

With version 3.0.0.170 and later this behavior has changed. Beginning with this version the check box behaves explicitly as it is described "Run Only if Other Event Conditions are True" - it only looks at conditions and ignores the trigger, meaning that the above event will run if called from another event as long as the conditions are true. The trigger will still be ignored.

To explain whaythis is an absolutely necessary behavior think about this: since motion is a trigger, the calling event would have to run this event at the exact millisecond that motion is triggered - something that has an infinitesimal chance of happening. So, if your second event is a dual purpose event, you will need to convert it to a different trigger, such as a recurring trigger and make motion a condition -or- create a duplicate of it where it is manually triggered with motion as a condition.

I simply don't understand what this means. The only reason I am calling another event is because it won't let me nest conditions and device control in one event. I think the disconnect with me is related to terminology and prior programming experience so please bear with me. To me a Trigger is some sort of change that can spark an Event. A motion detector changing from non-motion to motion would be my trigger. Event to me is a container that wraps conditional logic with actions to do one or more tasks. So in my Event called "Alert for Motion at Front Door" it gets triggered by the motion detector changing to Motion. From there on I have what I called conditions to dictate if something happens or not. I see from the HS help file they classify some conditions as triggers. From here I want to do two sets of Actions. One set I want to execute always when the initial trigger of motion happens. This will send an email, set some devices etc. That part I have no issues with and works fine. The second Action is conditional but I can't add that conditional logic here so I must call another event that has those conditions. OK fine. However that other event always fires regardless of the conditions. This is where I am confused. First off the Advanced setting called "If the Event Conditions are True". Is that talking about the conditions in the event I am trying to call or something in the one I am calling the new event from? I assume it is the new events conditions. I always want this other event to be called so that the rest of the Actions in the original event will execute regardless of any other conditions and this seems to happen. So when it calls the new Event there is no trigger in that event since it was called (triggered) by the original event. It only has conditional logic to decide if the light should be switched on or not. Yes you tried explaining to me with the words highlighted in red above saying it ignores the trigger. What trigger are you referring to? I don't have a trigger in the new event, only conditions and actions. You say that since motion is a trigger the calling event would have to run this (new?) event at the exact millisecond the motion is triggered. Why? The motion simply triggered the original event and should have no bearing what so ever on any subsequent actions that event may chose to do. Once the original event was started the specified conditions should dictate what actions are done. In this case my first action in the original event is to run the new event which it does. But I just don't get why it doesn't honor the conditions in the new event with that advanced option set to tell it to do so. If HS thinks allowing us to nest conditions and actions in a single event is more confusing than what ever this logic is I definitely disagree. I have never programmed in a language that didn't allow nested conditions / actions and if they called other events they always honored current conditions. I don't want to try and debate that part. I simply want to understand what this logic is that makes my second event fail to do what I want. Does my view of this make any sense?

[randy]

I simply don't understand what this means. The only reason I am calling another event is because it won't let me nest conditions and device control in one event. I think the disconnect with me is related to terminology and prior programming experience so please bear with me. To me a Trigger is some sort of change that can spark an Event.

Bingo! I misstated in my post above. Your trigger is "IF Motion - Plus Front Porch Front Porch Luminance was set and has a value that is less than 5 lux". If you really think about that trigger and realize when it is true, it is only at the very instant it is set with a value of less than 5 lux. It is only true for a microsecond each time that value is set. If it was true ALL of the time the value was less than 5 lux, it would trigger continually all night long. This is true of all triggers except a couple, which are really troublesome triggers.

A motion detector changing from non-motion to motion would be my trigger. Event to me is a container that wraps conditional logic with actions to do one or more tasks. So in my Event called "Alert for Motion at Front Door" it gets triggered by the motion detector changing to Motion. From there on I have what I called conditions to dictate if something happens or not. I see from the HS help file they classify some conditions as triggers.

Not quite true. I haven't read the manual, but some triggers can also be conditions or the reverse, it all depends on where it is used in an event structure. When a line starts with IF or OR IF it is ALWAYS a trigger. If it starts with AND IF it is a condition.

From here I want to do two sets of Actions. One set I want to execute always when the initial trigger of motion happens. This will send an email, set some devices etc. That part I have no issues with and works fine. The second Action is conditional but I can't add that conditional logic here so I must call another event that has those conditions. OK fine. However that other event always fires regardless of the conditions. This is where I am confused. First off the Advanced setting called "If the Event Conditions are True". Is that talking about the conditions in the event I am trying to call or something in the one I am calling the new event from? I assume it is the new events conditions. It only has conditional logic to decide if the light should be switched on or not. Yes you tried explaining to me with the words highlighted in red above saying it ignores the trigger. What trigger are you referring to? I don't have a trigger in the new event, only conditions and actions.

Forget about your first event it is perfect. Your first ACTION (always starting with Then) is to call your second event. The "If the Event Conditions are True, Run Event" part applies only to the event being called in that action, not to the event doing the calling.

I always want this other event to be called so that the rest of the Actions in the original event will execute regardless of any other conditions and this seems to happen. So when it calls the new Event there is no trigger in that event since it was called (triggered) by the original event.

No. The second event still has a trigger "IF Motion - Plus Front Porch Front Porch Luminance was set and has a value that is less than 5 lux". That trigger does not become a condition when the event is called, it is ignored. The reason it is ignored is because it was structured as a trigger in the event. As a trigger it is only true at the very microsecond the luminance value is set AND its value is less than 5 lux. It is not true ALL the time the luminance is less than 5 lux.

You say that since motion is a trigger the calling event would have to run this (new?) event at the exact millisecond the motion is triggered. Why? The motion simply triggered the original event and should have no bearing what so ever on any subsequent actions that event may chose to do.

My bad on that, I was being hasty in my reply, I saw the word Motion and it improperly registered with my aging brain I should have said your luminance trigger in the second event. The premise is still true.

Once the original event was started the specified conditions should dictate what actions are done. In this case my first action in the original event is to run the new event which it does. But I just don't get why it doesn't honor the conditions in the new event with that advanced option set to tell it to do so.

It honors the Condition (singular) of the second event, it ignores the trigger

If HS thinks allowing us to nest conditions and actions in a single event is more confusing than what ever this logic is I definitely disagree. I have never programmed in a language that didn't allow nested conditions / actions and if they called other events they always honored current conditions. I don't want to try and debate that part. I simply want to understand what this logic is that makes my second event fail to do what I want. Does my view of this make any sense?

I think once you wrap your mind around the clear and distinct difference between a Trigger and a Condition, it will all begin to make a lot more sense. The words at the beginning of a line determine whether it is a Trigger or a Condition, not the words after IF, OR IF, AND IF.

Now there are two ways to make your second event play well with your first. If you always want that light to go ON "IF Motion - Plus Front Porch Front Porch Luminance was set and has a value that is less than 5 lux", regardless of whether the first event is triggered then you could use the following:

IF The event will automatically trigger every 1m, 0s

AND IF Motion - Plus Front Porch Front Porch Luminance has a value that is less than 5 lux

(note the difference in wording when it is a condition, it no longer says was set and this is a good clue that it is no longer a trigger since it is no longer at the exact moment it is set)

AND IF Light Switch Front Door Front Door Over Head Light has a value equal to Off
THEN Set Device Front Door Front Door Over Head Light to On

This event would still turn the light on within a minute of the lux dropping below 5, it would not continually trigger because the lights value is a condition and when you call it from the first event the recurring trigger will be ignored and only the two conditions will be tested.


Your other option is if you want your second event to be valid only when called by the first is simply to change it to a manual trigger

IF This event is manually triggered

AND IF Motion - Plus Front Porch Front Porch Luminance has a value that is less than 5 lux
AND IF Light Switch Front Door Front Door Over Head Light has a value equal to Off
THEN Set Device Front Door Front Door Over Head Light to On

That way it will only run as a result of being called from the first event and will not run on its own.

I hope this makes sense - if not keep the questions coming

[Gunneyk]

OK now we are getting somewhere. I had no idea a trigger was defined by the line beginning with IF and OR IF and AND IF was the distinction for a condition. That explains a whole lot and now I understand why it is behaving the way it is. I don't necessarily agree with that. Most programming languages a "trigger" would be a change of some sort and any IF's would simply be expressions to evaluate (conditions) to decide on flow. I don't like how conditions and triggers are sort of lumped together in HS3. But at least now that I understand the premise I can at least deal with it thanks to your patience. I think your 2nd example of how to handle the called event is the way to go. I need to test that but it looks sound now that I know what it is looking for. One more thing. I always assumed that a manually triggered event was one that a human did in the gui. But I will now assume it means programmatically told to execute as well.

Thanks again for all the help

[randy]

OK now we are getting somewhere. I had no idea a trigger was defined by the line beginning with IF and OR IF and AND IF was the distinction for a condition. That explains a whole lot and now I understand why it is behaving the way it is. I don't necessarily agree with that. Most programming languages a "trigger" would be a change of some sort and any IF's would simply be expressions to evaluate (conditions) to decide on flow. I don't like how conditions and triggers are sort of lumped together in HS3. But at least now that I understand the premise I can at least deal with it thanks to your patience. I think your 2nd example of how to handle the called event is the way to go. I need to test that but it looks sound now that I know what it is looking for. One more thing. I always assumed that a manually triggered event was one that a human did in the gui. But I will now assume it means programmatically told to execute as well.

Thanks again for all the help

Good. Not to be rude, but it doesn't matter whether you agree or not - it is what it is. But I am pragmatic by nature. This is not a programming language, it is a multi-threading Event Engine.

I think much of the misunderstanding is because a lot of the HomeSeer users that are most active in this community are approaching this from previous programming experience. There are also plenty of others Who have no programming experience. It seems to me that the people who "get" it the fastest are those who approach it with virgin eyes. If HomeSeer is to thrive in the market, there a lot more potential customers who have no programming experience. That has to be their target. I hope (for all of our sake) that there is a much broader HS3 ownership that the 100 or so active posters on this board. I wouldn't be at all surprised if the larger percentage of current HomeSeer 3 users have not joined or even visited this board. Because I use my real name and location in my signature I have been contacted by a couple of users who found my posts through a Google search. Neither one is a member of this community yet.

While I understand what you are saying and that is the reason I am taking the time to write in-depth explanation of the event system, the logic is not "tortured", "clumsy" or "wrong". I also have a background where IF is a very specific beginning to a group of commands that are conditionally performed. That said, the logic used in the HomeSeer makes perfect sense to me, I just threw all of my past experience out and considered it a new language. I suppose you could think of IF to really mean WHEN, OR IF to mean OR WHEN and AND IF to mean IF, then it would look more like you expect it to.

In Event programming, which is a totally different beast than "conventional" programming languages, any event has to begin with a trigger. Logically there can be only one trigger for any set of Actions. HomeSeer expanded the capabilities by adding OR IF as a secondary trigger with a shared set of Actions, but its own set of Conditions.

With Multiple actions, one of them can be to run another event. Think of that as a "gosub" that can call another routine with its own Conditions. This gives you the nesting you need for multiple paths of Conditions from
a single trigger. I will fault HomeSeer's logic here, any Event called from another should by default have its Conditions respected. The option should be to ignore the conditions.

I will not accept that HomeSeer's logic is clumsy or wrong, it is simply a new language. I have been contacted by a number of people who have absolutely no programming skills and very little computer knowledge that understand HomeSeer with a very short learning curve. I've talked to them by phone, been to their houses and had remote desktop sessions with them. They have no expectation of how it should work, they just desperately want to know how it does work. Frequently an explanation of the logic is followed by an "ah ha" moment by the beginner. I think they benefit from their blank slate, where those of us with prior programming experience are hampered by assumptions.

A Manually Triggered event can certainly be one that "a human did in the gui", but that was not the intent of the designers. A Manually Triggered Event was designed to be called from another event or through HSTouch or some other interface. Think of it as control rather than automation. Since you can make any event in your system "one that a human did in the gui", because all of them have a button than can manually run them exclusive of Trigger or Conditions.

The beauty of this design where you can call an event with a trigger from another event and have it run, gives you potentially dual purpose events, they can operate when triggered or be forced to operate from another event without needing a trigger.

Since you are going for a Manually Triggered event for your second one, it shows me that you only wanted the second event to be called from another event. The way you had it written at the beginning of this conversation would have the light turning On any time the sensor had its value set to a value less than 5 lux, independent of the first event, That probably was not what you wanted.

[Gunneyk]

I don't take your replies as rude at all Randy. I prefer to hear straight talk than politically correct gibberish. There is nothing to say we have to agree on anything and that does not make either of us right or wrong when it comes to opinions and I certainly respect yours. Now that I know what is going on I will simply deal with it and move on. There is nothing wrong with a new or different language and yes I can see how it would be easier for someone who had no prior experience to pick it up as they have no preconceptions. But that is really my point or should I say my objection if you will to it. There are precedents to even things like flow control such as IF / OR / WHEN etc. You can even say these are pretty much industry standards. For HS to go against these standards and come up with their own form of these was a mistake in my opinion and is why we are having this conversation to begin with. They had the opportunity with HS3 to do what ever they wanted (which they did) and in my opinion if they made it more industry standard they could have still achieved their goals without confusing people with prior experience elsewhere. I used to use HAI with UPB in my previous house and while it was rock solid it felt a bit behind the times, especially from the gui standpoint. When I moved into this new house I had a blank slate although it had to be mostly wireless and is why I decided on Z-Wave. I looked around at about a half dozen vendors and originally decided on Zipato. Their interface is amazing and extremely intuitive as you can see from the screen shot of one of their rules. The allow for nesting with no problems and it is easy to tell a trigger apart from a condition. So they built their own version of an event driven language just like all vendors but they kept the core concepts or industry standards for the most part. I just wasn't expecting that with HS and a relatively new version of control software with HS3. If HS3 had an interface like Zipato I don't think they would have any trouble being and staying #1 in this industry. OK so I am done expressing my opinion as to why I don't agree with their direction and as to how I came to that opinion. It is after all just my opinion and no one has to agree with it.
Having said all of that the main reason why I switched from Zipato to HS is due to the support. Zipato was (and still is I think) getting started in the industry. As such they don't have a great support network yet and they had a lot of internal challenges they were in the process of overcoming such as a really great functioning web site. Having been with HS now for about 10 months I can't say enough about the support from not only the company itself but the people on the forums such as yourself. It is simply fantastic. I have been a Microsoft MVP for SQL Server for over 11 years now and I know what it means to have a support network like this for end users to have access to. Without it I don't believe a product such as HS can survive long term as there is just too much knowledge that comes only from experience. Initial users can easily get overwhelmed. Heck that is how I got to this thread in the first place. So once again thanks for all the help you and the others here give. It does not go unnoticed. And the second reason why I went with HS was they were one of the only ones who did not require a paid service or was totally reliant on a central server for day to day operation.

[scorp508]

I hate to perform a thread necropsy, but this thread was extremely helpful me as a HS3 newb. I was also looking at events from a programming background and getting infuriated at why AND IF and OR IF were not behaving as I expected them to. This has been very helpful, thank you!

[numgis]

Thanks for the good info in this thread, explains a lot.