[Andrew]

Hi Ray,

This is also something I would be extremely happy to see added. And the next step would be for it to talk to remote addresses via https as well so that the communication between them is secure.

For initial configurations a “snakeoil” or other default certificate could be used with a little message on the page suggesting generating a new certificate would be recommended (or possibly just done the first time it starts). Having the option to upload a certificate and key as well, for those of us that can sign our own, would be relatively easy. And of course there’s always the option of letsencrypt.

BUT, while this would be relatively simple of on an OSPi, it gets much harder on an ESP8266. You likely have enough ram free (about 15-20KB is about all that’s needed) having it capable of running either HTTP or HTTPS is much harder. The amount of code tends to explode as they are different enough to cause problems.

So from my experience the certificate is a relatively simple thing, supporting both HTTP and HTTPS on a small processor is much, much harder.

Cheers,
Andrew

[Andrew]

The DS2438 actually has two inputs where voltage can be read but generally only one is used as the other is designed for measuring current (it was originally created as a smart battery sensor, hence it also includes a temperature sensor) and I can’t recall if there are any limitations on it’s use.

There is also another 1-wire chip available with 4 voltage inputs. I believe places like Hobby Boards may stock a board with it on it, but I don’t recall it’s chip ID because it had a reputation for not being as reliable as the DS2438. It might be good enough for this usage though as the DS2438 is robust beyond belief. We’ve had enclosures fail and the chip kept working under water with salt build up across connections and everything was fine until eventually a pin corroded away or the buildup shorted the data line or ground to 12V. Truly unbelievably solid units.

I guess what I am getting at is that 1-wire has already solved most or all of what you are looking for and a probe that returns a 0-3V range is nothing more than soldering three wires to a board from the electronics side. A simple program (or maybe ospi.py plugin) that periodically monitors the soil moisture and then tells ospi.py to do a run-once program when needed should take care of the rest. And you can talk to the 1-wire bus through a GPIO pin, a USB or serial dongle or a network hub like the LinkHubE, though personally I’d love to see Ray add a 1-wire header to the OSPi with 5V out (and even better with a 12V pin as well!)…

[Andrew]

Hi all,

I would suggest the better method of reading from the VH400 sensors would be to use 1-wire with a DS2438. We use these to measure voltages from pressure sensors over links of more than 500m and in far worse conditions than you are every going to find in a garden. Lightning has never been a problem except when we stupidly had an earth point 200m from the 1-wire hub on one occasion.

We use standard 4 core underground (direct bury) phone cabling along with gell caps for connections. We also use send 12V down the spare wire and have a local 5V ultra low noise voltage regulator at each sensor, but that is because the pressure sensors absolutely require a 4.72-5.25V supply. The VH400 is very forgiving of supply voltage from the specs on the site.

DS2438 boards are also much cheaper than an arduino, you can address as many as you like and they will survive just about anything.

Andrew

[Andrew]

Hi Dan,

I believe the problem with the preview is time based. It appears to be fine until around 2pm localtime (UTC+10) after which it display the problem I’ve mentioned before of showing the date as tomorrow with no waterings. Clicking on today returns to today but all future waterings show as a day later than they really are (including ones later today).

As before, let me know if you need any further info and I can provide it by private message if it helps to reduce the chatter on the main forum.

Thanks,
Andrew

[Andrew]

Hi Dan,

Sorry to say I am still seeing the problem sometimes. Let me see if I can lock down what is causing it further and I’ll get back to you with the details. I’ll also send you a private message with a bit of extra CSS for improved rendering on small displays.

Andrew

[Andrew]

Hi Dan,

Hold off on looking to deep for the last problem I reported with the preview code. I just checked my timers again today and it seems okay. It goes to today correctly on opening the front page and tomorrow shows correctly now.

Before I reported the bug with “tomorrow’s” page being empty I force reloaded my browser and even tried a different browser with the same bad results. So there may be a bug in there somewhere but if there is I’m betting it is only when looking at the 2.0.3 page after it’s been running with earlier versions and the programs I had that triggered the original bug.

Thanks,
Andrew

P.S. I might have a play with some CSS at some point to make the web pages display properly on iPhones and iPads correctly again without needing any apps. It is very pretty now on a big screen but overflows horribly even on an iPad. Should be easily fixed I think.

[Andrew]

Hi Dan,

That has fixed the preview for today and the recurring waterings but brought another rather unusual one in.

When first accessing the front page it jumps to tomorrows preview until you click on the ‘today’ or ‘prev day’ buttons.
Also tomorrow’s waterings show as empty and everything after tomorrow is shifted back a day. I.e. program 4 in my example is every 2 days, today (Monday), Wednesday, Friday, etc, but the next watering shows as on Thursday, Saturday, etc. I also just noticed that program 5 which will run tonight at 8pm (4pm here now) doesn’t show on today, but it is shifted in the future like program 4.

If any of that doesn’t make any sense let me know. I’m also happy to email you more screen shots, etc if that helps rather than posting lots more to the forum until it’s all sorted if you prefer.

Thanks,
Andrew

[Andrew]

Btw, whereabouts in Australia? I assume in FNQ somewhere? We live on the Atherton Tablelands so we might be very close OSPi neighbours… 🙂

[Andrew]

Let me know if you need anything more or would like to test anything. One of the OSPis is spare for a few more days so I can break things on it without plants dying.

For the timezone, maybe the system timezone could be returned when queried by the mobile app, etc.
I am glad to hear the options setting is being fazed out, as a sysadmin it’s bugged me from the start as being a possible place of conflicting and poorer quality data… 😉

And lastly, maybe a bug report could be filed with the maintainers of raspi-config to have a record of it having been run and what has or has not been set would be very useful. Then you could query as to whether the timezone and locale have been set and if not show a set of instructions on how to fix it. The same would probably apply to other projects for appropriate settings like the camera, GPU memory split, etc.

[Andrew]

The timezone is set correctly in the OS and also in the options. There was a similar problem about two years ago with the original OpenSprinkler where the javascript didn’t cope with timezones significantly forward of UTC-5 from memory (Rob’s local timezone). I’ve pasted a copy of my programs below and my timezone is set to UTC+10.

For ‘today’, nothing shows even programs that have run and are in the log. For ‘prev day’ everything shows as expected, and for ‘next day’ all the non-recurring waterings display correctly and recurring waterings show the first watering only. I’ve attached the screen shots that should explain more clearly.

[attachment=2:3kggq1lo]today.png[/attachment:3kggq1lo]
[attachment=1:3kggq1lo]yesterday.png[/attachment:3kggq1lo]
[attachment=0:3kggq1lo]tomorrow.png[/attachment:3kggq1lo]

On a side note: can the options choice be removed and simply have ospi.py use the localtime from the system. Having it duplicated is a bit wasteful and then the options doesn’t automatically pickup daylight saving time, etc. Also if someone doesn’t have the underlying OS configured properly it can be masked by the time display in ospi.py

Thanks,
Andrew

Program 1: Every Weekday
Run: Lawn – front
Starting: 8:30 am for 0 mins 30 secs
Recurring every 8 hrs 0 mins until 6:00 pm

Program 2: Every Weekday
Run: Verandah baskets
Starting: 6:00 am for 1 mins
Recurring every 6 hrs 0 mins until 6:30 pm

Program 3: Every Weekday
Run: Tree fern
Starting: 6:00 am for 1 mins
Recurring every 6 hrs 0 mins until 6:30 pm

Program 4: Every 2 days, starting in 1 days.
Run: Front dripper line
Starting: 8:30 am for 60 mins

Program 5: Every 2 days, starting in 1 days.
Run: Lawn – verandah
Starting: 8:00 pm for 30 mins

[Andrew]

Thanks for the update.

Unfortunately for both of my OSPis the timeline for today now doesn’t show any waterings but it did in 2.0.1. I wonder if my timezone could be a problem (UTC+10)?
Also both 2.0.1 and 2.0.2 (I didn’t run 2.0.0) don’t show waterings any recurring waterings in the timelines after the first one except for ones from the log that have run.

Andrew

[Andrew]

I missed that there were other files updated this time. That is apparent by looking at the folder dates on github but I don’t see it mentioned in the README.

[Andrew]

Thanks Dan.
The whole thing is really progressing well! 😀

Just in case anyone forgets (I always do so I save the command on my Raspberry Pi) the quickest way to get the new update is:

wget 'https://raw.github.com/rayshobby/opensprinkler/master/OpenSprinkler%20Pi/software/demos/interval_program/OSPi/ospi.py'

[Andrew]

Michael is exactly right about the & at the end of the command to send it to the background and let rc.local complete. I go a few steps further. I send stderr to stdout and I invoke it via nohup to make stop any signals getting sent to it about terminals closing. Using nohup is redundant in rc.local since the system terminal can’t be closed, but it does mean that if I copy and paste the commands to start it on the command line it is always okay.

Back to getting it to run automatically… change the your /etc/rc.local to the following:

#!/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.



# Print the IP address

_IP=$(hostname -I) || true

if [ "$_IP" ]; then

printf "My IP address is %sn" "$_IP"

fi



### Setup the OSPi's RTC

#echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device

#hwclock -s



### Start the OSPi interval program

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

host=0.0.0.0

port=80

cd /home/pi/OSPi/

nohup /usr/bin/python ospi.py $host:$port 2>&1 &



exit 0

This includes two commands (commented out so they won’t run) for using the OSPi’s on board clock as well. There are a few other steps to getting that running so I commented them out here. I’ve also told it to listen on all available interfaces (0.0.0.0) so that it can be connected to by local services (like apache) on the loopback interface (127.0.0.1).

[Andrew]

Can you post the entire contents of you /etc/rc.local file?

I’ve just done a little digging to check and if you don’t specify either the ip address or port it will default to 0.0.0.0:8080 which is perfect for what you want, and hence why it runs perfectly from the command line for you. This would then be a solution for you but it is very bad practice because when you come back to it in a month or two’s time it will not be obvious what port ospi.py is running on or why it is there. And of course it would be far better to find out what is going on for you anyway! 🙂

[Andrew]

@djMax wrote:

I believe this program to be unsafe as is. It has bugs which can activate a large number of valves and cause electrical problems, in theory including fire.

Hi djMax,

Could you elaborate on this. Where do you think the bugs are that could allow this?
Also Ray has done some great work on the electronics on both the standard OpenSprinkler and the OpenSprinkler Pi. Is there something on these that has been missed that would cause a fire if you did try to open too many valves at once?

Making a claim like that as a single comment without any further info will likely get a lot of people quite defensive too (myself included, but of course I want to know about it if you have found a problem).

[Andrew]

Apache will default to port 80 because that is the assigned port for http.

And the line from /etc/rc.local with the port is the only place you need to specify it for ospi.py. Your previous post showing the following indicates that you have that set correctly:

 http://10.0.1.21:8080

[Andrew]

My apologies that I missed the desire for the web app for which you will need apache or another web server.

The problem you had is that you hadn’t changed the port to 8080 for ospi.py and it couldn’t use port 80 which was already in use by apache. Only one thing can ever use a port on one machine at the same time.

Your last post shows that you do now have ospi.py running on port 8080. Before doing anything else make sure you can access the OSPi on http://10.0.1.21:8080/ and only if that works reinstall apache with

sudo apt-get install apache2

By the way, a lesson here from a sysadmin is not to perform multiple steps and tasks at once since you won’t know which one caused or fixed the problem. And verify every step along the way. By uninstalling apache and changing the port to 8080 /etc/rc.local you will create confusion for yourself as to which did what. In this case you removed apache from running on port 80 and moved ospi.py to port 8080 at the same time. This allows ospi.py to now run but leaves you with nothing running on port 80 rather than two things competing for it.

[Andrew]

So run:

sudo service apache2 stop

(I don’t have apache installed so the service name may be slightly different. Press the tab key twice after typing sudo service to get a list of possibilities.)
Apache will start on the next boot after this though in case you still need it.

If you don’t need apache then

sudo apt-get remove apache2

will remove it from your system.

[Andrew]

If both returned

ValueError: :80 is not a valid ip address

then you didn’t have it set to try port 8080 on either attempt.

Could you post the output of

sudo netstat -anp --ip | grep LISTEN

And also, do you need apache? If not i suggest disabling or uninstalling it.

[Andrew]

As a related side note on this, if you want to know what is using what ports run

sudo netstat -anp --ip

You are mainly going to be interested in the listening TCP sockets so if you wish to ignore the rest:

sudo netstat -anp --ip | grep LISTEN

E.g. this example shows a Raspberry Pi running only ospi (python) and sshd for remote connections:

tcp        0      0 192.168.26.15:80        0.0.0.0:*               LISTEN      7324/python

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2279/sshd

The first set of addresses will tell you the IP and port (like 192.168.26.15:80 or 0.0.0.0:22 above), then second should always be 0.0.0.0:* because listening sockets are not connected to anything yet, and the end part tells you the process ID and process name of what is listening on that port (python running ospi.py is listening on port 80 above).

A busier server could have a lot more things running on it like this (notice apache on port 80 at the end):

tcp        0      0 0.0.0.0:34355           0.0.0.0:*               LISTEN      -

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      772/sshd

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      19913/master

tcp        0      0 0.0.0.0:41119           0.0.0.0:*               LISTEN      655/rpc.statd

tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      1674/perdition.imap

tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN      9831/nrpe

tcp        0      0 0.0.0.0:5667            0.0.0.0:*               LISTEN      1221/nsca

tcp        0      0 0.0.0.0:37              0.0.0.0:*               LISTEN      2611/xinetd

tcp        0      0 0.0.0.0:3493            0.0.0.0:*               LISTEN      1537/upsd

tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      32358/mysqld

tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      19913/master

tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      665/pop3-login

tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      941/imap-login

tcp        0      0 0.0.0.0:4559            0.0.0.0:*               LISTEN      1113/hfaxd

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      605/portmap

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      4439/apache2

[Andrew]

I was wondering the same but then thought that for remote connections SSH would probably be better. It’s far simpler to setup securely for the average person and using keys would mean password less authentication and encryption all in one.

[Andrew]

Maybe a way to approach the master valve/concurrent waterings would be to allow any connection to give a list of valves that should be turned on. This way you don’t have to care about master valves, etc as it is the responsibility of whatever is sending the commands not you.

An added bonus would be to say turn this list of valves on for x seconds. That way they will turn off of their own accord if the turn off command never arrives. (remote wireless valves like this would be very cool. Commercial ones are extremely expensive!)

[Andrew]

The favicon will be because it has been added to the html of the first page and has been missed on the others.

Personally I’d prefer to use a redirect in to the static file whenever it is requested. A couple of reasons:

• It’s done once and works everywhere (avoiding this potentially).
• The returned html is smaller and faster. (not a big deal but does help people connecting over the Internet or a VPN)
• The favicon query is only processed and sent on the rarer occasions that the browser asks for it.
• The favicon is not requested by any of the new frontends being created.

None of this is a big deal, just optimisation. It applies to the apple-touch-icon-precomposed.png too if you want one of these to make a bookmark on an iPhone/iPad.

Dan may have some reasons against this approach though and I’m not a real Python programmer so take that into account with my approach. I do live and work around bandwidth constrained environments though where sometimes little things like this can make a difference.

If you want to have it everywhere either copy the favicon line from the html on the first page to each of the other html generation code or add the following to the urls (near the top of ospi.py):

    '/favicon.ico', 'favicon',

'/apple-touch-icon-precomposed.png', 'appleicon',

and then this to the bottom of the script:

class favicon:

"""redirect to /static/images/icons/favicon.ico"""

def GET(self):

raise web.seeother('/static/images/icons/favicon.ico')

return



class appleicon:

"""redirect to /static/images/icons/apple-touch-icon-precomposed.png"""

def GET(self):

raise web.seeother('/static/images/icons/apple-touch-icon-precomposed.png')

return

[Andrew]

Hi Dan,

I’ve updated to the 10/July/2013 code and the program preview is wrong for our timezone (GMT+10). It believes that the today is tomorrow for the red line and the header at the top says “Program Preview of Tue Jul 16 2013” which is correct but using the url for /gp?d=17 (ie tomorrow) gives “Program Preview of Today” and shows the red line on it. There was the same issue some time ago on the regular OpenSprinkler that Ray corrected in the javascript. Not a big problem to live with though.

But I do still have a concern with trying to deal with timezones and time calculations in the code. The OS already knows the timezone and calculates the localtime accordingly. It handles daylight savings where appropriate and changes when local governments change these. Trying to duplicate all of that in the python code is fraught with problems as we’ve seen. And if you happen to miss the configuration setting in the options screen, as I did between one of the updates recently, you get very weird results of some things running generally as you would expect but then somethings run on the wrong days if the timezone settings line up badly, etc.

Can you see any problems with changing all references to time.time() to time.localtime() and remove all the timezone calculations?

I notice code like this:

dse = int((time.time()-time.timezone)/86400) # days since epoch

which doesn’t take DST into account which should become more accurate too.

There may be some places where time.time() needs to be outputted to the web to maintain compatibility with the standard OpenSprinkler javascript but I haven’t looked at how it handles the times to be sure.

Andrew
P.S. I hope I haven’t sounded to rude here. I am extremely impressed with the work you have done.

[Author]

Posts