Wrote some code over the last few weeks, and better yet it works. :-)

Posted: July 24, 2014 in Hacking, Hardware, Linux, Raspberry PI, RPi, Software
Tags: , , , ,

Pondering

After writing the pseudo code for the watering program, I let it simmer for a few days and then started on real code.  First thing I did was write a config file in the json format.  The target was to describe the watering zones in the system. ow many there are, should the program use syslog to log actions, and finally is there a rain moisture gauge attached and if so what kind is it (for now I only tackled a digital gauge that is either open or closed on GPIO 15), and there is a version number so I know what the file might contain as it evolves.  And yes the zones are 0 based, this file is not really meant for human consumption, though its pretty easy to read really.

Config.json

It looks something like this:

{
    "version": 0.1,
    "controller_name": "this watering system name",
    "log": 1,
    "zones": {
    "total": 8,
    "zones": [
       {
           "zone": 0,
           "name": "Human name of zone 0"
       },
       {
           "zone": 1,
           "name": "z1"
       },
       {
           "zone": 2,
           "name": "z2"
       },
       {
           "zone": 3,
           "name": "z3"
       },
       {
           "zone": 4,
           "name": "z4"
       },
       {
           "zone": 5,
           "name": "z5"
       },
       {
           "zone": 6,
           "name": "z6"
       },
       {
           "zone": 7,
           "name": "z7"
       }
      ]
    },
    "gauges": {
        "rain_moisture": {
            "present": 1,
            "bus": "GPIO",
            "type": "D",
            "device": 15,
            "signal": "NO",
            "use": 1
        },
    }
}

Watering

Once that was done and tested I located an open source json parser library that could parse that in easily.  No point in reinventing a wheel when there are perfectly good ones available.  The parser I ended up choosing was parson.  It’s lightweight and pretty easy to use. You can find it here and it uses the The MIT License (MIT) so all good open source stuff. Next I needed a watering program stored in json format.  So it contains the human name of the watering program, an option to use or not use the rain moisture gauge, then the zone info, including the count and zone info including zone number, how much water to deliver, the amount to deliver at one time, and a version number so we can track the file as it evolves.

wp1.json

{
    "version": 0.1,
    "program_name": "3 second watering",
    "use_rain_moisture": 1,
    "zone_info": {
        "total": 8,
        "WaterCycleExtraDelay": 30,
        "zones": [
            {
                "zone": 0,
                "WaterLength": 3,
                "WaterCycle": 2,
            },
            {
                 "zone": 1,
                 "WaterLength": 3,
                 "WaterCycle": 2,
           },
           {
                  "zone": 2,
                  "WaterLength": 3,
                  "WaterCycle": 1,
           },
           {
                  "zone": 3,
                  "WaterLength": 3,
                  "WaterCycle": 2,
           },
           {
                  "zone": 4,
                  "WaterLength": 3,
                  "WaterCycle": 2,
           },
           {
                  "zone": 5,
                  "WaterLength": 3,
                  "WaterCycle": 2,
           },
           {
                  "zone": 6,
                  "WaterLength": 3,
                  "WaterCycle": 2,
           },
           {
                  "zone": 7,
                  "WaterLength": 3,
                  "WaterCycle": 1,
           }
        ]
    }
}

Got that done, used the json parser to read that into the application.  Now we are cooking.  That sets up 8 zones to be watered 3 seconds each (that makes it easy to test) with a cycle time of 1 to 2 seconds to each zone will get run at least twice and 2 of them will run for a third time. So then I wrote the main code that will actually run the watering program and it’s working.  It’s not final, it has some bugs to be fixed but it works….

What remains to be done?

What remains before I can start testing it with some alpha/beta testers?  Some code cleanup add minor features, really it’s pretty much ready, it reads a rain sensor now (NO  or NC) it waters according to cycle, it knows time and date.

Advertisements
Comments
  1. Jim S says:

    Interesting. I am pulling together the same parts (OSPi, Pi, and LCD/button board) and trying to get my head around the software side. I see some support for the LCD in the other OSPi software and wonder if your reasons for doing your own still apply. I am looking for local control capability so users that are used to a regular controller can turn on and off zones and set run times. Also to allow a sprinkler company to do startup and shutdown (blowout the system). And also have web page control and control via the network for a home automation system running on another linux box. My plan was to stack the LCD above the Pi and use a slightly taller case so it all fits in one box. Not sure how I will handle the buttons though. I want this to look reasonably professional. I have some LCD units with larger keypads (full 0-9 and a few more) that has taller,bigger buttons so would look better and just need a bigger box.

  2. sgiab says:

    I’m essentially implementing a very similar controller. I have this microcontroller based RainBird 16-zone (using 15 zones) today and I wanted a slightly more sophisticated controller.

    RainBird doesn’t have a decent replacement, so I spent a couple minutes reverse engineering how it works and decided to make use of an idle Raspberry Pi. Two 8-port relay boards for $16 and now I just have to write some code however I want.

    I’m just writing it in Python and have the basic functionality working. I’m querying NOAA to get the weather and will use that as a decision point whether or not to water on that day. I’m thinking about just creating a Schedule class and pickle the object for persistence.

    Instead of cron starting it at a specific time, I’m thinking about adjusting for sunrise and always starting such that it finishes at sunrise. I’d just have cron kicking off my code periodically to see if it needs to execute anything scheduled.

    I might even put a 3.5″ LCD on it. It really isn’t necessary, but hey… I can do whatever I want with this thing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s