Conditions & Branching? Cases and If-Then-Else

[Ltek]

I just purchased HS again after a long absence... I used HS 1.7 for a long time.

I have complex security integration and occupancy event logic needs.

I'm a bit surprised I'm not seeing the complex Branching I was hoping... in the form of If-Then-Else or Cases.

I saw Group Conditions but not sure that will really fill the gap?

Am I stuck with writing a lot of code or?

thanks for the help!

[MrMxyzptlk]

Nah, rather than go the route of every other programming language on the planet...they think their way is better. There are many detailed threads on this forum saying why they did what they did...blah blah blah.

It shouldn't be any more complicated...just different.

[randy]

Take a look at this thread. Especially post #6, it is an IF then Else, Else, Else....

It is very easy to have a single trigger that can launch multiple events with different conditions. I won't get into the whole blah, blah, blah explanation here, but there are good reasons why HS followed this path. Like MrMxyzptlk said, it is only different, not at all complicated.

Group Conditions are not working correctly.

[Ltek]

Take a look at this thread. Especially post #6, it is an IF then Else, Else, Else....

It is very easy to have a single trigger that can launch multiple events with different conditions. I won't get into the whole blah, blah, blah explanation here, but there are good reasons why HS followed this path. Like MrMxyzptlk said, it is only different, not at all complicated.

Group Conditions are not working correctly.

Thanks for the pointer. HS forces a lot of extra work vs just simply having If-Then-Else and Cases. Seems like there is a good reason every major programming language on earth has these.

Its unfortunate HS has not progressed the rules/events engine to have this functionality.

[sirmeili]

Thanks for the pointer. HS forces a lot of extra work vs just simply having If-Then-Else and Cases. Seems like there is a good reason every major programming language on earth has these.

Its unfortunate HS has not progressed the rules/events engine to have this functionality.

I will say this...

That is because every language (or all the ones I can think of) deal only in conditions. They check if existing values meet certain criteria in if statements. HomeSeer events start with triggers (a change in something) then allows you to check that conditions (existing criteria) are met before execution.

Sure, you could have if/then/else on the conditions, but you can never have this on the triggers and make it easy to understand for the average user. I think it's easy to say that triggers can have if/then/else, but then you have to consider how that would work. If your trigger is "A device is set and changed to Y", then is the "else" trigger every moment in time that that trigger is not true, or only when it is set and changed and it's not Y?

The way their system is set up lets you do multiple IFs, which, yes, might be more tedious to set up, but I would think is more understandable for the end user and less resource intensive.

That said, there is nothing from stopping you from using a more generic trigger and then using scipt (vb.net or c#.net) from having if/then/else logic in your script.


edit: and I'll also add that HomeSeer Event's are not a " programming language". I was at one point like you, but as I started to think about how it would actually work, I started to see why it is set up the way it is.

[randy]

Thanks for the pointer. HS forces a lot of extra work vs just simply having If-Then-Else and Cases. Seems like there is a good reason every major programming language on earth has these.

Its unfortunate HS has not progressed the rules/events engine to have this functionality.

As I wrote above, there are reasons why it is the way it is and they are logical to me. As sirmeili wrote above, it is an Event engine, not a programming language. At the root of it is that events are Trigger driven and there cannot be an else to a Trigger. A Trigger of 10:00PM is true for an instant, the Else to that Trigger would be true for the other 8.64e+7 (-1) milliseconds of the day.

Since an Else would need different Actions based upon Conditions imposed on the Trigger, it would take a convoluted and confusing structure within an Event to conditionally branch to different Actions. I honestly don't see how it could be easier than to branch off to different paths through supplemental called events.

I'll give you the same challenge Rick Tinker gave me in 2014 - describe how an "Else" would work in a HomeSeer event.

[Uncle Michael]

. . .and I'll also add that HomeSeer Event's are not a " programming language". I was at one point like you, but as I started to think about how it would actually work, I started to see why it is set up the way it is.

This is a really good point.

I find it convenient to think of an event as a "packet" of actions. As HS defines them, an event can have only one set of actions. So, if you want to take alternative actions, you need multiple events. There are ways to do that with chained events, as Randy noted in his earlier post. It is also important to remember that HS integrates scripting quite effectively, which provides a powerful way to incorporate complex logic that is cumbersome in the HS event environment.

[joelbean]

Catch 22?

I really did read this entire post and I have a programming background that makes me very familiar with both 3rd generation conditional constructs and event programming usually found in SQL-based programming.

I still have a problem with the following. In layman's terms, I want to do the following:

There are only two devices involved in the event/s: 1) HSM200 and, 2) any other on/off device.

1) Only have ONE check for the trigger "becomes motion" in the Homeseer catalog of events. Otherwise, I possible have one motion trigger running before the other causing sync problems.
2) Do stuff based on the motion trigger but ONLY if the luminance value is a user-specified value.
3) Change the color of the light on the HSM200 to blue when motion is triggered.

The problem that is caused by not having more conditional logic ability after a "then" action:

When I turn the HSM200 light to blue, it changes the luminance value higher than what I want to represent a dark room.

So, I want luminance BEFORE turning the HSM200 light on, THEN check its value. In conventional programming, I could do the following:

If motion
then poll HSM200 for luminance
then change the light on the HSM200 to blue
then
if luminance value is < x
and if the on/off device if off
then turn the on/off device to on

Remember that I only want ONE motion trigger check for everything, including nothing but changing the HSM200 color light.

I can't figure out how calling another event based on the motion trigger can get me there.

Help please.
Thanks,
Joel

[Uncle Michael]

So, I want luminance BEFORE turning the HSM200 light on, THEN check its value. In conventional programming, I could do the following:

If motion
then poll HSM200 for luminance
then change the light on the HSM200 to blue
then
if luminance value is < x
and if the on/off device if off
then turn the on/off device to on

I see at least two options.

The first option is to run a script from the event that responds to motion. The script would contain the logic as you've laid it out.

The second option would involve two events and a virtual device.
The first event has four actions:
- transfers the luminance value to the value of the virtual device
- wait to allow that to occur (probably milliseconds)
- change the HSM200 to blue
- trigger the second event, if the event conditions are true
The second event has the condition that the virtual device value is less than the threshold and has the action to turn the on/off device to on.

[mulu]

I was just searching about If-else if-else if-...-else constructs. I read that other thread from Randy and see how he is approaching this, i.e. have the trigger and common conditions in one event. Then create events for each possibility and call each of those events with only one of them being executed. I can see where this can be of advantage, i.e. when you want to use these other events in other places or if you want to execute 1 or more of those sub-events, depending on conditions. It allows some flexibility.
Having said that, I don't think that a good way to handle 'traditional' if-else if... cases. I have cases where I don't need to reuse all those different possibilities. But now instead of creating 1 event that allows if-else if constructs I need to create a bunch of events. It's more work and unintuitive. I also don't buy the argument that HS is different to other programming languages because it's event driven. Yes, it is event driven and you really can only have one event but there can be many different actions taken depending on the status of other devices. So in my opinion the if-else if still makes a lot of sense. Just my two cents.

[randy]

Catch 22?

I really did read this entire post and I have a programming background that makes me very familiar with both 3rd generation conditional constructs and event programming usually found in SQL-based programming.

I still have a problem with the following. In layman's terms, I want to do the following:

There are only two devices involved in the event/s: 1) HSM200 and, 2) any other on/off device.

1) Only have ONE check for the trigger "becomes motion" in the Homeseer catalog of events. Otherwise, I possible have one motion trigger running before the other causing sync problems.
2) Do stuff based on the motion trigger but ONLY if the luminance value is a user-specified value.
3) Change the color of the light on the HSM200 to blue when motion is triggered.

The problem that is caused by not having more conditional logic ability after a "then" action:

When I turn the HSM200 light to blue, it changes the luminance value higher than what I want to represent a dark room.

So, I want luminance BEFORE turning the HSM200 light on, THEN check its value. In conventional programming, I could do the following:

If motion
then poll HSM200 for luminance
then change the light on the HSM200 to blue
then
if luminance value is < x
and if the on/off device if off
then turn the on/off device to on

Remember that I only want ONE motion trigger check for everything, including nothing but changing the HSM200 color light.

I can't figure out how calling another event based on the motion trigger can get me there.

Help please.
Thanks,
Joel

I realize this is a 9 month old post, but I didn't see it the first time around. I also realize the poster has not been back since March. This is actually quite easy. You don't need to poll an HSM200, it reports on a schedule. A single motion trigger can be true in many Events at the same time. It is my understanding that Events are queued by Trigger. If there are six events using the same Trigger, they will all 6 be spun off in individual threads essentially at the same time.

Event 1
IF motion
AND IF luminance value is < x
AND IF the on/off device if off
THEN turn the on/off device to on

Event 2
IF motion
THEN change the light on the HSM200 to blue

This is how the HomeSeer Event Engine works. It may not be speaking the language you are used to, but it is a very capable language. It is what it is. I do not defend the language and there are some simple things that could be changed/added to make it better. I do not agree that a lot of branches within an Event is easier or more intuitive than an Event that branches off to other Events. Either way, you have to filter through all the conditions to end up with a particular action.

[ericg]

As I wrote above, there are reasons why it is the way it is and they are logical to me. As sirmeili wrote above, it is an Event engine, not a programming language. At the root of it is that events are Trigger driven and there cannot be an else to a Trigger. A Trigger of 10:00PM is true for an instant, the Else to that Trigger would be true for the other 8.64e+7 (-1) milliseconds of the day.

Since an Else would need different Actions based upon Conditions imposed on the Trigger, it would take a convoluted and confusing structure within an Event to conditionally branch to different Actions. I honestly don't see how it could be easier than to branch off to different paths through supplemental called events.

I'll give you the same challenge Rick Tinker gave me in 2014 - describe how an "Else" would work in a HomeSeer event.

The above post was written before I ever heard of HomeSeer, but the if/then/else issue seems perennial. I note also that arguments against addition of if/then/else constructs to an event definition appear almost proportional to the number of posts the author has filed. Since I am a relative Newbie, count me as one of the group that would like to see the event definition language extended to include if/then/else functionality. I accept the Rick Tinker / Randy Prade challenge.

It strikes me that Randy's infeasibility argument above is something of a straw man: "At the root of it is that events are Trigger driven and there cannot be an else to a Trigger. A Trigger of 10:00PM is true for an instant, the Else to that Trigger would be true for the other 8.64e+7 (-1) milliseconds of the day." Well, yes, but I think that begs the question.

There are two major parts to an event definition. There is the trigger section that determines whether an event is to be executed or ignored. Then there is the action section, which determines what is to be done should the trigger section satisfy the requirements for event execution.

The if/then/else functionality I (and I suspect, others) would like to see would appear not in the trigger section, but rather, in the actions section. Presently, the actions section is limited to just two constructs: THEN (do something) and WAIT (before doing something). As I understand it, action processing consists of gathering up all the THEN actions appearing before the next WAIT (if any), throwing them to an action processor which carries them out in helter-skelter order. Then, after any WAIT, rinse and repeat. But the entire action sequence is essentially linear -- it makes no provision for conditional branching, which can be extremely useful.

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.

In my personal estimation, these are the major pros and cons of an if/then/else proposed event definition enhancement:

1. A properly designed event language extension would be fully compatible with legacy definitions. No worries there.
2. I believe that a reasonably sophisticated user with a currently large (say, > 1000>) event set would find that, over time, both the number of his events and their combined character count would become significantly reduced and more easily maintained.
3. A more sophisticated event definition syntax violates the KISS principle, which is so important to the casual user. An obvious mitigation would be use of the familiar bird/airplane construct to hide or allow the extensions.
4. If implemented properly, system overhead of extended event definition syntax compared to existing methods to achieve equivalent function would be essentially a push.
5. It is usually advantageous, where possible, to encompass the requirements of a relatively complex event process within a single event definition, as opposed to a set of separate, interacting events. Easier to create, to read, and to maintain. This is especially true when one considers the not insignificant challenges of interevent timing -- and even execution -- anomalies.
6. There is a very good argument that anybody who wants if/then/else capability should be doing it with scripts. Since I'm not there, yet, I'll defer for now.

Over a long professional career, I have had many confrontations with NIH syndrome, and I have no reason to suspect the principle would not be applicable here. I offer this post mainly in defense of those of us who would like to see an enhanced event definition syntax. Of course it can be done!

[Wade]

...Of course it can be done!

Thoughtful and well-articulated.

[Ltek]

ericg well said... Completely agree! Unfortunately Homeseer seems stuck in thier old ways. The plugin developers are the only ones adding anything innovative to Homeseer. It's been the situation for years

[Guest]

Look on Jeedom side (Google translate)
https://jeedom.github.io/core/fr_FR/scenario

Else conditions , loops ...