Forum Replies Created
-
Posts
-
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.
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.
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.
@sean: using “sudo reboot” should be quite safe, as it syncs by default according to the manpage on raspbian. Only if you used “sudo reboot -n”
would it not sync.
Kim.
> One solution is to add a short sleep at the end of the loop to give the CPU some spare time.
Yes, I thought about this but, not understanding the code, was reluctant to change things in
case I accidentally started turning the solenoids on and off every 10 milliseconds or something.So, a quick test of adding a usleep(10000) to the end of the loop (ie, 10ms delay) has reduced the CPU usage to
about 2% when idle, and the system still works, and the solenoids havent exploded 😉Thanks.
Kim.
