How does interval mode react to manual override?

[msambol]

Hi, I'm just getting started with SIP, and wondering: if I have programs on interval mode, e.g. run every 3rd day, and then switch to manual mode for a day, how does that impact the interval program? Will it resume its count where it left off, or will it restart the count when transitioning back to auto mode?

Similarly, if the interval program was prevented from activating the system because it was in manual mode that day, will it make up for the missed activation when it resumes?

Thanks.

[dan]

The Interval mode calculates the days to run when you first set it up. Switching to manual mode should not affect the schedule.

In other words It will stay on the same schedule as if the manual mode was not activated but it will not make up for a skipped day

[msambol]

Thank you for the quick reply, Dan. I understand the bottom line but not the explanation. How far ahead does the interval mode plan?

More important but totally off topic question: I tried using the HTTP GET API but have not had success. Regardless of which method I try, the server simply returns the login page.

e.g.

http://10.0.0.128/api/status
http://10.0.0.128/sn
http://10.0.0.128/cv?pw=mypass&mm=1

just return the login page - checked via browser and also via Postman.

If however I first login in the browser, then call

http://10.0.0.128/api/status
or
http://10.0.0.128/sn

these work.

http://10.0.0.128/cv?pw=mypass&mm=1

does not, it again returns the login page.

Help?

[dan]

My explanation of how the interval mode works was a little misleading, sorry.

When you set an interval SIP sets up a "base date", a starting date, as a timestamp which is stored in the program file. When it is time to run the program SIP checks to see if the current day is the right number of days from the base date to match the chosen interval. SIP does not need to store a list of days that the program will run.

Regarding the HTML GET commands; I did some testing here and the commands work even when it returns the login page.

If you login after sending a GET command you should see the correct result.

You can disable the password on the Options page under "Change password" by checking the "Disable security" checkbox. This will prevent the login page from being returned.

SIP's password is not very secure. It is mostly useful for keeping unauthorized persons from changing settings.

[msambol]

OK, that's clear, and results confirmed.


There may be a bug here though, as there seems to be a discrepancy between the station IDs as reported by two different APIs:

http://10.0.0.128/sn
result:
10100000

first and third stations are on.

http://10.0.0.128/api/status
result:  (I'm adding newlines for readability)
[
{"status": "on", "name": "Front Yard Drip", "reason": "program", "station": 0, "master": 0, "programName": "Manual Mode", "remaining": 0}, 
{"status": "off", "name": "Back Yard Drip", "reason": "", "station": 1, "master": 0, "programName": "", "remaining": 0}, 
{"status": "on", "name": "Main", "reason": "master", "station": 2, "master": 1, "programName": "", "remaining": 0}, 
{"status": "off", "name": "Back Yard Sprinklers", "reason": "", "station": 3, "master": 0, "programName": "", "remaining": 0}]

seems to indicate that station IDs start at zero, and the active ones are 0 and 2. API doc says station IDs start at 1 so I suggest either changing the values returned by api/status or documenting that it's off by one.

Then again, if I'm the first to raise this, maybe best to leave it alone

Thanks for the help and the product!

[dan]

SIP's internal lists are zero based as are arrays, and such in most programming languages.
Most end users are more familiar with 1 based numbering so the UI related representations are 1 based

The PDF file of GET commands tries to indicate which values are zero based and which start from 1.