Else statements?

[rrehart01]

I'm new to HS (coming from ISY), and have been toying with Events. In the ISY, there was the ability to add "Else" to the If/then statements. I don't see that as an option here. How is that done?

Example: IF Light A is on, AND IF Light B is on, THEN execute an event... ELSE execute a different event.

Is "Else" possible within HS?

[mikee123]

Nope. Unfortunately not. You have to create another event

[rrehart01]

Nope. Unfortunately not. You have to create another event

Meh. That could get messy. Feature request, I suppose. Thanks.

[jvm]

No, there is no "else". User's typically have to write another "If" statement to get an "else"-like desired response.

[jvm]

Meh. That could get messy. Feature request, I suppose. Thanks.

As an FYI - an "else" has been requested and discussed a number of times in the forums. Bottom line as I understand it is that it isn't clear how to implement an "else" that would be logical and give an consistent expected result. As a simple example, looking at the If ... Then ... Else you wrote in Post #1, would the "Else" trigger continuously when A or B is off, or would it trigger only once if A turned On while B is Off (or vice versa), or something else? The combinations / permutations of this are endless and grow with each additional condition in the event so it has never been clear how this could be solved in a logical manner.

[rrehart01]

As an FYI - an "else" has been requested and discussed a number of times in the forums. Bottom line as I understand it is that it isn't clear how to implement an "else" that would be logical and give an consistent expected result. As a simple example, looking at the If ... Then ... Else you wrote in Post #1, would the "Else" trigger continuously when A or B is off, or would it trigger only once if A turned On while B is Off (or vice versa), or something else? The combinations / permutations of this are endless and grow with each additional condition in the event so it has never been clear how this could be solved in a logical manner.

I see the point, but never personally ran into that with the ISY. My Else statements were finite (run once); meaning once it was run, the "IF" part of the statement would have to run again to allow it to check the conditions again (and therefore possibly run the Else again).

Regardless, since I can't run Else statements, it makes me wonder about nested IF statements. Meaning, is it possible to nest an IF statement within another to check two conditions prior to running the event, OR do the IF statements run in sequential order:

Ex Sequential:

1. IF Light A = x
2. OR IF Light B = y
3. AND IF Light A >< OFF
4. OR IF Light B >< OFF
5. Then xxxxx

Ex Nested:

AND (
Light A = x
Light B >< OFF
)
OR (Light B = y
Light A >< OFF
)
THEN
[ACTION]

[sirmeili]

"IF" and "OR IF" statements are "triggers". They trigger an event. the "AND IF"s are conditions tied to a trigger.

So, "If Kitchen Motion sensor changes and becomes motion AND IF Kitchen light is Off...."

The only time that event is triggered is when the Kitchen motion sensor changes. If it changes and is "Motion" it will check the conditions, in this case if the kitchen lights are off. If both are true, it will run the event. If you turn the Kitchen lights off, it won't trigger the event.

It takes a while of getting used to it, but it will make sense. You can simulate nested IFs by calling other events from your event.

You can read about nested events here: https://forums.homeseer.com/forum/ho...ondition-paths

rprade (Randy) has done a great job documenting most of the event system. You can find the TOC here: https://forums.homeseer.com/forum/ho...le-of-contents

[bsobel]

Hi Neighbor (I live in Jamul and Rosarito), and also came from the ISY.

A couple thoughts for you;

First if you haven't migrated from the ISY, there is an ISY plugin which gives you HS devices for your devices, programs, variables, modules, etc. It definitely helps in the migration (you can keep your ISY programs even, their state of true/false being reflected in the HS devices). Its what I used to migrate and still use today (albeit more of my events are on the HS side now)

The HomeSeer design is somewhat similar to ISY, there is a trigger state and then conditions. A trigger has to occur for the other conditions to even be considered. In HS every first statement in a block separated by an OR is a trigger, everything else is a condition. so:

If Light A is changed to ON (trigger)
And Light B = ON (condition)
then

What this generally means, is that the 'Then' will only run when the A light is turned on. If A is already On then B turning on won't run the then. To make the condition on either you need both cases as triggers:

If Light A is changed to ON (trigger)
And Light B = ON (condition)
Or
If Light B is changed to ON (trigger)
And Light A = ON (condition)
then

There are plugins to extend this system to simplify this (EasyTrigger is a very popular one, I also have one called Tags that allows you to create a group of device (e.g. A and B) and trigger on changes to either.

Lastly, the one thing that is here that ISY cant touch is scripting. I find the Event system useful for a certain level of event writing, but as soon as I have more than a couple devices involved, I almost always write a script. The script can access pretty much everything and make any calculation and decisions you need (with full program if/then/else/loop support). If you could program ISY programs, you can definitely write VB scripts, so definitely check them out.

Cheers,
Bill

[bsobel]

As an FYI - an "else" has been requested and discussed a number of times in the forums. Bottom line as I understand it is that it isn't clear how to implement an "else" that would be logical and give an consistent expected result. As a simple example, looking at the If ... Then ... Else you wrote in Post #1, would the "Else" trigger continuously when A or B is off, or would it trigger only once if A turned On while B is Off (or vice versa), or something else? The combinations / permutations of this are endless and grow with each additional condition in the event so it has never been clear how this could be solved in a logical manner.

The general approach to an else is if the trigger fires but the conditions don't match, run the else (which ideally could have its own conditions). This way the invocation is known and doesn't break the world with infinite loops, etc.....

[drparker151]

My guess is a major rewrite to the event engine would be needed. The system would need to track trigger type events differently than if, then, else events. For the else part to work, it would also have track state of current conditions as a true/false boolean. so that when all conditions were true the event would be true, then it could react to a change from true to false and execute the else only once.

[rprade]

While I understand what you are asking for, I also understand why it cannot be implemented with HomeSeer's Event structure being based upon Triggers. While I could envision building branching into an Event after the Trigger, the Trigger must still be the starting point, there can never be an "Else" to a Trigger.

WHEN it is Sunset

IF the house is occupied
turn the lights On
ELSE
turn the lights off

Could be done in a single Event.

If there were even more complex branching within an Event, I could imagine the Event becoming so cluttered that it might be difficult to understand.

HomeSeer's approach is different than branching within an Event, but I would posit that it is no more or less difficult to understand or implement. The above situation could be represented by one of two different approaches

Event 1
IF it is Sunset

AND IF the house is occupied
THEN turn the lights On

Event 2
IFt is Sunset

AND IF the house is NOT occupied
THEN turn the lights Off

Another method would be:

Event 1
IF It is sunset
THEN Run Event 2 if the conditions are TRUE
THEN Run Event 3 if the conditions are TRUE

Event 2
IF This Event is Manually Triggered
AND IF the house is occupied
THEN turn the lights On

Event 3
IF This Event is Manually Triggered
AND IF the house is NOT occupied
THEN turn the lights Off

Obviously for only two branches the first examples are easier, in the case of multiple branches the second set of examples might be better. This is an individual choice.

Either way they are really no more difficult to deploy or understand than combining it all within single Event.would be, it is just a different language.

In this thread, I attempt to explain how it works in HomeSeer. While a simple situation like controlling lights based on occupancy could be done within a single Event, a very complex set of conditional Actions as represented in that thread, would be very difficult to implement within a single Event. HomeSeer simply made a decision as to how they wanted to handle branching.

Just as someone who speaks English might struggle with the structure of Spanish, both languages are as they are. In order to speak either one, you work within the rules of that language.

[rprade]

I would also want to hear what happens to my 1400+ perfectly functioning Events if HomeSeer was to completely restructure Events to accommodate branching (after the initial Trigger) within the Event.

[bsobel]

I would also want to hear what happens to my 1400+ perfectly functioning Events if HomeSeer was to completely restructure Events to accommodate branching (after the initial Trigger) within the Event.

Nothing. Else as I described is actually easy to add. None of your events would have else clauses unless you added them. Perfectly compatible.

[sirmeili]

Nothing. Else as I described is actually easy to add. None of your events would have else clauses unless you added them. Perfectly compatible.

How do you handle multiple triggers? (OR IFs). Do you say if any of them are triggered but their conditions not met then run the Else?

I think it adds a level of complexity to the event system that would confuse new users, especially if they don't have a programming background.

[mikee123]

Originally I also wanted a 'else', but got used to the logic as it is. It works fine, its just split into different events which gives you other possibilities again, like calling the 'part event' from other events etc. Once you got used to it, you dont really miss it any more, its easy to work with the event engine and it can do whatever you want