I'm thinking Mr. Zimmerman didn't live where I live

[ShawnHarte]

We are both attacking the problem from different angles and arriving at the same result.

Your solution is quite accurate, works with all setups(overall better, I agree), but requires a flow meter…something that is impractical in my setup (I personally would have to place a meter on every secondary line as there is no accessible space on the primary line feeding them).

My method involves calculating volume or really precipitation rate(volume over time), this is quite the pain for subsurface if not impossible, and less accurate for drip systems, but works well for my setup, sprayers and surface drip. I suppose one could cover the sprayer and funnel the water into a container and measure direct volume of water output, versus the tuna can in the middle, I just used the manufacturers stated precipitation rate and made sure I had enough water pressure to keep it spraying at full capacity.

End of the day it sounds like we have 2 simple solutions with their own pros and cons, that provide the information needed to adjust the watering time.
I use an ET calculation to determine how much water is needed and multiply that by my calculated time to get 1mm in the total zone area, you would be doing the same with a measured time to get 1mm in the total zone area. Any rain can be subtracted from the ET calculation, so the weight of the rainfall is figured out already. If we want to water more or less we can just lie about the time it takes to get 1mm and it applies the adjustment percentage more or less.

Anyway we’ve spent plenty of time saying the same thing different ways, your example above math wise is exactly the same as mine (Volume per Time) / (Coverage Area) = Depth per Time. Which gives us a way to calculate either, depth or time needed, quickly using a computer. So my friendly (I must admit quite patient), neighbor to the North thanks for the discussion, it’s interesting to see how different people work out problems. BTW no bother on the Imperial and Metric mixing, I’m German and live in the US so either system is fine.

[Anonymous]

I’m not really even thinking there is a “my way and your way”… just that enough variables/inputs need to be available for different scenarios.

I must admit I was making an evidently poor assumption that everyone had a flow meter provided by the city as a means for billing their customers. I should know better because of course there are going to be people in places where water isn’t metered, places where meters are older models that don’t display a flow readout, and certainly places that have meters inaccessible for convenient or even possible reading. I guess I’m lucky, now that I think about it, because I just have to open my utility closet and look at the LCD readout and it tells me how many L/min are flowing (I’ve been trying to hack it so I can have a read-out on my mobile without having to go to the closet). So long as I can keep my kid from an untimely flush of the toilet, I can determine fairly precisely how much each zone uses.

I imagine if I didn’t have this city-provided meter that I’d be looking into installing one on my own, because it has been so helpful with not only irrigation needs but also determining if a toilet is leaky or what not.

Anyway. We agree: ability to make a meaningful correlation between rain and irrigation is necessary. However that is achieved 🙂

[ShawnHarte]

I have honestly never been so relieved to find out the city can charge me anything they want without me knowing. I never even thought to use the city water meter to measure water flow, mine has no display whatsoever, just a radio transmitter to the little locked box on the side of the house, with another radio presumably used to transmit the collected data to the truck that drives by to ‘read’ the meters.
That could have been quite embarrassing for me, but it is quite useful to those that have a display on their meter. I would bet at least a few people would overlook it as a reliable water flow meter, provided, free of charge to most residences in or near a city. I’ll also be calling my utility to ask about potentially having one I could monitor installed.
So anyway thanks for, perhaps unknowingly, enlightening me to another source of data for my sprinklers 😀

[Anonymous]

I see some cheap Hall effect water flow sensors available (< $20) for 1 to 60 L/min range (which doesn’t help for very low flow drip or very high demand sprinklers but should cover most cases). However, these just put out an electrical impulse. One would still need to process those signals and display the info. But it has me wondering if there’s not a product idea here 🙂 It probably has been done. I just haven’t found it yet. Altogether I figure you can probably have flow data sent directly to the OS for < $40 but someone’s got to do it.

Hmmm… would that be interesting to people? I can look at it.

[Mike]

Already been looked at and Ray has the code. https://opensprinkler.com/forums/topic/flow-sensor-working/ A flow sensor would be nice for those of us not on city water and therefore without a meter.

[Wokkeltje]

@Samer: the feature you implemented in 2.1.4 to have a minimum watering time is verry nice, but it would be nicer if we could modify the parameters in the GUI (on a station base).

thanks already for the nice product.

[john_es]

Someone mentioned that the Zimmerman math is run in the cloud… is that true? I was under the assumption that OS did not need to have an active internet connection apart from the need to get weather data from the internet.

[ShawnHarte]

The Zimmerman method adjustments to watering times run in weather.cpp on the OS, all the weather information it requires is retrieved from the weather#.py (# is a number) script which are then sent back to the OS for consumption and use by weather.cpp and the rest of the firmware. So while no, the scheduling calculations are not run in the cloud, they are inherently tied to the requirement for weather and scale data from WU or Yahoo and weather#.py respectively, and thus require an internet connection.

Hopefully that’s clear as mud or at the very least helps,
Shawn

Edit: ***Changed a bit for clarity, weather.cpp adjusts watering times based on scale, weather#.py calculates scale from weather data on WU or Yahoo***

[Ray]

Well, just a slight correction: the Zimmerman method calculation is actually done on the cloud server — OS receives a simple ‘watering percentage’ parameter from the cloud server. We are working on allowing the user to edit certain parameters and this is likely to be available in the next firmware update 2.1.5. The idea is to save user parameters on the OS side, and it will pass the parameters to the cloud server when it’s making the weather call. However, the calculation will still be done on the server side, partly to release OS from having to carry out this calculation, partly because this streamlines the handling of weather algorithms, allowing people to use new weather algorithms without firmware update.

[catalin]

Good thing you are exposing those three, Samer. Another +1 from Romania. It has been so hot these days, yet the cloud has decided to go 49% water level…

Since we are on the subject of weather control, not sure what OS is currently fetching from WU. The station appears in green as well as the developer API key. However, Hitting “Weather Diagnostics” reveals a “Mean Temp” of 18 deg C, which is.. uhm.. well perhaps that was the temperature at 3 am, but no way for mean temp to have been that, we have had 30+ degrees from noon to 19 PM.
Also, after disabling / enabling Zimmerman method the “Last Weather Call” went to Jan 1st 1970… “Last Weather Call Successful” however stayed fine. And the Watering Level went back to 100% after this maneuver. “Min Humidity” and “Max Humidity” – no idea where OS pulls those from. It currently gives me max humidity of 100%. That can’t be true, not even for Panama during the summer season 🙂

Hope you will address those issues for 2.1.5 too, thanks!

[augendoc]

I agree completely with Mr. Morehouse. Here in the central coast of California it’s a coastal desert. We do get maritime influence in the form of really cool nights (55F) but the temperature during the day will be in the 80sF right now and the wind can be howling. And it will get a lot hotter during the day by August. Some more inland valleys can see a temperature range in the summer of 40f night to 104f day in August. Right now my Zimmerman is reading about 54% and it’s just not enough water. I don’t have enough experience with this unit to know what the Zimmerman will be in August but at this rate I do know that come July-August-September I am going to have to bias the current Zimmerman recommendations.

And that gets to be a pain in the butt because it becomes the equivalent of Manual Mode, which my old controller did just fine. The weather based water control feature was why I bought Open Sprinkler.

The Zimmerman formula needs to be tweaked or perhaps a more complex formula needs to be an option. That should include wind, degree-hours and humidity. Ultimately soil moisture should be a factor, too.

[ShawnHarte]

The Zimmerman calculation works like this:

hf = 30 – (Today’s average humidity)
tf = ((Today’s Average Temp)-70)*4
rf = -((Precip Today)*200)

Scale = 100+(hf+tf+rf)

The scale is then bound to 0 to 200
If you notice the results are skewed too much in one direction or another they will often remain skewed within the same season ie summer as overall weather patterns are fairly consistent. To correct for this without manually running your program all the time I would suggest finding how much water you believe you are needing or not needing and adjusting your programs watering time by that percentage. For example you have a watering time of 10min programmed but it keeps knocking it down to 5min and you really need 8min. Adjust your pre-scaled time by +30% (100*(8-5)/10) and you will now have something the weather calculation will work with, just know that you may need to watch it for a few cycles, and if you have watering time restrictions you could run over your allotted time, though this could happen with the base calculation.
Also, his calculation works well in most areas away from large water sources ie ocean/lake, so prior to messing with the times make sure it actually needs more water. It’s easy to check by stepping on your grass, if it springs up within a couple seconds it does not need more water. Grass is ideally kept right on the edge of its drought conservation behavior, the plant will hold water near the roots and use surprisingly little water while remaining green. I used to work for a commercial irrigation company and was surprised by how much water people would put on their grass with little to no benefit, or worse causing fungus growth and killing large patches of grass. Remember, grass will yellow if it is over watered as well, so color is not the best indicator. For shrubs and other plants check with a knowledgeable person at a nursery for best watering practices, or ask how to tell if it is drought stressed.

It appears as though ET is in the works, the script used for weather adjustments has the calculations present, it just isn’t implemented at this time, so given a bit of time Ray and Samer may have the solution soon. (ET is evapotranspiration, a complex calculation for actual plant water loss based on several environmental factors, including wind, temp, humidity, and solar radiation to name a few.)

[catalin]

Very nice now that we have the 3 factors exposed. 🙂
I wish for the next version to allow per zone watering adjustment.

[catalin]

Uhm… anyone else having issues with the water adjustment % ?
It seemed to work some days ago when I fiddled with it, but having tried just now to adjust the 3 factors once again the water % got stuck on 151%. The adjustments were properly submitted and saved on the controller, so… help please!

[Samer]

@catalin Do you have the Raspberry Pi version or the microcontroller version (the one with the LCD)? If you reboot the device, does the adjustments occur?

We found a possible issue which we are resolving in 2.1.6 regarding the DNS resolution of the weather service. The DNS reply was being cached by the firmware indefinitely and because we use Amazon Elastic Beanstalk we are behind a load balancer and the IPs are liable to change.

A reboot of the controller is updating the DNS entry however this is only temporary fix. In firmware 2.1.5, we added a feature to reboot the microcontroller version because at that time we did not understand the underlying issue but knew a reboot fixed it, hence why I am asking. We are not rebooting the Pi as it may be doing other functions which we do not want to interrupt.

We now believe we understand the issue completely and will be offering a fix in 2.1.6.

[catalin]

Hi Samer,

just tried again now without reboot:
1st fiddle worked; subsequent fiddlings did not work
Rebooted
first fiddle worked, subsequent did not
Again reboot
Nothing works any longer

I am on the controller based 2.1 DIY version

Surely this is not a js issue, right ?

thanks

[Samer]

Can you explain what you mean with fiddle and what exactly is not working? Because the controller only updates the weather every one hour. So I am not sure what change you are looking for and what is occurring.

Thanks!

[catalin]

I was looking for a “Water Level: X %” feedback upon adjusting the Temp / Rain / Humidity factors. And as described, I do get it at times. (i.e. X will change sometimes)

[Ray]

First of all, if the change in the three factors are small (like changing from 100 to 95), they may not be significant enough to result in any change in the calculated water level. Second, each weather call takes some time to process, so if you are trying to change the factors too frequently it might not work. I suggest that you wait for a minute between each change and see if this makes any difference.

[catalin]

Hi Ray,

I am afraid neither of the two remarks do not apply for my case.

Thanks

[Ray]

You said ‘neither of the two remarks do not apply for my case.’ — Sorry but I don’t understand what you mean…

[catalin]

Sory, I mean neither of them apply. I.e.

>>First of all, if the change in the three factors are small (like changing from 100 to 95),

tried changing from 50 to 500 as well, and many more combos.

>>Second, each weather call takes some time to process, so if you are trying to change the factors too frequently it might not work.

I have waited for a minute already, I have waited for even days between the changes.

Thanks!

[Samer]

500 is not a valid value and the range is 0 to 100%. You may try to switch between 0 and 100 for the most dramatic difference.

Thanks

[catalin]

Good catch, I reckon the UI would benefit from validating user input. Anyway, tried 0 to 100 as well…

[Samer]

That’s a good point and will add that to the list for the next app version.

[Author]

Posts