Feedback Request: Conditional Actions

[macromark]

Based on our HS4 Feature Poll, the most popular popular feature request is for Conditional Actions. As such, we're scoping that feature now and we'll be looking for feedback along the way. Please read through the information below and post to this thread if you have suggestions that might help this effort. Thanks in advance!

Conditional Actions

HS4 event conditions are currently applied only to triggers. Because of this, multiple events often must be created for any given trigger based on the desired behavior for actions. Consider the following scenario for what I normally do when motion is sensed in my garage:

Event 1
If motion is sensed in the Garage (trigger)
AndIf the garage lights are off (condition)
Turn the garage lights on (action)

Event 2
If motion is sensed in the Garage (trigger)
AndIf the Garage Door is Open (condition)
Record the Driveway Camera for 30 seconds (action)

Event 3
If motion is sensed in the Garage (trigger)
Restart Garage motion sensor timer (action)

Event 4
If motion is sensed in the Garage (trigger)
AndIf the Garage motion sensor timer is less than 1 (condition)
Speak "Motion Sensed in the Garage" (action)

Now imagine how this workflow can change if conditions can be applied to actions instead!

Event
If motion is sensed in the Garage (trigger)
Turn the garage lights on (action)
If garage lights are off (condition)
Record the Driveway Camera for 30 seconds (action)
If Garage Door is Open (condition)
Restart Garage motion sensor timer (action)
Speak "Motion Sensed in the Garage" (action)
If Garage motion sensor timer is less than 1 (condition)

Workflow

No change will be made to the trigger section of the event. That will continue to function as it currently does with support for multiple triggers and conditions. In the actions section, the following changes will be made:

1. A new "add condition" button will be added to the button group at the right end of each action block. Clicking that button will add a new condition block beneath the action. That block will work the same as the condition blocks in the trigger section.
2. Saved action conditions will appear slightly indented to provide a visual queue that they belong to the action immediately above them.
3. It will be possible to enable or disable individual action conditions

Here is a mock-up of what we have in mind for this:

[rmasonjr]

Wow - that really reduces the number of events and the indentions make it easy to read.

[ksum]

Would one be able to do this without the first Set (action) option shown? I think that may be helpful. Meaning:

IF

motion is sensed in the Garage (trigger)

THEN

If garage lights are off (condition)

Record the Driveway Camera for 30 seconds (action)

If Garage Door is Open (condition)

Restart Garage motion sensor timer (action)

Speak "Motion Sensed in the Garage" (action)

If Garage motion sensor timer is less than 1 (condition)

(no action has been defined)

I am guessing the last Condition in your example is not necessary?

Also, in your example it appears the Original state of the Outside Garage Overhead Light Switch is used for further conditions within the event and not a Changed State as a result of Earlier Actions in the Event itself. Is this correct?

[macromark]

Would one be able to do this without the first Set (action) option shown? I think that may be helpful. Meaning:

IF

motion is sensed in the Garage (trigger)

THEN

If garage lights are off (condition)

Record the Driveway Camera for 30 seconds (action)

If Garage Door is Open (condition)

Restart Garage motion sensor timer (action)

Speak "Motion Sensed in the Garage" (action)

If Garage motion sensor timer is less than 1 (condition)

(no action has been defined)

I am guessing the last Condition in your example is not necessary?

Also, in your example it appears the Original state of the Outside Garage Overhead Light Switch is used for further conditions within the event and not a Changed State as a result of Earlier Actions in the Event itself. Is this correct?

Karl - I don't understand your suggested change... doesn't seem to follow the logic of my original event group.

As for turning the light on only when it's off, that's not absolutely necessary. I just do that to reduce the Z-Wave traffic in the event I'm in the garage moving around a lot.

[HSAccord]

I think this is definitely on the right track.

Combining multiple features inside a virtual device to use for maintaining state data with this feature would finally bring event processing up to snuff.

I could probably cut the number of events I maintain in half, or more, with this.

[Uncle Michael]

• I assume that you are planning only one level of condition (no nesting). Is that correct?
• For consistency with the event conditions, have you considered placing the condition ahead of the action and indenting the action(s) affected by that condition instead of having the condition follow the action it affects? Something like this:
  • THEN
  • Turn on light 1
  • Start timer
    • If time is after sunset
      • THEN
      • Turn on light 2
      • Turn on light 3
    • If door is open
      • THEN
      • Record on camera

(I think this structure may be what ksum was assuming.)

[macromark]

[LIST][*]I assume that you are planning only one level of condition (no nesting). Is that correct?[*]For consistency with the event conditions, have you considered placing the condition ahead of the action and indenting the action(s) affected by that condition instead of having the condition follow the action it affects?

Yes, planning just one level for conditions similar to trigger conditions.

Personally, I like adding the conditions after the actions (Do this thing, if this is true) as opposed to before (if this is true, do this thing) primarily because I'm already used to seeing the actions first in that part of the event. However Rich likes it the opposite way. I suspect folks who have a programming background will agree with you and others may agree with me. We'll have to see.

[mrceolla]

I don't currently have a strong preference for before or after, but based on the first screenshot I think it would be beneficial to make some style changes to make sure it is clear which conditions apply to which actions. Somehow indicating that these rows all belong together

[brientim]

Yes, planning just one level for conditions similar to trigger conditions.

Personally, I like adding the conditions after the actions (Do this thing, if this is true) as opposed to before (if this is true, do this thing) primarily because I'm already used to seeing the actions first in that part of the event. However Rich likes it the opposite way. I suspect folks who have a programming background will agree with you and others may agree with me. We'll have to see.

This simplifies the events considerably whereby a trigger can have multiple actions based on their own predicated conditions.

I am with Rich, the predicate condition before action (if then statement)

[ksum]

Karl - I don't understand your suggested change... doesn't seem to follow the logic of my original event group.

As for turning the light on only when it's off, that's not absolutely necessary. I just do that to reduce the Z-Wave traffic in the event I'm in the garage moving around a lot.

My thought is that there would be a need for a nested If statement. I just see people complaining about not having nested conditions. Sure, I can have multiple Events handle this, but I can have multiple Events now and people are not happy. Trying to limit the "You got halfway there." comments. Maybe something such as this (apologies for the crude editing. I need to get Snagit on my personal system...)


My comment about turning the light on and then later checking the condition of the light is that if you check the condition of the light at the time of the highlighted portion below, the light will be On because you have just turned it on in the circled portion below. So would the highlighted portion evaluate the value of the light switch at the time the Event was Triggered, or at the time which that portion of the Event is processed? If the later, I would want to set the light on later, and, by your statement "As for turning the light on only when it's off, that's not absolutely necessary. I just do that to reduce the Z-Wave traffic..." In your example, you are turning it On regardless. Your statement actually gives merit to my request for nested If statements. The point here being, however, that SOME may expect that the highlighted section never runs in your example because at that point, the light is On and never Off.

[upstatemike]

For what it's worth I like seeing conditions before the action. If the condition is not true then no need to proceed to the action because it does not matter. Just seems the more logical way for things to flow.

[w.vuyk]

anyone scripting would expect the action to come after the conditions, just like the current events and actions.
Anyway this would be a nice improvement, but I would need to test it to get a full grasp on this. My events are a lot more complex with IF and OR's and multiple conditions in between these. I think the new methods could save quite some events, but also an event can become hard to understand with all the extra action conditions....
does a condition in events apply only to the first action, or all lower actions? Not saying it should work this way, but maybe it is worth a thought here?

[RRR]

For what it's worth I like seeing conditions before the action. If the condition is not true then no need to proceed to the action because it does not matter. Just seems the more logical way for things to flow.

2nd that

[macromark]

If I move the conditions before the actions, the resulting screen would look like this:

The one issue I have with that is that the action in the middle (Start Timer Garage Light Timer) might appear to be part of the condition/action grouping above it. At any rate, it's awkward looking. So, some additional formatting might be warranted. Adding some paddling helps a little but not much


Maybe a divider?

[avpman]

This simplifies the events considerably whereby a trigger can have multiple actions based on their own predicated conditions.

I am with Rich, the predicate condition before action (if then statement)

Agreed. IF THEN, do this, not DO THIS IF. In particular, because the IF statement is what controls the action.