Announcement

Collapse
No announcement yet.

Feedback Request: Conditional Actions

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Feedback Request: Conditional Actions

    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:

    Click image for larger version  Name:	image.png Views:	3 Size:	54.6 KB ID:	1568627
    Learn About HomeSeer

    #2
    Wow - that really reduces the number of events and the indentions make it easy to read.
    HS4Pro Running on a Raspberry Pi4
    67 Z-Wave Nodes, 111 Events, 422 Devices
    Z-Wave, UPB, WiFi
    Plugins: EasyTrigger, weatherXML, OMNI, Z-Wave, Tuya, Device History
    HSTouch Clients: 3 Android, 1 Joggler

    Comment


      #3
      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 S
      HS4Pro on Windows 10
      242 Devices
      56 Z-Wave Nodes
      37 Events
      HSTouch Clients: 3 Android, 1 iOS
      Google Home: 3 Mini units 1 display

      Comment


        #4
        Originally posted by ksum View Post
        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.
        Learn About HomeSeer

        Comment


          #5
          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.

          Comment


            #6
            • 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.)
            Mike____________________________________________________________ __________________
            HS3 Pro Edition 3.0.0.548, NUC i3

            HW: Stargate | NX8e | CAV6.6 | Squeezebox | PCS | WGL 800RF | RFXCOM | Vantage Pro | Green-Eye | Edgeport/8 | Way2Call | Ecobee3 | EtherRain | Ubiquiti

            Comment


              #7
              Originally posted by Uncle Michael View Post
              [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.

              Learn About HomeSeer

              Comment


                #8
                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
                HS4, Insteon, Z-wave, USB-UIRT, Google Hub/Chromecasts/Speakers, Foscam & Amcrest cameras, RCA HSDB2a doorbell
                Plugins: BLLAN, BLOccupied, BLUSBUIRT, Chromecast, Harmony Hub, Insteon, Jon00 Homeseer/Echo Skill Helper, Jon00 DB Charting, MediaController, NetCAM, PHLocation2, Pushover 3P, weatherXML, Z-wave

                Comment


                  #9
                  Originally posted by macromark View Post

                  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)

                  Comment


                    #10
                    Originally posted by macromark View Post

                    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...)
                    Click image for larger version

Name:	image.png
Views:	688
Size:	60.7 KB
ID:	1568669

                    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.
                    Click image for larger version

Name:	image.png
Views:	697
Size:	61.6 KB
ID:	1568668
                    Karl S
                    HS4Pro on Windows 10
                    242 Devices
                    56 Z-Wave Nodes
                    37 Events
                    HSTouch Clients: 3 Android, 1 iOS
                    Google Home: 3 Mini units 1 display

                    Comment


                      #11
                      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.

                      Comment


                        #12
                        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?
                        -- Wim

                        Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData

                        1210 devices/features ---- 392 events ----- 40 scripts

                        Comment


                          #13
                          Originally posted by upstatemike View Post
                          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

                          Comment


                            #14
                            If I move the conditions before the actions, the resulting screen would look like this:
                            Click image for larger version  Name:	image.png Views:	0 Size:	42.2 KB ID:	1568696
                            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

                            Click image for larger version  Name:	image.png Views:	0 Size:	37.0 KB ID:	1568697
                            Maybe a divider?
                            Click image for larger version

Name:	image.png
Views:	666
Size:	37.1 KB
ID:	1568698​​
                            Learn About HomeSeer

                            Comment


                              #15
                              Originally posted by brientim View Post

                              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.

                              Comment

                              Working...
                              X