Announcement

Collapse
No announcement yet.

Repeat a certain check

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Nice, it seems a shame they removed it in HS4.

    (In HS4) I thought maybe I could put in a step at the end to run the event again after a delay, but you can't - "run another event" actually is "run a different event", you can't run the same one again although you can run a second event which then runs the first...

    Script commands don't help either because TriggerEvent doesn't have an option to check the conditions (which is a huge gap IMO).

    So even though events support these delayed actions and waits and the ability to call other events, looks like in HS4 a timer or at least two events is required, which sucks which you've just shown me a neat solution.

    Comment


      #17
      You can still do this in 1 event

      A recurring trigger happens (set this to 5 min)
      and if window open
      and if virtual switch on
      then announcement
      HS4 Pro on Shuttle NC10U, Win10; Z-NET
      Number of Devices: 449
      Number of Events: 210

      Plug-Ins: Arduino, BLLock, DirecTv, EasyTrigger, Honeywell WiFi Thermostat, MeiHarmonyHub, PHLocation2, Pushover 3P, UltraM1G3, WeatherXML, Worx Landroid, Z-Wave

      External applications: Homebridge-homeseer, Geofency, EgiGeoZone.

      Comment


        #18
        Originally posted by jmaddox View Post
        You can still do this in 1 event

        A recurring trigger happens (set this to 5 min)
        and if window open
        and if virtual switch on
        then announcement
        Yes I do that sort of thing for scripts that do a bunch of complex checks and then an action (like mow if it's in time range X but not if it rained in the last four hours or we mowed in the last 18 hours, but then do it at some point later if it's not raining, finally if it's been a few days do it even if raining etc, oh and also check if the mower is on its base, and maybe we need to edge mow).

        But your example doesn't work as required - it will announce somewhere between zero and five minutes after the conditions are true, not straight away. This will work better:

        A recurring trigger happens (set this to 1 min)
        and if window open
        and if virtual switch on
        then announcement
        event cannot repeat for 5 minutes

        I still hate this model - events should be triggered by actions, not polling, it always becomes a compromise between responsiveness and useless processing, but it's better than nothing.

        Also it made me think about the "at least condition" for delayed triggering - they removed "has been for at least" in HS4 to avoid runaway triggering, but if it's not the main condition then that's not a problem.

        And bingo - you can still use "has been for at least" in an AND clause, so we can do this if we want the first announcement after five(ish) minutes:

        A recurring trigger happens (set this to 1 min)
        and if window open
        and if virtual switch has been on for at least 5 minutes
        then announcement
        event cannot repeat for 5 minutes

        Comment


          #19
          Originally posted by rge View Post
          This will work better:

          A recurring trigger happens (set this to 1 min)
          and if window open
          and if virtual switch on
          then announcement
          event cannot repeat for 5 minutes

          I still hate this model - events should be triggered by actions, not polling, it always becomes a compromise between responsiveness and useless processing, but it's better than nothing.

          Also it made me think about the "at least condition" for delayed triggering - they removed "has been for at least" in HS4 to avoid runaway triggering, but if it's not the main condition then that's not a problem.

          And bingo - you can still use "has been for at least" in an AND clause, so we can do this if we want the first announcement after five(ish) minutes:

          A recurring trigger happens (set this to 1 min)
          and if window open
          and if virtual switch has been on for at least 5 minutes
          then announcement
          event cannot repeat for 5 minutes
          Keep in mind that <has been for at least> is not an action. It's a condition. That's why it cannot act as a trigger.

          I'm not sure what you mean by "useless processing", but the <has been for at least> "trigger" in HS3 is, in practice, a combination of the <has been for at least> condition and a hidden recurring trigger that was basically free running. That's why it could lead to runaways.

          Also, a recurring trigger with unsatisfied conditions does not appear to consume measurable resources. I suspect the event engine is quite efficient at combining conditions and triggers to minimize overhead. Aside from OCD considerations, it's probably not an issue.

          That said, you could make the event even more responsive by shortening the recurring trigger even further. (Making it 1 second would pretty closely replicate the performance of the HS3 "trigger".)

          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


            #20
            I agree, checking "if time is X" is likely no more effort for the event engine than checking "if device is X". Time is just a hidden device.

            Comment


              #21
              Originally posted by Uncle Michael View Post
              Keep in mind that <has been for at least> is not an action. It's a condition. That's why it cannot act as a trigger.

              I'm not sure what you mean by "useless processing", but the <has been for at least> "trigger" in HS3 is, in practice, a combination of the <has been for at least> condition and a hidden recurring trigger that was basically free running. That's why it could lead to runaways.

              Also, a recurring trigger with unsatisfied conditions does not appear to consume measurable resources. I suspect the event engine is quite efficient at combining conditions and triggers to minimize overhead. Aside from OCD considerations, it's probably not an issue.

              That said, you could make the event even more responsive by shortening the recurring trigger even further. (Making it 1 second would pretty closely replicate the performance of the HS3 "trigger".)
              True, it just isn't aesthetically / architecturally pleasing, maybe that is a bit OCD!

              It would also really help if they added "trigger every X minutes starting at Y minutes in the hour".

              At the moment the option is to run at the top of the hour, so everything runs at the same time, or not specifying the start time which in practice means the same after the first restart.

              It isn't just because of the controller but also the Z-Wave network, which isn't so happy if a lot of devices are changed at the same time. And logging/monitoring is much easier if everything doesn't happen at the same time.

              Comment


                #22
                Originally posted by rge View Post
                It would also really help if they added "trigger every X minutes starting at Y minutes in the hour".

                At the moment the option is to run at the top of the hour, so everything runs at the same time, or not specifying the start time which in practice means the same after the first restart.
                I was under the impression the timing was more random than that, and I haven't seen any obvious behavior quirks that might accompany that sort of coordination. How did you determine that they are all synchronous?

                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

                Working...
                X