Conditions & Branching? Cases and If-Then-Else

[Uncle Michael]

Suppose the trigger section were left as is -- no arguments there, no compatibility problems. But also suppose that the action part of the event definition language were enhanced with the inclusion of if/then/else constructs. There still would be no compatibility problems with legacy event definitions, because legacy definitions would be a subset of the enhanced specification. I submit, however, that the potential for simplification of a user's entire event suite is simply enormous.

Examples are easy to create, but consider this one:

<TRIGGER section:>
IF <driveway motion detected>
AND IF <nighttime>

<ACTION section:>
THEN <turn on driveway lights>
THEN IF <household asleep>

THEN <turn on master bedroom bed stand lamp>
THEN<activate warning system beeper>

ELSE IF <home occupied>

THEN <turn on front porch light>
THEN <activate doorbell>

ELSE

THEN <activate armed response security system>

ENDIF

The example, of course, presumes just one of many possible syntax schemes. The syntax choice is not particularly important, as long as it is easily parsed.

Of course it can be done!

Yes, it can. And if you accept the syntax scheme that is inherent in HS3, it can be done today.

For example:
THEN <turn on driveway lights> is unchanged

THEN IF <household asleep>

THEN <turn on master bedroom bed stand lamp>
THEN<activate warning system beeper>

becomes:

Then If the Event Conditions are True, Run Event <Asleep Motion>,
where the Event <Asleep Motion> is,

IF This Event is Manually Triggered
And If <household asleep>
Then <turn on master bedroom bed stand lamp> and
Then <activate warning system beeper>

ELSE IF <home occupied>

THEN <turn on front porch light>
THEN <activate doorbell>

becomes

Then If the Event Conditions are True, Run Event <Occupied Motion>,
where the Event <Occupied Motion> is,

IF This Event is Manually Triggered
And If <home occupied>
Then <turn on front porch light>
Then <activate doorbell>

ELSE

THEN <activate armed response security system>

ENDIF

becomes

Then If the Event Conditions are True, Run Event <UNOccupied Motion>,
where the Event <UNOccupied Motion> is,

IF This Event is Manually Triggered
And If <home unoccupied>
Then <activate armed response security system>

[ericg]

Yes, it can. And if you accept the syntax scheme that is inherent in HS3, it can be done today.

Agreed. So, which do you like better?

[Uncle Michael]

Agreed. So, which do you like better?

I use the scheme I laid out. It works quite well, and by calling events like subroutines rather than embedding everything in one event, I've found that in some cases I can actually make use of the "sub" events independently as well.

To be clear, If/Then/Else logic is impractical for TRIGGERS (Randy's point), but I agree that for CONDITIONS (your example) it would be a reasonable addition. It's absence, though, is not a serious problem for me, and there are other capabilities that I'd put higher on my priority list.

Also, using If/Then/Else capability for event conditions would not be my preference when I encounter a need for complex logic. In that situation I would continue to use a script that incorporates the needed logic.