- This topic has 29 replies, 8 voices, and was last updated 9 years ago by
.
-
Posts
-
Hi all,
I’m using a RPi2 with the unified firmware.
I’ve been having problems with schedules starting up automatically. Well, today OS started the schedule automatically. Three of my four zones ran the correct duration, but one zone scheduled for 10 minutes ran for 45 minutes.
On the edit program page there’s a section for ‘Additional Start Times’, but both values for the section are set to zero.
I’ve attached an image to this post. The zone named ‘Front yard Main’ is the one that had the issue. You’ll see in the program preview screenshot it being scheduled to start at about ~07:05 and end at ~07:15. But in the log table, you’ll see the runtime at 45m 40s.
Can anyone suggest any remediation to this issue?
Attachments:
Well I can’t reproduce the issue. I imported the configurations you sent to me and ran it for a day. The program ran correctly and I didn’t find any issue with the running time.
Hi Ray,
Thank you for your support and response.
I was wondering if you could suggest any data collections that I might execute if the issue occurs again. Or, is there some sort of tracing/verbose mode that I can set to monitor?
just a “me too”, and I cant reproduce it either!
In my case, running my stations via the “run once” menu resulted in them running for semi-random longer-than-scheduled times. My five stations were meant to run sequentially with 10, 20, 10, 20 and 20-minute runtimes. The actual runtimes were 19:22, 27:28, 30:00, >64min, and >53min. The last two were still running when I manually aborted the run-once schedule.
The actual observed runtimes agreed with the log entries. Since the runtimes were much longer than normal, but the station start times were correct (staggered by exactly 10 or 20mins from the previous station), this meant that the stations were running in parallel for a lot of the time. At least I know that my 24V power supply can handle several solenoids at once!
This is all with the latest unified firmware on a RPI model B. As I mentioned, after deleting the scheduled program and re-entering it, and rebooting, I am unable to reproduce the problem. Both a run-once for 30 seconds per station and regular scheduled program executed perfectly the next day.
Of course, since then it has rained continuously and I’ve disabled the schedule until things are less soggy, so I havent tested any further.
To help diagnose the problem, could you let me know:
1) Did you use the pre-configured SD card image, and then installed and switched to the unified firmware?
2) or Did you start from a fresh raspbian image, and installed the unified firmware?
3) Did you configure the system to use the DS1307 RTC in any way?Basically I need to be able to reproduce the issue in order to debug the code. Thanks.
Hi Ray,
Once again, thanks for your support and response.
Since I’m running a RaspberryPI 2, I was not able to boot it using the pre-configured SD image you provide on the site.
So what I did was download the latest Raspbian image and then pulled the unified firmware down from github and built it.
I did NOT interact with the RTC.
Just a quick update.
I rebuilt my RPi2 image and decided to start a program manually.
The first zone started up immediately, but at that exact moment the web interface was lost. Attempts to reconnect resulted in a ‘connection refused’ browser message. I was still able to ping the pi, and also shell into it.
I let it run past the scheduled duration, and it didn’t stop automatically. I ended up power cycling it to stop the current watering job.
Upon reboot I decided to run another zone, but did so via the home page, and not via a ‘manual program’.
During that job the browser stayed up, but reported a network error. Pings to the unit failed. That job continued to run past its scheduled duration. Power cycled the unit.
I decided to try using a powered USB hub with my USB wifi. I’m using aEdimax EW-7811.
http://www.amazon.com/dp/B003MTTJOY/ref=pe_385040_127745480_TE_item
The next manually started zone ran to scheduled completion, and the browser/network remained up throughout.
Following that, I started my last zone and everything worked as expected as well.
I’m going to go back to an older RPi model this weekend and give that a go. Living in Southern California and with all the visibility about watering lawns, I really need to be able to trust my sprinkler timer. And I don’t want to dedicate a powered USB hub, if it turns out the RPi2 is just too power hungry.
How much current is supplied to the RPi during a sprinkler job?
Regards.
In my case, the problem occurred on an up-to-date raspbian image with the unified firmware installed/built manually.
I have configured the DS1307 RTC. Its on the network 24/7 and using NTP. The ntp logs show this keeps time to within 100ms (and my understanding is that the minor NTP time adjustments are fed back to the RTC. It is networked via an Edup rtl8192cus USB dongle, no USB hubs or anything.
We did some extensive tests and it turns out that setting the firmware to run as cron job may have lead to the issue. So we’ve changed to use a startup script to set the program to run on startup. If you perform ‘git pull’ you should see a newly added file build.sh. It will compile the firmware and add a startup script to /etc/init.d/. Make sure you remove the existing entry on crontab (sudo crontab -e, remove the last line). Then restart RPi and see if it works. Thanks.
Ray,
Should the rest of us do this too?
If so, is the command just git-pull with no options? or sudo git-pull? or?
Hi Sean, here are the instructions:
1) go to the firmware folder (should be OpenSprinklerGen2 by default)
2) run ‘git pull’, you don’t need to run it in sudo
3) run ‘./build.sh ospi’. This will compile the firmware and install a script /etc/init.d/OpenSprinkler
4) run ‘sudo crontab -e’ and remove or comment out the last line (which was added when you installed the unified firmware initially).
5) restart, and check if you can access http://x.x.x.x:8080 where x.x.x.x is your RPi’s IP address.I will check with Samer if I’ve missed anything here, but I think that’s what I did last night.
By the way, you should export your current configurations before switching. The reason is that your current programs and settings are stored in a file name nvm.dat, and that file exists in different folders when the firmware was started as cron job vs. started as /etc/init.d job. So after you switch, you may notice that all settings and programs have been reset to factory default. There are two ways to restore: one is to import the configurations, the other is to locate the nvm.dat and simply copy it and overwrite the one in your OpenSprinklerGen2 folder. Of course if you don’t mind you can always just re-create the programs and settings.
Hi Ray,
Thanks for your support.
I just performed the update as suggested. A few things caught my attention.
During the build, the following was output:
——————————–
Building OpenSprinkler…
Adding OpenSprinkler launch script…
update-rc.d: using dependency based boot sequencing
insserv: script OpenSprinkler.sh: service OpenSprinkler already provided!
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
Done!
——————————–
The last 3 lines caught my attention. Should I be concerned?
I built this image by following the recipe Claudio provided in a separate thread.
Also, I noticed that after building and rebooting, my settings where still intact. You seemed to indicate that a config import was necessary, so I’m wondering if something is miss-aligned on my build.
Lastly, when I run the crontab -e, it reports that there is no crontab for root nor pi. Unsure how to explain that – it’s as though it may not have ever been set.
Regards.
Thanks also for hunting this down. However … FWIW my system never used cron to run any opensprinkler stuff. The firmware is started directly from rc.local at boot time. It changes directory to the opensprinkler install dir first to make sure it always finds the right nvm.dat file. Though I suppose it is plausible that my tinkering accidentally caused some nvm.dat confusion.
A standardized init.d startup is better anyway, so I’ll switch to that. But I wont be able to test for a while, since its still raining here.
I’ve performed the same upgrade & seemingly all went okay. As s3v3n7w0 mentions, though, I never had to restore my settings and my crontabs were empty. Did the upgrade not work correctly?
I’ve been noticing similar behaviour to those above today whereby an 8-minute manual run of one station never stopped, continuing for over 2 hours until I noticed the problem and issued the ‘stop all stations’ command via the app. Curiously, at the time, the interface wasn’t reporting any station running, but the logs now show the true duration.
Separately, this happened again with a 5-minute run — the station ended up running for almost 2 hours. Seemingly, it only stopped when I re-opened the OpenSprinker app on my phone to check if the program had completed. Again, the app wasn’t reporting anything running, but reports the true duration.
Also, I’ve noticed my OpenSprinkler fails to run scheduled programs entirely on certain days, but this might be a different issue. I’ll create a separate forum post for it.
App Version: 1.4.1, Hardware Version: OSPi, Firmware: 2.1.3, Raspberry Pi B, Installed using latest (at the time) image and followed upgrade instructions.
Today was the first sprinkler job since updating as Ray suggested. Everything ran okay.
One thing that David mentioned that is similar to my situation, is when I first discovered the zone running for too long, bringing up the web interface did seem to trigger it to stop.
I’d also like to mention that I’ve been having problems with my wifi dropping out, which there does seem to be some history with the RPi and Edimax interfaces.
Apparently there’s an issue with the interface going in to a low power mode. I followed the guidance here last night: https://learn.adafruit.com/adafruits-raspberry-pi-lesson-3-network-setup/test-and-configure#fixing-wifi-dropout-issues
It’s too early to say for certain that it’s a fix for my situation, but the results so far have been positive.
With respect to the cron report, I think that’s due to the guidance one follows. When I was first experimenting installing OS, I followed Ray’s guidance in the following thread. He has you add a cron job.
However, most recently I followed Claudio’s guidance in this thread.
In Claudio’s write-up, he has you adding the startup to init.d. So I think that might explain why I didn’t have a cron entry, and possibly why the build script I ran last night complained about the following:
update-rc.d: using dependency based boot sequencing
insserv: script OpenSprinkler.sh: service OpenSprinkler already provided!
Since OS starts on bootup, I think I’m okay on this respect.
It would be nice to get confirmation that the rc.d script that Claudio provides is the same that Ray is using in his latest build.
I’ll continue to monitor and report back if I see any problems with the scheduled job time durations.
@s3v3n7w0, I’d had issues with my wifi as well but changed from a generic eBay wifi adapter (edup brand, RT5370 chipset) that has known issues with the Raspberry Pi to a TP-Link TL-WN725N & no further wi-fi connectivity issues. However, my scheduling issues persist and appear to be worse, with no schedules running automatically at all now. The OpenSprinkler process is running fine via its init.d script, so the problem I’m experiencing must be internal to the OS code.
Hi David,
Thanks for the tip. Moving forward I’ll start using that TP-Link model of nano adapters for other projects.
I can report that after making that change though, I haven’t had a dropout yet. It has been the longest I’ve been able to maintain immediate connectivity throughout my periodic tests to see if I can still reach the Pi.
I also had power issues so I’ve made a small case mod and powered the Pi independently via the mini USB connector, which cured the problems.
I share David’s issues with no schedules running automatically at all. As per my other post (https://opensprinkler.com/forums/topic/programs-only-seem-to-run-when-website-or-app-is-open/), the programs only run if the either the app or Web page is open.
Here’s an update on my end.
I spoke too soon about the wifi. When I checked this morning, OS was unavailable via the web, and my programs did not start automatically.
After a reboot, I ran the one time program option, and the first zone completed and the second zone started up.
During the second zone start, the web interface dropped out again. The second zone ran past the scheduled time, so I bounced the PI again.
Next, I just did a manual one zone run from the homepage – it ran to completion, and web was available throughout.
I started my last zone via the homepage. Web interface dropped out, and it exceeded the duration, so I power cycled the Pi to stop it.
It would be nice to get a standard build image that supports the RPi2, so we can level set the environments everyone is running.
One thing I thought I’d clarify.
It may not be in all cases for me that the Pi loses it’s wifi connection. Up until now, when the web interface becomes unavailable, I’ve assumed the wifi went to sleep.
I was just checking on the unit, and came to notice that the web interface seems to go out to lunch, and rejects the HTTP requests.
But the Pi is still available over the network and one can shell into the unit, even though browser access attempts on 8080 are rejected.
It does seem to at least anecdotally backup Tony’s opinion that the issue is related to the webserver.
I think I’ve nailed it to the web server.
Everything works when the app or webpage is open. If I leave the app running in the background and client and server maintain contact everything works.
If there’s a loss of contact between client and server It fails to start or finish
Everything is being run on the client side except the saving the settings.
Server side would be better as the client would simply update the server.
Client outages wouldn’t matter.
Have the exact same problem, without the webinterface program’s dont run at all. If i leave the webpage open everything works. If i make a program that runs lets say for 10 minutes, and i keep the page open it starts… if i close the page after lets say 5 min’s the valve keeps open until i open the webpage again (15 min, 60, a day..)
I dont know the ins and outs but seems to me that the process that runs the schedule stops without the webinterface.
If i can help finding a solution please let me know…
We are looking into this and appreciate everyone’s feedback regarding the problem. It is clear many users are having the same problem. The OSPi/OSBo release for the Unified firmware is currently in “beta” but we did not expect a bug of this magnitude.
We will let everyone know once this has been fixed however in the meantime you may switch to using Dan’s Python program or Richard Zimmerman’s sprinklers_pi while we get the Unified firmware fixed.
Thank you for your patience.
Thanks for looking into this!
For the interested, I’ve reverted my OpenSprinklerGen2 code to this revision and manual runs appear to work correctly with the app/website closed. This was the first revision I’d ever checked out and most things appeared to be fine at that specific commit so they should seemingly be fine again now. I’ll report back about scheduled runs tomorrow.
- You must be logged in to reply to this topic.