Feedback Request: Conditional Actions

[Ltek]

macromark Can we end this conversation and get the feature put in and tested? I think the majority of us want If-Then logic (every programming language uses this for a reason)... and some of us would like CASE added since its a efficient and effective way to represent that type of logic.

[macromark]

OK so... putting the conditions above the actions appears to be the preferred configuration for the Actions section. Also, I like the suggestion of putting "THEN" blocks between the condition/action groups to better separate them. It was also suggested that differentiating the "master trigger" from the conditions below by using "WHEN" instead of "IF" might be a good option. I have also changed the color coding of the master trigger to red to further emphasize this. Have a look and let me know what you think.

[macromark]

macromark Can we end this conversation and get the feature put in and tested?...

No. This feature really needs to be scoped out before we jump into coding and getting feedback from everyone will help to ensure that what we end up doing makes the most sense to the most people. So... we'll keep talking until we get a good handle on it.

[stefxx]

OK so... putting the conditions above the actions appears to be the preferred configuration for the Actions section. Also, I like the suggestion of putting "THEN" block between the condition/action groups to better separate them. It was also suggested that differentiating the "master trigger" from the conditions below by using "WHEN" instead of "IF" might be a good option. I have also changed the color coding of the master trigger to red to further emphasize this. Have a look and let me know what you think.

Looks great! Too bad you've ignored the requests for ELSE, but hey I guess that will be the next most voted requested feature . Seriously, if it gets implemented as shown here, it will be a great addition to HS4!

[macromark]

Looks great! Too bad you've ignored the requests for ELSE, but hey I guess that will be the next most voted requested feature . Seriously, if it gets implemented as shown here, it will be a great addition to HS4!

Thanks and I agree!

BTW, not ignoring the "else"... would be a good "round 2" addition.

[John245]

Thanks and I agree!

BTW, not ignoring the "else"... would be a good "round 2" addition.

I also like the ELSE or ELSE IF.

Looking forward to the 1st round.

---
John

[ksum]

Regarding the ELSE request
I can see this as being problematic:

IF the Time Is X (Will run at that time only)

Do Something

ELSE

Do Something Else

This is only one example of the many instances where Else causes problems. It seems the use of a second Event is more straightforward for Else uses which are actually opposite triggers.

As for the display, I found randy 's option to be unintuitive. It seems that is sating "Set These If this is also true." I do not believe most people think this way. I would suggest, therefore, the following, minus the red symbols.:


Also, I would suggest that the last IF Conditional Block (marked with a star) Is run if the first IF Conditional Block (marked with a diamond) is executed and sets the Outside Garage Overhead light On and the Garage Door is Open. Meaning if, at the time of the initial Trigger, this light was Off and it is a Weekday, it is now On and therefore any Condition following the one marked with a diamond evaluates the light as being On as it is now set to On from said diamond Condition. (hopefully this makes sense) If this logic is not used and the Initial Values of all Devices Prior to the Event being Triggered are used for all Conditional Evaluations, then there is no reason for the Action which Starts a Timer needs to be in the middle of the groupings. In that case, all Actions made with no Conditions should happen first to further simplify reading the Actions.

[Steveo369]

OK so... putting the conditions above the actions appears to be the preferred configuration for the Actions section. Also, I like the suggestion of putting "THEN" blocks between the condition/action groups to better separate them. It was also suggested that differentiating the "master trigger" from the conditions below by using "WHEN" instead of "IF" might be a good option. I have also changed the color coding of the master trigger to red to further emphasize this. Have a look and let me know what you think.

Looks great. Is the plan to also be able to implement multiple actions within each THEN group? Still unsure on this. See my previous post Number 44 (https://forums.homeseer.com/forum/ho...08#post1568908).

[ksum]

I like the WHEN and additional color coding. That was posted while I was making my last response. I also like the THEN breaks.

My comment regarding the Evaluation of Devices in each Conditional Block is still apparently open, though, and I think not understood in my first posting of such. In the example from macromark, if an earlier block in this same event opened the Outside Garage Door there becomes 2 possibilities for the last Condition:

1. The Garage Door was closed before the Event starts and is evaluated as Closed
2. The Garage Door has since been Opened and therefore evaluates as Open

Which of the 2 above conditions are True for a Garage Door Possibly Opened at an earlier point in the Event?

[randy]

I like Triggers being WHEN. It clearly differentiates the Triggers from the Conditions. I also like the color differentiation among elements with the tags in grey. I do not see the need to outline the blocks, it just makes it busier. There are plenty of visual clues to make the flow of the Event clear in the sample.

I agree that it would be useful to have multiple Actions in each Conditional Action block.

Else would only work on conditions, it wouldn't for triggers. It could be useful for conditions and should be reasonably easy to implement within this new structure.

This:

WHEN It is 8:00PM

THEN
IF The house is occupied
Set the living room track lights to 50%
THEN
IF The house is not occupied
Set the living room track lights to 60%

Becomes:

WHEN It is 8:00PM

THEN
IF The house is occupied
Set the living room track lights to 50%
ELSE
Set the living room track lights to 60%

[upstatemike]

I like the WHEN and additional color coding. That was posted while I was making my last response. I also like the THEN breaks.

My comment regarding the Evaluation of Devices in each Conditional Block is still apparently open, though, and I think not understood in my first posting of such. In the example from macromark, if an earlier block in this same event opened the Outside Garage Door there becomes 2 possibilities for the last Condition:

1. The Garage Door was closed before the Event starts and is evaluated as Closed
2. The Garage Door has since been Opened and therefore evaluates as Open

Which of the 2 above conditions are True for a Garage Door Possibly Opened at an earlier point in the Event?

I would think the state of all conditions at the point of the Master Trigger is what would be evaluated, so option 1. If conditions are allowed to alter state mid-event the outcome could be hard to predict and unpleasant to troubleshoot. The order of your "And If" statements would also become super critical.

[stefxx]

Regarding the ELSE request
I can see this as being problematic:

IF the Time Is X (Will run at that time only)

Do Something

ELSE

Do Something Else

This is only one example of the many instances where Else causes problems. It seems the use of a second Event is more straightforward for Else uses which are actually opposite triggers.

The ELSE is not relevant for triggers. As your example clearly shows, I believe that is the main reason why ELSE was never implemented before.

However, for the new conditions (which we are discussing here) it makes perfect sense. I have multiple examples of complicated conditions, and then a second event (with the same trigger) testing the exact opposite condition. Using an ELSE would make it soo much simpler and easier to implement and read.

[Steveo369]

I like Triggers being WHEN. It clearly differentiates the Triggers from the Conditions. I also like the color differentiation among elements with the tags in grey. I do not see the need to outline the blocks, it just makes it busier. There are plenty of visual clues to make the flow of the Event clear in the sample.

I agree that it would be useful to have multiple Actions in each Conditional Action block.

Else would only work on conditions, it wouldn't for triggers. It could be useful for conditions and should be reasonably easy to implement within this new structure.

This:

WHEN It is 8:00PM

THEN
IF The house is occupied
Set the living room track lights to 50%
THEN
IF The house is not occupied
Set the living room track lights to 60%

Becomes:

WHEN It is 8:00PM

THEN
IF The house is occupied
Set the living room track lights to 50%
ELSE
Set the living room track lights to 60%

I like this, but we are also using a relatively simple Event example. I think we also need some mock ups with multiple triggers and conditions. I could see the WHEN and IF constructs getting confusing between Event wide conditions and Action specific conditions. (Maybe a different font or italics for Action specific conditions?)

[randy]

I like the WHEN and additional color coding. That was posted while I was making my last response. I also like the THEN breaks.

My comment regarding the Evaluation of Devices in each Conditional Block is still apparently open, though, and I think not understood in my first posting of such. In the example from macromark, if an earlier block in this same event opened the Outside Garage Door there becomes 2 possibilities for the last Condition:

1. The Garage Door was closed before the Event starts and is evaluated as Closed
2. The Garage Door has since been Opened and therefore evaluates as Open

Which of the 2 above conditions are True for a Garage Door Possibly Opened at an earlier point in the Event?

I saw this as a potential problem as well, controlling a device in one action and evaluating the same device in a subsequent conditional action within the same event. I honestly think this is something that should be avoided as a best practice. I'm not sure this should be controlled programmatically. I don't know how HomeSeer is handling Actions, but they used to all be launched in threads, virtually simultaneously. As a result the execution order of Actions was not assured. If they are all spun at once when the Event runs, they will all be evaluated at the time the Event is triggered. Regardless, all Conditions should be evaluated at the moment the Event runs.

[Steveo369]

I would think the state of all conditions at the point of the Master Trigger is what would be evaluated, so option 1. If conditions are allowed to alter state mid-event the outcome could be hard to predict and unpleasant to troubleshoot. The order of your "And If" statements would also become super critical.

I tend to disagree. Conditional Actions are mostly functionally equivalent to calling an Event from another Event. Couldn’t a user already create the problem you mention with calling multiple Event Actions sequentially in an Event?

The conditions are evaluated at the time the Event (or Conditional Action) is called. Ordering of Actions has always been important in Event creation. Perhaps it becomes more important with Conditional Actions, but it’s already’ baked in’ to HS.