Confirming correct use of interval condition?

Good day all!

Just looking for confirmation on how to setup simple cycling of a decorative pond pump using the interval condition. I’ve read a few posts, so I think I get it, but not 100% sure.

I essentially want the pump to run for 1 hour, and then shut off for 1 hour. I’m not overly particular on when exactly it starts, just want to be mindful of duty cycle so it’s not running continuously.

Here’s what I setup:

Condition Group 1 in Reactor sensor
-interval - 2 hours, relative to 0:00 (midnight)
-delay reset 3600 seconds (i.e. 1 hr)

Activities:
Reactor sensor true - Turn on Pump
Reactor sensor false- Turn OFF Pump

Have I set this up correctly to accomplish 1 hour on / 1 hour off cycling of the pump?

1 Like

You stuck the landing, my friend.

Funny, I was just writing the script for the video on Interval conditions. I’m going to use this as the example in the video.

Minor detail: the pump will actually run for 3602 seconds, because the default pulse width is two seconds, and the delay reset is added to that. So if you shorten your delay reset to 3598, you’ll have the pump running exactly one hour of every two hours.

ha ha nice. lol. OK, that’s good to know for precision! Thanks Patrick ! :slightly_smiling_face:

I’ve been building on the learning from my query the other day, where you educated me on how the delay reset property works.

(Expression for current time not refreshing - #4 by rigpapa - Reactor - Ezlo Community)

So figured I could put the delay reset to use, marrying it with the interval condition. I did setup the sensor this morning, I didn’t notice it “untripping” after the ~1hour of being tripped

(i.e. it appeared the reactor sensor root was always showing as true). Maybe I just didn’t notice when it went false. I’ll watch it more carefully this afternoon and folllow up if anything’s peculiar.

the videos are awesome btw!

OK. You can always look at the Logic Summary “Events” section, too… it documents the progress of the RS’ work, so you can get a good idea of what it’s doing/has done.

Ahh, I never even thought to check that. good call. I’ll post below, but indeed it looks like my suspicion is right. It’s not “un-tripping” hmm… I can’t see any reason for why it wouldn’t be. I see in the snapshot of the conditions it also says “false as of 10:15am”, yet the sensor is still evaluating to true.

Any idea what I’m missing? :thinking:

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.2 config 301 cdata 19082 ui 19143 pluginDevice 23
    System: Vera version 1.7.4453 on Sercomm G450; loadtime 1560440720; systemReady 1560440736; ALTUI v2.43; Lua 5.1
Local time: 2019-06-13T11:22:18-0600; DST=1
House mode: plugin 1; system 1; tracking off
  Sun data: { "stamp": 2019164, "civdawn": 1560422177, "nautdawn": 1560418045, "sunset": 1560484177, "nautdusk": 1560491063, "latitude": 50.80855, "astrodusk": null, "longitude": -113.9485, "civdusk": 1560486931, "astrodawn": null, "sunrise": 1560424932 }
  Geofence: running in quick mode, last update 05:43:00, data version 2
            User 2342071 ishome=1 inlist= since=23:30:00
            |    1 "40 Norris Coulee Trail, De Winton, AB T0L 0X0, Canada De Winton" type="home" status="" since=05-14.06:35:00
            User 2338371 ishome=0 inlist= since=05:43:00
            |    4 "40 Norris Coulee Trail, De Winton, AB T0L 0X0, Canada De Winton" type="home" status="out" since=05-15.19:34:00
            Raw: { "updated": 1560446520, "users_settings": [ { "id": 2338371, "ishome": 0 }, { "id": 2342071, "ishome": 1 } ], "mode": 1 }
====================================================================================================================================
Back Pond Pump Timer (#93) tripped
    Version 19082.4 06/13/19 07:13:05
    Message/status: Tripped
    Condition group "Reactor Sensor 14" (AND) TRUE as of 07:12:32 <root>
      &-T-interval { "type": "interval", "options": { "holdtime": 3600 }, "mins": 0, "id": "cond0", "hours": 2, "days": 0 } [1560434400 => 1560441600 at 10:00:00; F/T as of 10:00:15/07:12:32] <cond0>
    Activity root.false
        Device 92 (GE Outdoor SS #1) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Activity root.true
        Device 92 (GE Outdoor SS #1) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="1" )
    Events
        06/13/19 09:45:30 start: 
        06/13/19 10:00:00 condchange: newState=true, cond=cond0, oldState=false
        06/13/19 10:00:15 condchange: newState=false, cond=cond0, oldState=true
```![cap1|690x180](upload://eytTVuhPQhwSJr48jB3P8mJWwAW.jpeg)![cap1|690x180](upload://eytTVuhPQhwSJr48jB3P8mJWwAW.jpeg)

here’s the screenshot of the conditions… puzzled why it shows false, but sensor has stuck on true since I set it up this morning

Hmmm… I fixed a bug a bit ago that would intersect your symptoms here–I didn’t release it as a hotfix because I didn’t think it would intersect many users’ usage, but I think you are getting it. Let me pull together a hotfix patch with just that fix and I’ll chime in when it’s ready.

OK. Install the hotfix-19164 version of L_Reactor.lua. This will likely address the issue.

Oh wow no kidding? I didn’t think I’d stumble on a bug lol. thought I was missing somethin.

Omg ty for turning this around so expeditiously! I’ll deploy this when I get a chance this evening and let u know :blush:

1 Like

That did the trick Patrick! It’s tripping perfectly every even hour, and untripping on the odd hour like clockwork! Impressive, glad u were able to nail this one down… As I was scratching my head lol

1 Like