Forum Replies Created
-
Posts
-
No trouble to report since your script update and the reimage from scratch.
Thanks.
Also as an FWIW :opensprinkler with a 12v battery and electric matches makes an awesome fireworks controller…..not that anyone would ever do that
Second day with successful Zimmerman watering. Reimage the SD Card and manual data entry did the trick.
@Ray any reason your OSPi image doesnt turn on the BCM2708 watchdog by default? Since this system fits the bill for an embedded system seems like a no brainer.#Ray
Did a fresh install using your OSPi image. Left it on Wheezy. Manually entered the config entries instead of import. Weather diagnostics has a nice fresh couple of dates in it after configuring it to use my location, WUNDERGROUND key and turning on Zimmerman method BUT by manually calculating the Zimmerman method it is significantly below 100% but still the watering percentage remains at 100%.
Next up – spanning the port and providing you a wireshark capture showing the server request and response.
Not sure what else I need to do to reinforce that this isnt user error.
Also – the guide uses an off the shelf WPA_Supplicant advice but that doesnt make the WIFI aggressive reconnect. WICD-CURSES (lazy hate nano’ing/vi all over the place) might be the best package to include in your image since its menuing will hit the middle of your audience.
*****update – turned off Zimmerman – set to rain delay – turned back on Zimmerman and now calculating as Zimmerman predicts. Will let this bake for awhile BUT gonna have to assume that from the initial image I setup whenever the Unified firmware came out to now that an artifact caused this issue and the new image does not carry that forward.
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.
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 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.
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.
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.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!
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.
Also disappointed as the diagnostics clips above when used for calculation do not match your algorithm….I posted them to be helpful.
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.
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.
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:
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:
changing to wunderground now remained stable. didnt look at permissions for offending file or write it out – perhaps just corrupted somehow.
Thanks!
that did the trick
offending weather_adj.json:{“auto_delay”: “off”}
new:
{“weather_provider”: “yahoo”, “wapikey”: “”, “delay_duration”: “1”, “auto_delay”: “on”}
the old one was generated after i entered to use wunderground…hmmm will experiment and try that again just to isolate.
sorry:
/home/pi/OSPi# python ospi.py &
[1] 5344
/home/pi/OSPi# The Python module apscheduler could not be found.
Setting water level to 100%
plugins loaded:Starting timing loop
http://0.0.0.0:8080/
192.168.1.39:63440 – – [08/Aug/2014 18:48:41] “HTTP/1.1 GET /api/status” – 200 OK
192.168.1.39:63440 – – [08/Aug/2014 18:48:41] “HTTP/1.1 GET /api/log” – 200 OK
127.0.0.1:47999 – – [08/Aug/2014 18:49:05] “HTTP/1.1 GET /” – 200 OK
127.0.0.1:48000 – – [08/Aug/2014 18:49:05] “HTTP/1.1 GET /sn0” – 200 OK
192.168.1.39:63443 – – [08/Aug/2014 18:49:11] “HTTP/1.1 GET /api/status” – 200 OK
192.168.1.39:63443 – – [08/Aug/2014 18:49:12] “HTTP/1.1 GET /api/log” – 200 OK
192.168.1.39:63449 – – [08/Aug/2014 18:49:42] “HTTP/1.1 GET /api/status” – 200 OK
192.168.1.39:63449 – – [08/Aug/2014 18:49:42] “HTTP/1.1 GET /api/log” – 200 OK
127.0.0.1:48001 – – [08/Aug/2014 18:50:04] “HTTP/1.1 GET /” – 200 OK
127.0.0.1:48002 – – [08/Aug/2014 18:50:05] “HTTP/1.1 GET /sn0” – 200 OK
192.168.1.39:63469 – – [08/Aug/2014 18:50:12] “HTTP/1.1 GET /api/status” – 200 OK
192.168.1.39:63469 – – [08/Aug/2014 18:50:13] “HTTP/1.1 GET /api/log” – 200 OK
Traceback (most recent call last):
File “/home/pi/OSPi/web/application.py”, line 239, in process
return self.handle()
File “/home/pi/OSPi/web/application.py”, line 230, in handle
return self._delegate(fn, self.fvars, args)
File “/home/pi/OSPi/web/application.py”, line 420, in _delegate
return handle_class(cls)
File “/home/pi/OSPi/web/application.py”, line 396, in handle_class
return tocall(*args)
File “/home/pi/OSPi/plugins/weather_adj.py”, line 150, in GET
return self.render.weather_adj(get_weather_options())
File “/home/pi/OSPi/web/template.py”, line 881, in __call__
return BaseTemplate.__call__(self, *a, **kw)
File “/home/pi/OSPi/web/template.py”, line 808, in __call__
return self.t(*a, **kw)
File “templates/weather_adj.html”, line 39, in __template__
Wunderground
KeyError: ‘delay_duration’192.168.1.39:63469 – – [08/Aug/2014 18:50:16] “HTTP/1.1 GET /wa” – 500 Internal Server Error
along this line for those with concerns on the OSPi – an option to write these specific log entries to rsyslog would be nice. Already have all syslog going to a central syslog server and having already run through corrupt cards on my other RPi due to too many writes trying to cut down on writes is an admirable goal.
Part of me was thinking about process to make the status part of an SNMP MIB with dwell time on a zone/sensor/pin as a pollable value. Currently polling this with MURLIN from a Cacti site and looking for the rain sensor trigger as well as zones in action. Threshold set to alert me if a zone is on for a specific time or sprinkler controller stops responding.
