Is there an "ELSE IF" conditional for events?

[wkearney99]

I'm just beginning with the events here, and have done no scripts as yet. But I've 4 decades of past programming experience, so I know a few things.

Is there an ELSE IF condition for events?

As in, If a motion sensor has had it's value changed to X then do something else if the value is y do something else.

I see if, or if, and if, but no else if.

[Rupp]

You need to set up separate events for each of the else ifs

[randy]

I'm just beginning with the events here, and have done no scripts as yet. But I've 4 decades of past programming experience, so I know a few things.

Is there an ELSE IF condition for events?

As in, If a motion sensor has had it's value changed to X then do something else if the value is y do something else.

I see if, or if, and if, but no else if.

As Rupp said above, it takes multiple Events. You can nest events for conditional IF/ELSE logic.

For Trigger IF/ELSE logic it is different. Using your example above "If a motion sensor is set to motion", think about what an Else If would be, an Else would be any time it is not "motion", so it would trigger all of the time the device is not detecting motion. If you are wanting something to trigger and have different actions when the motion sensor changes to "no motion", you would simply build another completely separate event.

Look at the table of contents post in this forum for discussion about Triggers, Conditions and event logic.

[Uncle Michael]

. . . think about what an Else If would be, an Else would be any time it is not "motion", so it would trigger all of the time the device is not detecting motion.

Randy,
I think the question is more about devices that have more than two states, or even the states of multiple devices.

The issue is that the HS event processing algorithm allows only one set of event actions for an event. If you want to produce a different result from a different trigger, a new event is required. I see it more as a structural requirement than a limitation.

[randy]

Randy,
I think the question is more about devices that have more than two states, or even the states of multiple devices.

I suppose it is possible, but with his example of a motion sensor, it seemed to me it was a two state device. He also wanted to perform different actions based upon the two values.

Is there an ELSE IF condition for events?

As in, If a motion sensor has had it's value changed to X then do something else if the value is y do something else.

I see if, or if, and if, but no else if.

The issue is that the HS event processing algorithm allows only one set of event actions for an event. If you want to produce a different result from a different trigger, a new event is required. I see it more as a structural requirement than a limitation.

Which is why I wrote above: "If you are wanting something to trigger and have different actions when the motion sensor changes to "no motion", you would simply build another completely separate event."

[wkearney99]

For Trigger IF/ELSE logic it is different. Using your example above "If a motion sensor is set to motion", think about what an Else If would be, an Else would be any time it is not "motion", so it would trigger all of the time the device is not detecting motion.

No, not if the motion sensor has a time out for vacancy detection. As in, motion detected as one event and then it sends another, different event, when vacancy is detected. It's not going to send the second event unless the first has already occurred.

[randy]

No, not if the motion sensor has a time out for vacancy detection. As in, motion detected as one event and then it sends another, different event, when vacancy is detected. It's not going to send the second event unless the first has already occurred.

There you have the answer. Even the very fast PIRs I use have a few seconds when they are in one state or another. You are talking about triggers or the exact moment a device changes state. As I said above HomeSeer does not have the ability to chain an event off into different actions, all events share common actions - when the event is true (trigger occurred, conditions met) it runs all actions. You can have multiple (IF/OR IF) triggers, but they will share common actions.

With that in mind the event you are describing:

IF motion sensor is set to motion
THEN do this and that

Else IF (assuming this is when it changes to no motion)
THEN do the other

Is simply constructed as two events:

Event 1
IF motion sensor is set to motion
THEN do this and that

Event 2
IF motion sensor is set to no motion
THEN do the other

I understand this doesn't feel the same as IF/ELSE in traditional programming, but it really does make sense in multi threaded trigger driven event processing.

In traditional programming if the IF is not true the ELSE is. When you are dealing with triggers, the IF is only true at the exact moment as that state becomes true, then neither the IF or the ELSE are true, followed by the ELSE becoming true at the moment the IF state becomes false (or the ELSE state becomes true). Since HomeSeer spins off a thread when an event is run, it makes more sense for the ELSE to be a separate event, since it likely shares little other than possibly some Conditions with the IF.

[wkearney99]

There you have the answer. Even the very fast PIRs I use have a few seconds when they are in one state or another.

Not the case here, it fires events based on it's own processing.

HomeSeer spins off a thread when an event is run, it makes more sense for the ELSE to be a separate event, since it likely shares little other than possibly some Conditions with the IF.

Yes, if they're not sharing any processing.

It's an age-old problem of managing resources. Lots of systems will merrily let you create all manner of tasks. Most end up making a mess as the processing for events, especially ones dependent on time, chew up cycles. Being efficient with resources means understanding just how to avoid making a mess.

This also becomes an issue when considering 'state'. As in, tasks firing depending on the house being in a particular mode. Simple things like Home or Away, but potentially a lot of others involving overlaps with Security status. The logic starts getting complicated, even more so if planning isn't done for them at the outset.

[Uncle Michael]

It's an age-old problem of managing resources. Lots of systems will merrily let you create all manner of tasks. Most end up making a mess as the processing for events, especially ones dependent on time, chew up cycles. Being efficient with resources means understanding just how to avoid making a mess.

This also becomes an issue when considering 'state'. As in, tasks firing depending on the house being in a particular mode. Simple things like Home or Away, but potentially a lot of others involving overlaps with Security status. The logic starts getting complicated, even more so if planning isn't done for them at the outset.

I'm getting confused. Are you concerned about managing multiple events? Computing resources? Both?

I agree that adding events has the potential to become an unruly mess, but it doesn't have to with good planning.

As far as computing cycles are concerned, I'd need to know much more about how HS works 'under the hood' to be able to draw any firm conclusion. All software systems involve some compromise, but if the event engine is well designed, then it seems to me that dividing the processing into event 'bites' as HS does has the potential to be a very efficient method for minimizing overhead.

[Uncle Michael]

It might be instructive to explore an example scenario where an Else If structure would be advantageous over a group of individual events.
It would be especially useful to see an enumeration of just how the two alternatives compare in terms of complexity and efficiency.

It's also useful to keep in mind that there are times when it may be more appropriate to use a script rather than a group of events. Although scripts bring their own construction and maintenance overhead, they are often worth the extra trouble for handling complex logic.

[randy]

Not the case here, it fires events based on it's own processing.

I am assuming by processing, you are referring to the adjustable timeout before showing no motion. My PIRs have essentially the same processing, but it is fixed at a couple of seconds. In either case the processing is simply the amount of delay imposed before the PIR changes state to no motion after a motion event

We can keep going around on this, but I am just trying to state how HomeSeer IS, not debating how it could be. Your original question was "Is there an "ELSE IF" conditional for events?". The answer is no. There are ways to accomplish whatever you want to do in HomeSeer, using Events, plug-ins and/or scripting, but you cannot have an ELSE in an event. For motion sensors, the event logic usually consists of two events - one that fires when there is motion and a second that fires when there is no motion. For lighting a lot of us use additional event logic such as removing and creating delayed device actions to create a time window for lights to remain on when no motion is detected.

It is also important to avoid concern about the number of events, because evaluating an event takes very little resources because they are trigger queued. An event is not evaluated further until the trigger occurs and even when the trigger is true, the conditions must also be evaluated true before the event uses any significant amount of CPU cycles. I currently have over 1600 devices and over 1300 events, yet the biggest consumer of CPU cycles is the plug-ins.

[wkearney99]

I agree that adding events has the potential to become an unruly mess, but it doesn't have to with good planning.

...I'd need to know much more about how HS works 'under the hood' to be able to draw any firm conclusion.

One without the other leads to trouble.

This leads to questions about what scenarios are to be considered for group events.

[randy]

One without the other leads to trouble.

This leads to questions about what scenarios are to be considered for group events.

Assuming you are referring to Group Actions or Group conditions, you can use them any time you feel they would save you time in building events. They do not introduce any advantage in terms of processing efficiency, but can be an advantage if you have quite a number of events that share quite a few common conditions, or if you want to be able to easily change a condition that is used across a large number of events. I have never found group actions or conditions to offer any compelling value.