Features or bugs ?

[ottorino]

Hi all,
I see three behaviors that I cannot classify as bugs or features.

1)
I read from manual

Station Water Times
• Set the water time for each station. A value of 0 means the station will
not run. The range and resolution of water time are as follows:
o 0 to 59 seconds, in steps of seconds.
o 1 to 179 minutes, in steps of minutes.
o 3 to 16 hours, in steps of hours.
o Also supports sunrise-­‐to-­‐sunset and sunset-­‐to-­‐sunrise durations.

If this is true, why I cannot set, say, 1 min + 30 seconds ?
When 1 is in the “minutes” field, the “seconds” field is blanked and is not possible either to press the up/down arrows or enter a number directly.
If I set 0 to “minutes” I can set 90 to “seconds”, in the green field “1m 30s” appears, but after saving the program, the very same green field contains “1m”.

That’s kind of curious, because the Zimmerman method is able to set minutes and seconds: in fact in the Run-Once program I can find, say, 1m 48s.

It happens both on the web version and on the android version
(Firmware 2.1.5(1),
android and web app 1.46,
HW 2.1(AC),
GT-i9300 samsung,android 4.3,
Linux Mint Qiana, MATE, Firefox ).

2)
After using the android app, i.e. seeing preview, checking logs, modify programs, seeing weather conditions etc. etc., I sometimes press the “back” soft button on the phone (on my S3 the one on the right) until I get a black screen, instead than quitting the OS app. The black screen is then definitive: I cannot start the app again. The only escape is to kill the app from the central hard button and restart it again

3)
On the android app I can log to OS.com, since in the black screen (the one activated by the icon on top left, or wiping the screen from extreme left: I’m sorry I do not how to write in english !) has the proper option.
I cannot find the “log to OS.com” on the web app.

Are the behaviors 1), 2) and 3) expected and known ?

[Samer]

Regarding the first issue you posted, this is not a bug and the description is correct. To elaborate, let me first quote the same values you did:

0 to 59 seconds, in steps of seconds.
1 to 179 minutes, in steps of minutes.
3 to 16 hours, in steps of hours.

The value is cumulative between all the “inputs” on the popup all converted to the units listed on each row. In other words, when we say “1 to 179 minutes” we are saying if the duration is greater than 59 seconds and less than 3 hours the granularity (or highest resolution) is minutes.

For the second issue, I have run into that issue before and have not found a great fix yet. This is a known bug.

The third thing you mentioned is not a bug. When you access the UI directly by using the IP it does not function as an “app” in that it won’t allow you to access other OpenSprinkler units you may have. I realize users now want cloud sync on the direct IP UI for the station images and will work on getting a working solution.

Update: Just to add to the first issue, the watering time has a final unit of seconds when it is scheduled. However to save space, we interpret the stored water value based on how large it is but once interpreted the time is scheduled in seconds. This is important because a value of 2 minutes can be modified into 1m 30s by using a watering scale of 75%.

[ottorino]

Thanks for the prompt and exhaustive answer, Samer.

I see.
But it was not that easy to extrapolate from the manual that the granularity was changing

So I have sometimes a waste of water, especially when it comes to pots or sloped landscapes.

I see that I cannot use the evapotranspiration correction in these cases.
Say I have a 138% of correction

1 min * 1.38 = 1 min 23 sec is acceptable, no waste of water, but some wilting or suffering is appearing in the plants
2 min *1.38 = 2 min + 45 sec and it’s too much

A workaround is to split the two minutes into two events, possibly separated by an interval.

It’s not solely a matter of evapotranspiration, but rather an equilibrium between the amount of water dispensed each time and infiltration rate of the soil.

[Ray]

@ottorino: the fact that the program water time is in a non-linear scale is a design decision — it’s because we want to represent the stored water time using just one byte. The related discussion and survey is here:
https://opensprinkler.com/forums/topic/survey-can-station-water-time-fit-in-1-byte/
the reason behind the non-linear scale is that typically the longer the water time, the less accuracy you care about. This is similar to how floating point numbers are represented in a computer system. Because OpenSprinkler supports a relatively large number of stations, it’s important to compress the water time to as few bytes as possible.

The actual runtime is computed as the stored water time multiplied by the watering level, so the actual runtime is of full precision down to accuracy of seconds. It’s just that the stored water time must be stored in EEPROM and there is very limited EEPROM space on the microcontroller, hence the non-linear scaling.

[Author]

Posts