[ottorino]

Please note that my previous answer was neither a no or a polite negative answer. We can possibly try to exchange our mail addresses in some other way. I’m currently writing from my mobile and it’s not comfortable. As soon as I will lay my hands on a true keyboard I will try to arrange something

[ottorino]

Hi there. It seems that I cannot send private messages to you, therefore I do not know how to send you my e-mail address

[ottorino]

As far as I can understand the weather integration regulate only the amount of water. In my system, even before the zimmerman algorithm came into play, I’ve always had the orbit device you are planning to buy. I suppose that the orbit device is the only one capable to trigger the irrigation on and off. When on, the zimmerman algorithm calculate the amount of water.
Hope this helps

[ottorino]

Hi Jemba.
In the meantime just unselect the climatic control from the programs you use.

[ottorino]

I made some experiments during the night.
Two programs unattended plus one attended
1) start 2 hours before sunrise, no climatic correction, unknown water level. Executed and logged
2) start 1 hours before sunrise, climatic correction, unknown water level. Not executed (no water on the dry soil this morning) and not logged
3) start 3 hours after sunrise, climatic correction, 133 % water level. Executed with correction and logged

I presume that during the night the water level drops to zero and this inhibit the execution of the programs.

Attachments:

1. 

   Schermata-del-2018-06-18-11-35-22.png
   

[ottorino]

After removing the WU API key it seems that a program supposed to start two hours before sunrise and climatc control is no longer activated. I cannot see it in the log. Could it be due to the swinging values I now see in the water level ?

[ottorino]

Hi all.

Here in Florence, Italy with my old API key on WU, I have a strange behavour.
The date shown is for Jan(uary) rather than Jun(e) and the sunrise/sunset hours are correct.
For January !
Opensprinkler programs with sunrise/sunset assume that is January,
but the date shown in the main screen is the actual one, June 16th

Somehow, the weather forecast seems correct for June.

With OWM the sunrise/sunset hours are correct for June,
and watering programs with sunset/sunrise starts at the correct time

[ottorino]

I myself had the same problem. A std fuse will not harm. Mine is in place since two years. You have only to play a little with the solder and two pieces of solid wire. The fuse will be standing like torre di Pisa, otherwise the cabinet will not close properly. But from the electrical point of view there are no noticeable differences.

[ottorino]

Turning off the 24 V main supply.

[ottorino]

@Tom & David
I agree with you both.
The difference is the same between a measure and an estimation.
Both of them can be useful depending on the aim or the available equipment or money.

I also would like to have a flow meter since I had the very same problem which Tom had, but in the meanwhile I’m using the estimation method. But I did the estimation in a different way: I let each channel run for 5 minutes and record the amount of water on the analogical main flow meter of my house.

No need to say that all the other tap valves in the house were closed.

From time to time I repeat the procedure to check for flow consistency

[ottorino]

+1 for me too.
I sometimes need to jump some watering cycles, say for one day.

May I suggest to insert the pause both for the programs and for the stations ?

[ottorino]

Yes. It analyze only the past.

I realize that is not easy to modify the backup.json file.

If needed, I can modify the script to:
export the data into a more readable and editable form as csv.
modify the data (by the user)
reimport the modified data and get the results for simulated programs

[ottorino]

Hi all.
what is described above has happened again. The clock was resetting at 21:59 again and again.
Luckily enough I was there and was able to stop everything before wasting a lot of water.
The series
36, 10, 9, 21,… sec
at
21:59, 21:59, 21:59, …
is due to the fact that the sprinklers insisted on coming out and I insisted on stopping them.

The real time was around 23:15, july, 7th, thursday and I was able, by pure chance, to attend at the first event marked 21:59:01

I think I have a problem in the RTC but I do not know ho to solve it. Any idea ?

I’ve checked the battery and seems in good conditions, 3.2 V. It was replaced last year.

(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 ).

Attachments:

1. 

   Schermata-3.jpg
   

[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.

[ottorino]

I think that we need some programs which start from sunset to sunrise.
I know that the day is the frame in which OS is programmed, so therefore two programs are needed to irrigate during the night.

Nevertheless, many of us thinks in terms of night/day when comes to irrigation: so I suppose that a program which do not consider the 0-12 day, but rather the day/night sequence would be helpful to many of us.

BTW: I know that it’s easy to throw in ideas without taking the burden to work on them !!

[ottorino]

Yes. It’s nevertheless impractical for numbers around 60 or 120.

When I keep pressing the result is unpredictable. It keeps going for a while snd also the minus sign disappear

[ottorino]

No, I’m not sure. And I think that you’re right in pointing that actually it was 2 min and 49 sec.

Nevertheless, the scheduled time was 30 sec. Also allowing a plus for the Zimmermann method I would expect a figure round 33 seconds
(30(sec) * 1.08 (%) = 33 sec)

OT
It seems that seconds are considered on base 10, instead than on base 60.
I see that the other channel (1 min scheduled time) with a correction of 108% results into a 1 min + 8 sec

Is that right ?

[ottorino]

“Also two other channels were turned yellow and some strange figures appeared.”
can you be more specific? Do you have a screenshot?

Thanks for the reply, Ray.
No unfortunately I did not take any screenshot.

I have the screenshot of the log:

The program was started manually:
The channel “Prato,sole” started and stopped regularly after a minute, the scheduled time (+ 8 sec from evapotranspiration adjustment)
then the channel “Prato,ombra” started and was expected to run for 30 sec + extra time from evapotranspiration adjustment

The sprinklers were watering, and the dot for “Prato,sole” on the main screen turned from red to green.
I cannot remember if the yellow dots appeared at the very same time to the green one, but “Prato,ombra” was yellow after the green/red change on “Prato,sole”.
Within the “Prato,ombra” frame there was a yellow dot on the left, the sprinklers were watering and a sentence appeared under the name of the channel.
The sentence was something about time and I remember it was about 2:49 hours.
At the same time, on the main screen two channels (“Vasi” and “Fasce laterali”) were in the very same conditions of “Prato,ombra” (yellow dot and all the rest), but the sprinklers were not watering and the times were about 16h:something and 29h:something.
I stopped the whole thing by “Stop all stations”.

Attachments:

1. 

   Schermata-1.png
   

[ottorino]

Hi all,
I think that this is the right place to report a behavior.

One of my programs starts 2h after sunset (23.01 local time) and then it have a repetition after 2 hours for two times
Only the first event is run, the one at 23.01.
I can tell it for sure because I was awake at 01.01 and nothing happened.

Am I forced to split the program in two ?

Moreover, when I started the program manually, the main screen of app was reporting 2h and 49 minutes to be run rather then 30 sec scheduled.
Also two other channels were turned yellow and some strange figures appeared. I
Then I stopped everything and went to bed !!

app 1.4.5, firmware 2.1.5(1), HW 2.1(AC)

[ottorino]

Just for the records.
On updating the firmware, also the logs are canceled, not only the programs.

[ottorino]

Thanks Samer. I actually do not remember to have dismissed the notification: but evidently this was the case

I finally succeeded to upgrade to 2.1.5: the right command for OS 2.1 was

sudo avrdude -c usbasp -F -p m644 -U flash:w:firmware2.1.5.hex
which gave

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9609
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "firmware2.1.5.hex"
avrdude: input file firmware2.1.5.hex auto detected as Intel Hex
avrdude: writing flash (56878 bytes):

Writing | ################################################## | 100% 3.97s

avrdude: 56878 bytes of flash written
avrdude: verifying flash memory against firmware2.1.5.hex:
avrdude: load data flash data from input file firmware2.1.5.hex:
avrdude: input file firmware2.1.5.hex auto detected as Intel Hex
avrdude: input file firmware2.1.5.hex contains 56878 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.71s

avrdude: verifying ...
avrdude: 56878 bytes of flash verified

avrdude: safemode: Fuses OK (H:00, E:00, L:00)
avrdude: error: usbasp_transmit: error sending control message: Protocol error

avrdude done.  Thank you.

[ottorino]

@ray: infact the app is no longer showing the red alert on the upper right. But I’m baffled: the very same app insists on telling me that the firmware is still 2.0.9. (From information: app 1.4.5)
Which part of the app is trustable ?

I lean on the side of the old firmware: the old programs are still there without restoring them from the backup

[ottorino]

It seems that I’m missing a “-F” here.

What I sent
sudo avrdude -c usbasp -p m644p -U flash:w:firmware2.1.5.hex

what I’m supposed to send

sudo avrdude -c usbasp -p -F m644p -U flash:w:firmware2.1.5.hex

I suspected this since an answer was;

> Double check chip, or use -F to override this check.

Should I “force” the command ?

@ cuteboi I already wrote the lsusb outcome in my first post

From avrdude masnual

-F      Normally, avrdude tries to verify that the device signature
                   read from the part is reasonable before continuing.  Since
                   it can happen from time to time that a device has a broken
                   (erased or overwritten) device signature but is otherwise
                   operating normally, this options is provided to override
                   the check.  Also, for programmers like the Atmel STK500 and
                   STK600 which can adjust parameters local to the programming
                   tool (independent of an actual connection to a target con‐
                   troller), this option can be used together with -t to con‐
                   tinue in terminal mode.

[ottorino]

Yes, I already sent the command as sudo, but without success

[ottorino]

@Samer
Is this the right command ?
https://opensprinkler.com/forums/topic/firmware-update-problems-hardware-version-2-1/#post-36533

[Author]

Posts