[s3v3n7w0]

Hi Ray,

Thanks for your support.

I loaded the updated firmware before my sprinkler job today.

My first zone ran okay, but during the second zone run, my browser reported a connection error in red across the bottom of the page.  After this occurred, the zone ran past its scheduled duration, and I needed to PS/OFF the unit to stop it.  All zones subsequently started manually finished properly, however, the browser connection stayed up through its duration.

 

[s3v3n7w0]

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.

[s3v3n7w0]

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.

[s3v3n7w0]

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.

[s3v3n7w0]

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.

https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-3-for-avrrpibbblinux/

However, most recently I followed Claudio’s guidance in this thread.

https://opensprinkler.com/forums/topic/tutorial-install-opensprinkler-unified-on-a-fresh-raspbian-image-for-a-pi-2/

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]

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.

 

[s3v3n7w0]

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.

[s3v3n7w0]

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.

 

[s3v3n7w0]

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?

 

[s3v3n7w0]

Quick update, the program started automatically today.  Unsure what happened earlier this week.  I will continue to monitor.

Thanks again for your kind attention Sean.

 

[s3v3n7w0]

Hi Sean,

Thanks once again for your assistance.

To be clear, I do not have a rain sensor, and the checkbox for Rain Sensor under Weather Control is NOT checked.

I’ve attached my configuration export, with the weather underground key replaced with F’s.

My next scheduled run start tomorrow at 06:31 Pacific.  I’m wondering if there is any guidance that could be suggested to login and poke around the shell in the event the sprinklers don’t automatically start.

Regards,

72

 

**Edited reply to upload zipped backup, didn’t notice the json file was not permitted earlier.

Attachments:

1. backup.rar

[s3v3n7w0]

Hi Sean,

Thanks for your response.

I’ve confirmed that the program is enabled.

Weather adjustment is unchecked.

Weather diagnostics report the current values.

The view logs table does report the last several entries for when it watered, however, these watering intervals where triggered by a manual ‘Run Program’ from the Edit Programs page.  I did the last several times when I realized that the program was NOT starting up automatically.

The preview programs for the next scheduled day looks right – I see a block of time for the 4 stations scheduled.  If I advance the view to the next scheduled day, it shows the blocks starting a bit earlier to correspond to the Sunset start time parameter.

I’m not using a rain sensor, and while I have a weather underground key, the adjustment is set to manual and the % water is set to 100 (default).

From my view, everything looks right.  As mentioned the first time it was scheduled to run everything ran fine.  It’s only after the subsequent scheduled runs did it fail to start and required manual intervention to run the program.

Next scheduled run is tomorrow.

Is there any advise what I should be looking at in the event is does start up automatically tomorrow?

Regards,

72

[s3v3n7w0]

Hi Samer,

Thank you very much for your quick response and support.

Best regards.

[Author]

Posts