- This topic has 103 replies, 22 voices, and was last updated 8 years, 4 months ago by
.
-
Posts
-
Hi Feri,
Due to recent changes in Hungarian weather (rain, low temperature) the 0% watering level is the expected result of Zimmerman calculation IMO. I know how cold it is nowadays. I live in Budapest 🙂 I even shut down my opensprinkler and switched on heating instead.
Read through this thread:
Attaching capture of weather diagnostics.
Firmware 2.1.6(1)
removed weather location and readded – changed from zimmerman to manual and back no change.default zimmerman options.
How is it calculating 0% with the diagnostics below.
Attachments:
yet again today. latest pull from git. rebuild and “surprise” after changing to manual weather adjustment and moving slider to 100% and then back to zimmerman its back to 100% without any impact based upon the zimmerman algorithm. successful weather calls though.
Attachments:
Ray,
Any chance of working on this bug in the near future? It seems to be affecting a few people.
Here in SoCal it has rained so infrequently that manually readjusting 0% to 100% has not been needed very often. Hopefully that will change.
Bill
So can I clearly get an answer as this is a big that is not being worked or is this being worked?
While I understand this is an “opensource” project reviewing code to see if I can fix got me to wondering as things are shifting to Opensprinkler being pivotal to the application running.
Specifically my prior 30 year old controller did basically everything this can do now because of this bug. If Day and crew are busy developing a new version to be able to use big data or sell/offer a service instead of fixing a core function – please be clear.
This is an app that impacts real world objects and historically controllers slated with this responsibility are rock solid. Ignoring a bug that impacts a high value function erodes confidence.
My sprinkler guy asked me what my controller was and I had to tell him to pass as it was for tinkers only…..that hurts.
To isolate the problem, the first thing to check is if the weather algorithm is outputting reasonable numbers. To do so, open a browser and type in the following command:
http://weather.opensprinkler.com/weather1.py?loc=xxxxx&key=xxxxx
substitute the first xxxxx with your location (such as zip code), and second xxxxx with your Wunderground API key. The output should contain a number called scale=xxx and that’s the percentage it calculated.The weather algorithm is explained here:
https://opensprinkler.freshdesk.com/solution/articles/5000017312-using-weather-adjustmentsIn your particular case, it could very well be that the weather condition happened to result in 100% (humidity is slightly above 30%, and temperature is slightly above 70F).
No this isnt a “perception” error on my part. Output: &scale=0&rd=-1&tz=28&sunrise=343&sunset=1235&eip=1124396973
100% on the weather diagnostics and main page still.
Your post assumed I had not done the calculation manually to validate.
From your post I can assume your approach is no software issue but user issue.
Also disappointed as the diagnostics clips above when used for calculation do not match your algorithm….I posted them to be helpful.
sorry for the prior snarkiness (late in the day posting not recommended).
After reading the latest weather.cpp decided to run Opensprinkler from shell via SSH and the output of the weather call got me looking.
Today using the weather url directly after a reboot:
&scale=22&rd=-1&tz=28&sunrise=339&sunset=1238&eip=1124396973
but weather percentage remains at 100% with good weather responses BUT initially there was NO good response. Now your initial url call does an redirect and wondering if the initial parse loads a value that introduces an issue.Specifically:
if (findKeyVal(p, tmp_buffer, TMP_BUFFER_SIZE, PSTR(“scale”), true)) {
v = atoi(tmp_buffer);
if (v>=0 && v<=250 && v != os.options[OPTION_WATER_PERCENTAGE]) {
// only save if the value has changed
os.options[OPTION_WATER_PERCENTAGE] = v;
os.options_save();who cares if it has or has not changed – write it out. symptomatically this check would stop the change of the scale os.options. Is it possible you hit a value (response to a bad response or similar) that causes this to read as not changed and thus not written out.
Ray – just as I was specing what i needed to mount a photocell to my garage rails i see you have the OpenGarage! $45 and it has ultrasonic sensors!!!! Problem solved. Ok where did I put that credit card!
“// only save if the value has changed
who cares if it has or has not changed – write it out. symptomatically this check would stop the change of the scale os.options. Is it possible you hit a value (response to a bad response or similar) that causes this to read as not changed and thus not written out.”There is a particular reason why it only saves the value if it has changed: to reduce the write cycles of EEPROM. Because EEPROM has a limited number of write cycles (conservatively 100,000 but most likely around 1000,000), it needs to be factored in to avoid wearing out EEPROM too fast. So yes, it needs to be cared for.
I’ve started to debug the weather script today. There are a few things to keep in mind which may explain the discrepancy between the direct weather call result and what the firmware receives:
1) the location: because the UI/app converts location string to GPS coords, make sure that when you run the script directly, use the GPS coords (you can find this out by checking http://x.x.x.x/ja?pw=xxx where x.x.x.x is the IP address and xxx is the MD5 hash of the password). The “loc” field you see in the output is the GPS coords. I’ve done a few experiments in the past and saw that the weather output for using the GPS coords and city name (or zip code) are quite different, even though they are in roughly the same location. I will try to find out why, but it’s most likely due to the difference in the WUnderground weather data returned for GPS coords vs. location name.
2) Check the ‘last successful weather call’ time stamp and make sure it’s relatively recent. If the last successful weather call is not valid or very old, that means the controller is not receiving the weather call result correctly, and this can very well explain why the controller’s watering percentage is not changing.
3) I know this is trivial, but do make sure you’ve selected Zimmerman as the Weather Algorithm. Sometimes users may have temporarily changed it to ‘Manual’ and forgot to change it back. Then the watering percentage certainly won’t change.
“Ray – just as I was specing what i needed to mount a photocell to my garage rails i see you have the OpenGarage! $45 and it has ultrasonic sensors!!!! Problem solved. Ok where did I put that credit card!”
–> OpenGarage is available for purchase here: http://rayshobby.net/cart/opengarage
1 – Used the GPS coords that are stored in the dat file to test (as well as manual) in stead of just zip code – same results.
2 – This AM last successful call as at 8:01am checking at 8:28am – still at 100% without change.
3 -selected asn submitted again just for good measure. No change.as a note – leaving this as is in case theres something you needed to shoot but likely will reformat SD card and start from scratch with MANUAL entry of programs in order to avoid this being an artifact of repeated upgrades etc.
“Used the GPS coords that are stored in the dat file to test (as well as manual) in stead of just zip code – same results.” –> just to make sure I understand what you meant by ‘same results’: I assume you were directly calling the weather script by providing the location, Wunderground API key, and your device password. So by ‘same results’ you mean the returned watering percentage is different from 100% (which is what your OpenSprinkler is showing). Or did you mean that using ‘GPS coords’ and ‘zip code’ result in the same watering percentage? The important thing to verify is whether the watering percentage showing on your OpenSprinkler is consistent with the direct weather script call. If not, it’s often due to either the difference in location (GPS coords vs. zip code) or it’s because the controller did not get weather call result correctly (check the last successful weather call time stamp).
hi
most of the WU station gives me
Percip yesterday = 0
Percip today = 0it is impissible, yesterday evening and today morning there were a lot of big rain in this area.
There is mud in the garden, but system started the irrigation.so i changed weather adjustment to manual. 🙁
feri
Hi Feri,
Those WU stations have no rain sensor that is why they report zero precipitation.
Find another WU station nearby your home.Ákos
the results of using either my zip code or gps co-ords in the direct url are the same and result in a non 100% weather percentage which is what mine is stuck at. I see that weather cpp has permissions and code changes 13 days ago and recompiling and committing. Otherwise tired of the controller watering right before a rain storm and will reformat the sd card and start over.
recompiled and restarted = no help. Changing any of the weather variables has no impact to the 100% weather indicated for the watering percentage. Changing the manual percentage and then changing back to the zimmerman…..the percentage stays the same as what the manual was even after a “successful” weather call. Changing to auto rain delay also retains the manual percentage but grays it out in settings. Setting back to the zimmerman method then sets the last weather call to null and the last successful weather call being immediate before the diagnostics call.
The Zimmerman method doesn’t seem to work on my rev 2.1.6 firmware.
I’m in California, no restrictions enabled, getting weather updates continuously using my API key. Percentage is stuck at 36% for weather conditions near the baseline.
Reset to manual and 100% and then back to Zimmerman results in the 36% again.
The “adjustment method options” don’t seem to accept my changes. e.g., there’s no indication of options changed when I submit.
A bit hard to decipher the history, but it appears this is a bug correct?
What’s the status?
Thanks.@chickenmad: to make sure I am on the same page: are you hosting the weather script yourself? You mentioned recompiling the weather code so I assume you are hosting it on your own server?
@kabbak: the adjustment method options not changing may be due to a recent change and could be a bug. We will check this right away.@kabbak: I just checked it on my test OS 2.3 and the weather adjustment options seem to be working. One thing to check is: if you have OS 2.3, you can try to take out the microSD card, insert it to a computer (you may need a micro to SD adapter), and check the WTOPTS.txt, which stores the weather options.
If your OS is an older version (2.0 to 2.2), note that it may not have a built-in microSD card, and weather options require microSD card. You can insert a microSD card yourself.
If you have OSPi, you can ssh to it and view the content in wtopts.txt directly
I have few weeks old OS white box. HW 2.3, firmware 2.1.6.
Messing with the SD card is a bit much.
Does someone in Northern CA have my setup that DOES use Zimmerman correction correctly? Mines stuck at 36%.
Thanks.Ray – running unified firmware on an up to date Raspbian image. both latest and recompiling meant the git pull (force) and rebuild. SO behind on so many personal things that I feel bad I havent had a chance to look at your code and sniff the response the sprinkler is getting when it does the update. I will span the port off of my switch that services the AP on that end of the house and look at the packets during a weather update and if interested can post those to a public wireshark area for you to look at. relies on my honey do list, kids baseball and work to calm down a bit.
Really thinking this has to be an artifact from multiple upgrades and an option remaining in place that causes this to go south and the best path for resolution isnt to make you folks tail after this but see if a reimaged card and install WITHOUT importing the options from the app/file does the trick.
On a different note – love the OpenGarage – can I suggest a twist of it? Mounted on wall in front of the vehicle and using it to key vehicle arrival AND light a remote red/yellow/green LED for parking purposes. Again – if I had more time I can see everything you need is right there but time time time. Also – was thinking of whether I could use the door path sensor (photoelectric eye) that exists on the garage to trigger a pin on the unit to know when thats been hit i.e. not only did the door open BUT something passed through or when I leave the garage door open (long way from the garage to the front door and friends like to surprise us by coming in from the garage) triggering a notification that somebody/thing just passed the beam.
@kabbak, my Zimmerman method is working on 2.1.6. Would you be willing to post your zimmerman option settings and the Weather Underground station’s pws ? Happy to check to see if I get the same results.
A couple of quick questions:
1) Can you tell us the exact version number of the firmware i.e. 2.1.6 (1) or 2.1.6 (2).
2) When you say “the adjustment method options don’t seem to accept my changes” do you mean one of the following: 1) you change the options, press submit and then restart OpenSprinkler but the changes have not been remembered, 2) that changing the settings is remembered but seems to have no impact on the watering % or 3) there are options in the UI that you cant edit e.g. baseline temp/rain/humidity.
- You must be logged in to reply to this topic.