[JBinkley]

The “fi” is ok, that’s just the close for the “if”.

I believe it is there in the default rc.local, because sometimes “hostname -I” may fail because the network connection is not yet stable at the time the script runs and so the _IP would not exist and the printf would fail and the script would abort. Note that the “|| true” on the line before the if is there as an override in the case that “hostname -I” fails. If it were not there, the script would abort at that point.

The next line has the potential of failing for the same reason.

host=$(hostname -I | sed 's/ *$//g')

That’s why I added the “sleep 30” in my script. It gives the PI 30 seconds to get the network figured out before it tries to get the IP address and start the ospi.py program.

But, as I look at your script, I think your biggest issue is that you are missing the last line that actually starts the ospi.py program:

/usr/bin/python ospi.py $host$port

But, you want to make sure that is before the

exit 0

/joe

[JBinkley]

If you are running it on startup, you should be seeing something like this:

root@raspberrypi-sprinkler:~# ps -ef | grep python

root      2303  2096  0 Jul09 ?        00:06:29 /usr/bin/python ospi.py 192.168.1.60:8080

root     16020 16011  0 18:36 pts/1    00:00:00 grep python

root@raspberrypi-sprinkler:~#

In my case, I start it in /etc/rc.local, which should look something like this:

#!/bin/sh -e

#

# rc.local

#

# This script is executed at the end of each multiuser runlevel.

# Make sure that the script will "exit 0" on success or any other

# value on error.

#

# In order to enable or disable this script just change the execution

# bits.

#

# By default this script does nothing.

echo "[$(date)] rc.local executing" >> /tmp/rc.local.debug

sleep 30

host=$(hostname -I | sed 's/ *$//g')

port=:8080

cd /home/pi/OSPi/

echo "[$(date)] rc.local starting ospi.py $host$port" >> /tmp/rc.local.debug

/usr/bin/python ospi.py $host$port



exit 0

I added the “sleep 30” because it did not always seem to start properly. After I added that, it seems to start without issue.

I don’t think there would be any issue, by the way, if you just left out the host and port stuff and started with “/usr/bin/python ospi.py 8080”

/joe

[JBinkley]

Dan – I just updated to your latest. Thanks for putting that together.

I am observing one interesting little bug on the program preview. I am in California and I noticed that with some of the modifications mentioned in this thread that I don’t see the red line on the program preview for the current day when it is rather late in the day. A little while ago (at 11:20 PM PT Monday), I noticed that the red line is showing up on the Tuesday page at 11:20 PM. (http://:8080/gp?d=9&m=7&y=2013) I also noticed that the page referred to itself as the “Program Preview of Today”. So, I think there might be some confusion on the time zones in the preview page.

Edit: Opps… I should have read back a few posts. I think this is exactly what aradke mentioned. By the way, my post earlier about a single time was not really related to time zones as someone later implied. I was really talking about the potential for an intermittent problems when, during the same pass through the main loop, the time reference might be different by a millisecond or two.

[JBinkley]

Samer,

Thanks much for this!

I did encounter one small issue. The main web page broke because the Javascript loc value was not inside quotes.

This correction to line 361 seems to correct it.

        homepg += 'n'

Also, I notice both in the code that Dan provided and in some of what you have done, that we have some cases where time.time() is called both in an outer main loop and deeper. For instance, at the top of the main loop we have:

now = time.time()

and again in prog_match:

lt = time.localtime(time.time())

The differences are likely to be very small and I have not completely deciphered the logic, but that might on very rare occasions cause something unexpected. It might be better to either make the variable now a global and use that as the current time referent (or pass it as a variable). That seems to be what was done in the Arduino version. If I see any more hang issues after a couple of days, that’s an area I’ll look at more closely.

[JBinkley]

I wonder if anyone else has encountered a problem with the interval program getting “stuck”. I have 5 different schedules. What seems to happen is rather randomly, one of the stations will come on, run, and, apparently, turn-off at the right time. But the interval program seems to be a little confused and shows a status with 1 second remaining. Then, apparently none of the other stations come on.

I’ve not had a chance yet to review the code, but expect to later today, unless someone else has already discovered what could be causing this.

Thanks,
/joe

[JBinkley]

I’m just checking in on this after a couple of days heads down on work issues and it looks like you have made tremendous progress. I’m looking forward to the weekend when I can upgrade to your latest.

One thought came to mind when I saw you mentioned that only have a couple computers for testing. You can get a nearly free t1.micro instance of Debian (or many other distros) from Amazon Web Services (AWS). The micro instances are charged at $0.02/hr, but I think Amazon has a promotion where new accounts get 750 free micro hours/month. The way AWS works, you only pay for compute time when the instances are running and then a very small amount for storage while the machines are stopped.

Thanks again for the great work you have done on this!

[JBinkley]

😀 😀

Terrific! I had just put together my Raspberry PI OpenSprinkler yesterday. This morning I noticed your posts on the forums and that you had just checked in what sounded like a pretty functional build. I think I had your mobile web app running about 10 minutes later on another PI that I use for my weather station.

Putting it on the same PI as the OpenSprinkler took a little more effort, but that was primarily because I was running the interval program on port 80. Switching the interval program to port 8080 and apache to 80 did the trick. (Guess the other way around would work, too.)

A couple minor things that I’ve noticed:

• On the install screen, the iPhone username field defaults to capitalizing the first letter, but that does not seem to happen on the login screen. I had a little trouble logging in, thinking that I had the wrong password until I realized that apparently usernames are case sensitive.
• You might want to somewhere note that “Open Sprinkler IP:” could be filled with either ““, “” or “:“

Thanks for putting this together. It’s fantastic.

/joe

[Author]

Posts