Strange behavior after rain delay

[jonathan-marsh]

I put two systems on a 72 hour rain delay. However the scheduler seems to have kept trying to run programs and queuing them up for delayed start, at least for stations on extension boards.

After the rain delay expires, the stations continue to show as awaiting a start. Pictures of pre-expiry of rain delay and post-expiry attached.

However, I don't think this is just a display issue. On my other system, with no extension boards, the display looked fine both before and after a 72 hour raid delay expired, but when a regularly-scheduled program ran one of the suppressed programs began actually running.

Stop all stations clears everything out.

I haven't looked at the relevant code yet, will try to debug when I have some time.

-Jonathan

[Dan-in-CA]

What version of SIP are you running? I did a quick test with 16 stations and they all appeared to be suppressed by rain delay. Will do some further testing. I have been using the node-red plugin as a diagnostic tool because it can read SIP control variables while SIP is running.

Dan

[jonathan-marsh]

5.0.40

-Jonathan

On Thu, Nov 9, 2023 at 6:07 PM Dan @.***> wrote:

What version of SIP are you running? I did a quick test with 16 stations and they all appeared to be suppressed by rain delay. Will do some further testing. I have been using the node-red plugin as a diagnostic tool because it can read SIP control variables while SIP is running.

Dan

— Reply to this email directly, view it on GitHub https://github.com/Dan-in-CA/SIP/issues/326#issuecomment-1804965192, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASRVYSCJI7U4R2YCW54IEDYDWD5HAVCNFSM6AAAAAA7FOILQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUHE3DKMJZGI . You are receiving this because you authored the thread.Message ID: @.***>

[jonathan-marsh]

Hi Dan,

Here's what I've discovered.

Got it down to a simple test case: Program 1: run station 1 at 6PM for 30 min Program 2: run station 2 at 7PM for 30 min Enable rain delay for 1 hour at 5:50 PM (so program 1 will be suppressed, but program 2 will run)

Upon entering schedule_stations() at 6PM, gv.rs = [[0, 0, 1800, 1], [0, 0, 0, 0], ...

Because rain delay is enabled, no stations are scheduled, i.e. no start or end times are added to gv.rs, so the station won't start, but neither is gv.rs cleared out in any way.

Upon entering schedule_stations at 7PM, gv.rs = [[0, 0, 1800, 1], [0, 0, 1800, 2], ... Program 2 has added station 2, but station 1 still remains in the list from 6PM.

Because rain delay has expired, this time all stations are scheduled, and on completing the subroutine gv.rs = [[1701486000, 1701487800, 1800, 1], [1701487800, 1701489600, 1800, 2], ...

My expectation is that station 1 should be suppressed, not just delayed until the rain delay expires. The current behavior is that the last program attempted for each station during rain delay remains queued, will run when the first program runs after the rain delay expires.

The solution appears simple - just clear out the suppressed program from gv.rs at the time the rain delay is detected.

While trying to understand the code, I also noticed a few places where station testing or manipulation is done by looking at [s] instead of [sid], which will cause issues when extension boards are in place - e.g. if a master valve is assigned to station 8+.

I'm a bit nervous to change a fundamental bit of the timing loop without extensive testing, perhaps you could take a look at the changes at https://github.com/Dan-in-CA/SIP/compare/master...jonathan-marsh:OSPi:master and see if you see anything problematic?

-Jonathan

On Thu, Nov 9, 2023 at 6:07 PM Dan @.***> wrote:

What version of SIP are you running? I did a quick test with 16 stations and they all appeared to be suppressed by rain delay. Will do some further testing. I have been using the node-red plugin as a diagnostic tool because it can read SIP control variables while SIP is running.

Dan

— Reply to this email directly, view it on GitHub https://github.com/Dan-in-CA/SIP/issues/326#issuecomment-1804965192, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASRVYSCJI7U4R2YCW54IEDYDWD5HAVCNFSM6AAAAAA7FOILQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUHE3DKMJZGI . You are receiving this because you authored the thread.Message ID: @.***>

[Dan-in-CA]

Thanks Jonathan, I will take a look at your code. Dan

[Dan-in-CA]

Looks good. I don't see anything that would cause a problem.

[jonathan-marsh]

Fixed in #329