Archive for the ‘Linux’ Category

Funny, I tend not to blog much but every once in a while I get the urge.

Not too long ago someone asked me what I really love doing. As in what would I do for free every day if I could (assuming I did not have to worry about paying the bills and such). I thought about the question for a while and looked back over my years as a developer and manager of technical types and realized that I love creating new things that are needed by someone, I also love teaching folks about technology. That explains why some jobs in my past have resonated with me more then others.

I recently took a small contract that was really fun, I got an email from a gent that wanted to send Morse Code via light. He wanted to be able to type a paragraph of text and send it over and over again via a light and not just any light, a bright enough light to cover a mile or more of distance. He had a few more requirements:

  1. It had to be self-contained, and portable
  2. Water resistant to water mist and or light rain
  3. Easy to use, he did not want to learn Morse Code, just wanted to type text and have it sent as Morse Code
  4. Able to send the text as Morse Code somewhere between 5 words per minute (WPM) and 75 WPM

As it turns out I am an amateur radio operator (HAM) here in the US and I have my general license (still studying for my extra license), so I know about Morse Code but I can’t actually send or receive it. I tried back in the 70’s to learn it but never could wrap my brain around it. Seems to fit in the same general area as speaking and understanding other human languages besides English (I can’t do that either). I’ve tried to learn Spanish, Italian, Esperanto and Klingon. I’ve never had any success, the closest I’ve come is I can count to 39 in Spanish….. and that was with 6 years of training in elementary school.


Thinking over his requirements, I realized I needed some kind of a waterproof case about briefcase size, perhaps a bit deeper then a normal briefcase to allow for a large light to be stored in the case when not in use.

Clearly needed to be some kind of embedded computer to create the text and control the light. Cheap and small, how about a Raspberry Pi (Rpi) model 3B? It’s small, easy to program, has lots of general purpose input output pins (GPIO) and has an HDMI monitor output. Perfect. Of course if you are going to have a computer you need a keyboard/mouse and a display. MonitorInLidAll simple enough. Now what kind of light will be bright enough to be seen a mile away and yet be controllable to be able to send Morse Code. Needs to be bright, really bright. Can’t use Halogen, that gets too hot and will keep glowing even when the power is removed, incandescent same problem, florescent does not turn on fast enough and keeps glowing also. LED fit the requirement – it turns on and off fast and it’s very bright. When you replace a household 100 watt light with an LED you usually replace it with an 8 watt (W) LED, so what if I use a 100W LED? I hunted around and find a 100W spotlight that is normally used on trucks that go off-roading. Now that is BRIGHT, slight problem however it uses 12VDC – 30VDC for power and requires up to 8 amps of current.  Video of a super bright LED light flashing on a blue wall.

We have a computer and monitor that use 5VDC to run, the LED light that requires somewhere between 12V and 30VDC and is high amperage at least compared to the GPIO pins of the Rpi. For easy portability powering it from 12VDC makes sense, that is easily available from a vehicle or a wall power supply. Some bigger trucks use 24VDC so keep that in mind when designed the circuit….. OK I found a DC to DC step down power supply that can handle up to 35VDC input and can output 5VDC regulated for the Rpi and Monitor. Now all I had to handle was the current for the LED spotlight. First thought is use a cheap 5VDC mechanical relay, the Rpi can control a 5DCV relay easily, except one problem. Sending text at 75WPM means that the transition speed between on and off is fast, very fast, in fact much faster then a mechanical relay can handle. So back to the drawing board…… Wait one, how about a solid state DC relay? 3 – 32VDC input for control – 5VDC input from the Rpi check that works, can switch 5 – 200VDC output – the LED light works on 12 – 30VDC, check that works too. Alright a solid state relay it is. Solid state relays can generate heat so make sure I get a heat sink made for the relay. Some miscellaneous other parts, wires, mounts, case, etc and we are off to the races:

So far we have about a $800 parts list:

  1. VideoSecu LCD LED Monitor TV Wall Mount
  2. SAE Cable – iGreely Solar Weatherproof SAE Socket Sidewall Port
  3. MUYI 2 Set Inline Fuse Holder 10 Gauge Waterproof Pigtail Blade Fuse Holder
  4. Kenowa Portable Monitor 11.6 Inch 1920X1080 IPS with 2 Mini HDMI USB(5v)
  5. Logitech K400 Plus Wireless Touch TV Keyboard with Easy Media Control and Built-in Touchpad
  6. RS Components Raspberry Pi 3 B+ Motherboard
  7. Miuzei Raspberry Pi 3 B+ Case with Fan Cooling
  8. Seahorse SE-720 Waterproof Protective Hardcase Without Foam (Black)
  9. DROK Buck Converter Voltage Regulator DC 5V Power Supply
  10. Blue Sea Systems DualBus 100A BusBar – 5 Circuit
  11. Universal Compact Bench Power Supply – 30 Amp Regulated
  12. Universal 6″ LED Spot Lights For Cars – 100W Bright 8000LM LED Off-Road Spotlight
  13. TinaWood SSR-25DD Solid State Relay 25A 3-32V DC/5-200V DC
  14. 8’ Aluminum angle
  15. A 1/8” sheet of Aluminum to bolt the computer hardware too.
  16. Misc bolts, pop-rivets and connectors.

Time to build the system into a solid system. I took the Seahorse case and built an aluminum frame that had 3 compartments, 1 for the LED light, 1 for the computer, relay and DC-DC power supply, and one for the keyboard storage. The entire frame was pop-riveted together, painted black and then the frame was riveted to the 1/8” aluminum sheet. Then nuts and bolts were used to secure it inside the case.

The LED compartment had a slot to allow the LED to be bolted down so the LED could not bounce around in the case, if that happened it would be a disaster, the light was big enough and heavy enough to break everything else in the case if it broke loose. The Monitor mount was bolted to the inside of the lid of the case and the flat panel monitor mounted to it.Computer-Power-Relay

Now wire up the Rpi, monitor, solid state relay and step down power supply. Plug in the external power and it works, it powers up and I get the Rpi logo on the monitor. Fantastic. Now we need some software.PowerSupply


I had told the gent that I was going to use Open Source software on his project, fortunately he knew what Open Source software is so I did not have to explain that to him. I installed Raspbian on the Rpi and did a search for any Open Source application that sent Morse Code, I found only a few. I downloaded the source code to all of them and had a look. My original plan was to crib as much as possible from an application and only write the controlling aspects. No luck there. The few applications I found were not suitable for the project. Most were for learning Morse Code, the best was fldigi that is a radio control application but it was far too complex for the project.

So I had to design from scratch an application that could take a paragraph of text and send it via flashing the LED light. I called the command line application “morse”, I know really original. I used the “C” language as I wanted the application to be compiled and fast. Morse code is “interesting” it’s all about timing, more about that below.

Quick Primer on Morse Code

Morse Code is all about the dot. All the timing in Morse code is based off the time of the dot. So:

  • A dot is one time unit.
  • A dash is three dot time units.
  • A dot dot or dot dash or dash dash separation is one dot time unit.
  • A letter separation is three dot time units.
  • A word separation is seven dot time units.

How fast a dot is depends on how many words per minute you are sending, and from there cascades the rest of the timing. There are two type of timing: “Standard” and “Farnsworth”, the “morse” application can do both types. For more info lookup Morse Code on a search engine.

I designed the application in several sections.

  1. First I built a header file that was a lookup table of dot and dashes for each Morse Code letter and punctuation. I ended up building the lookup table for the most of the entire ASCII table with either dots and dashes or NULL’s for things not in Morse Code.
  2. The next thing I did was write the code to display a letter from the lookup table from that I added the ability to process and display an array of text. That all ended up being in a single C file called “display_morse.c”.
  3. Now that I could display text, I needed a way to load a text file into memory so it could be displayed, that ended up being in a file called “process_file.c”.
  4. Next I needed a way to tell the application the name of the file to load, speed to display it, how many times to loop displaying it, etc. all of that ended up going into a file called “process_command_line.c”.
  5. Of course if you are taking command line input it might be handy to also have config files that set the defaults so you don’t have to use the command line options, that ended up being in a file called “process_config_file.c”.
  6. Finally all “C” applications start with a main() function that is in the file called “morse.c” and the include file called “morse.h” which contains the master structure of variables needed to control the application.

The application is under the gpl v2 license and is available on github  It does use two library’s one of the library’s is specific to the Rpi to run the GPIO pin that controls the LED light and would need to be replaced if a different embedded hardware system is used, the other library is to parse command line options and can be used no matter what hardware platform is chosen.

It was truly a fun project and met his needs. It’s used on a really large field where they fly drones and don’t allow any radio communications except the drone controllers. Turns out there are apps that will read Morse code signals sent on light by cell phones! Who would have thunk??? So you can receive Morse code via your cell phone for short range communications but for truly long range well that is where a special project like this comes in. So if you need a special device and you can’t buy it on Amazon or at Target or some other store, and you really need it, get it touch with me and likely I can create it for you.


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.


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


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.


    "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.

OK, sat down over the weekend and did a bit of pseudo code for the watering program.

Easy when you think of it:

  1. Grab command line to see what watering schedule to run
  2. Load system config so I understand my hardware
  3. Load the designated watering schedule
  4. Set up a loop to run all of the zones, if zone is not active or does not have any more water time go, loop to next zone, else:
    1. Check the global gauges to see if we can water, if not exit program with reason
    2. Check zone gauges to see if the zone can be watered, if the zone gauges say no water, zero the zone and go back to the top of the loop
    3. Determine how long to water, either to the limit of the soil or for the full zone time
    4. Start watering the zone
    5. Sleep for the determined time
    6. Stop watering the zone
    7. Go back to the top of the loop and keep doing it until all water delivered to all zones or we are bumped by gauges.
  5. Shutdown any specific hardware as necessary (make sure the water and the pump (if you have one) are off.)
  6. Exit program with status

Now there are some nuances there, logging and other bits but really that is it.  Overly simplistic and lots of detail to pay attention to but at the highest level no need to check things second by second.  And if for some reason I determine I have to check things more frequently than at each zone change I can by using threading but I don’t currently see the need for it.

So the first thing I decided to have a look at is what format are my data files?  Gave that a lot of thought, XML, YAML, JSON or some home cooked format.  After careful consideration of both the input web program and the watering program I decided on JSON for a bunch of reasons, its light weight, there are standard validation tools that can easily tell me if the file if formatted correctly, and its easy to write a json file from web software and their are a bunch of parsers under open source licenses so I don’t need to reinvent the wheel.  Finally it’s pretty easy to hand craft a json file and get it correct so I can get the watering program done and tested without the web front end.

In some ways I don’t love JSON, the pure form does not support comments in the file.  Several parsers do support C and C++ style comments but its not part of the standard as best I can tell.  Of course some people don’t believe in comments so it matters not to them but I do like them..  Oh well the rest of the file format I like well enough.

The other thing I thought about was possible devices attached to the sprinkler system to determine if I should actually water now, or things on the Internet I can reach out to, they are:

  1. Weather report
  2. Temperature gauge (don’t water if too cold)
  3. Rain moisture gauge (don’t water if raining right now)
  4. Rain metering gauge (don’t water if we got enough water in the last day, tricker as we have to have something monitor this all the time)
  5. Wind gauge (don’t water if the wind is blowing too hard, you will just water the neighbors yard)
  6. Ground moisture gauge (one for the entire yard or one per zone, if the ground has enough water now why add more?)

Additionally some things you need to know are:

  1. How many zones are active in the system
  2. Does the system use a pump to pressurize the water, if it does you need to turn it on for each zone to water
  3. Do you want info logged about how much water is put out and what was skipped (if anything because of gauges)

The metering rain gauge is bothering me, I thought I’d only need a web front end and a watering program but to track a metering gauge will require monitoring it all the time.  So I guess that will call for a daemon program that watches the gauge if you have one and accumulates water over time so you can decide if you need to water at all. Hmm, I think I leave that to last, or maybe someone else will code that since I don’t even have such a gauge, though I know they exist.

On to the next step coding the load the config.json file into memory and parse it.  Language well that will be “C” since I prefer that over Python.  IMHO Python is nice for proof of concept and quick one off scripts but I really prefer “C” for the watering program.

So, now that I have a test platform (and I still have a system in my garage that is watering the grass) its time to think seriously about the design of the software and how it will work.

The OpenSprinkler Pi has at least two open source projects one written in python and one written in C/C++.  Both of them model the OpenSprinkler Arduino software, in fact I think both can be run on both platforms.  That makes the software usable across more installations BUT at a large cost, loss of flexibility and security. The app has to run on the least powerful hardware the Arduino.  The Arduino is an  8-bit Atmel AVR microcontroller,  just bare metal is it were.  There are no OS services running on such a device. So the current app’s have to do everything on the Arduino, be a web server, serving the programming interface and have a thread that runs all the time to execute the scheduled waterings.  Simply because there is no other way for it to work on an Arduino.  Now don’t get me wrong, I like Arduino’s, and I use them for simple tasks and data gathering, they are great but they are simple devices and sometimes you need more.  Of course being an Arduino it sort of limits the damage that can be caused by crackers, you can’t reflash it remotely (at least I’m not aware of being able to reflash it remotely) so it’s going to limit what you can do with the device if you can crack it.

However the RPi is a different can of worms in this regard.  Linux on the RPi is very powerful, it is after all a fully fledged computer, not just an embedded bare metal device. Running a unified single application that has to run as root (to control the RPi GPIO pins) opens potential security holes, because on the RPi if you crack it, you can easily reprogram it to do anything you want.  Best practices on the Internet for web servers is you run them at the lowest level of authority so that in the event someone cracks the web site they can’t get control of the entire system.  Imagine if you have a single program running as root and a cracker gets control of it they could run up your water bill into thousands of dollars by turning on your sprinklers every night from midnight to 06:00 AM and turn your Internet connection into a spambot or worse.  You might not notice the damage until you get your water bill, or my my case a citation for illegal water usage!

Nope, a web server needs to have as little permissions as possible, so what can we do to address this. Well we can break the program apart, the “user interface (UI)”, “the scheduler (TS)” and a “watering program (WP)” to take the watering times and lengths and actually water the grass.

OK so the “UI” is run on a web server, check, low permissions, write data files and tell the “TS” when things need to be run.   This is not a complex program but it does require study as interfacing with humans is a skill that not all programmers have.  What makes perfect sense to a developer can be gibberish to the average human.  You need to present the information needed in a way that makes sense and builds on each step.  There could be some configuration sections that only the installer of the system needs to set, and other screens that the average homeowner needs to use to water the grass.

Next you need the “TS”, here on Linux you don’t actually have to write anything, you have cron.  Cron is a time-based job scheduler in Linux and Unix-like computer operating systems.  It can schedule jobs minute by minute, with the addition of at least one handy dandy script to enhance  cron (cron-last-sunday) you can schedule quite intricate requirements.   If you need more than that can do, you can add your own special purpose script to assist cron.

Finally the “WP here you potentially do need root access (there are ways around even needing root here but that is a topic for another blog entry).  The “WP” can only do what is in it’s data files it does not interface to the public so to speak.  The first thing the “WP” should do when it is invoked by the “TS” is quickly validate it’s data files to tell if the data files are corrupt, if they are it does nothing harmful, it simply stops.  It can however send an email to you saying “I did not water the lawn today because my data files don’t make sense.

No harm done, all that happened is the lawn did not get watered so no water wasted and all is well. If you carry a smart phone you will see that email within minutes of when the watering was supposed to start.  You can go see what the heck happened to the data files potentially fix them and still get the lawn watered in the correct time slot.  And finally the “WP” can only read and not write to the data files, so the only thing that can change the data files is the “UI”.

With the single program broken up into three (3) smaller separate bits we get higher security, something that is much easier to debug and we save time as we don’t actually need to write the “TS” program, we have it and its well tested over years of time and 10s of thousands of servers.  So 1/3 of the project is already written for you, now that is a score! ;-D

So now what, do I focus on the “UI” or the “WP”.  I’m going to focus on the “WP” because I can focus on what it is supposed to do, water the grass the way I want to water it: when (per zone), how much water (per zone), absorption rate (how much water can be applied before it runs off)(per zone).  Other things the “WP” can be aware of is a rain gauge (global), local weather reports (did it rain yesterday, is it raining now, does it have a high probability of rain tomorrow and how much is expected)(global), moisture gauges in the soil (is the soil already wet enough, or does it become wet enough while the water is being applied)(per zone or globa depends on how you install them).  Oh and lets not forget a temp gauge, because if it’s near freezing you don’t want to water then either.  And somebody I know wanted to add a wind gauge as he does not want to water if it’s too windy, as it will simply blow the water away and never get to his lawn.

As you can see the “WP” can be really simple: turn on the water per zone for x time.  Or it can be very complex: Turn on the water per zone but if the duration is longer than the absorption rate then only water as long as the ground can absorb it, cycle on to the next zone until it’s reached its absorption  limit and keep doing that until all zones are watered then loop back and put the remainder of the water in each zone, oh yea don’t do it if it’s raining now, or rained more than an inch yesterday or it’s expected at more than an 80% chance of an inch of rain tomorrow, and don’t water if its near freezing or the wind is blowing too hard. Whew, that is really really complex and yet easily within reach with an RPi as the controller, not so much with an Arduino.

Really if all you need is the simple instance, an Arduino is perfect for the job, it’s only when you get really complex do you need a bigger computer.

Once again I’ve written a really long blog entry when I meant to write a short entry, oh well, I’m done for now.  So a question, Ideas anyone, what features do you want in your sprinkler controller?

So carrying on with my sprinkler controller project I need an easy way to run things on the 1st Monday of a month and the 3rd Monday and only then.  Hmmm, I can do that with cron by looking up the dates and entering each day but that is a manual process to look that up and then enter 24 entries in the crontab…. Must be a better way so I go surfing the Internet and what do I find but a nice bash script called run-if-today.  You feed it the day of the week and what week of the month you want the entry to run. Perfect  makes the crontab 2 lines vs 24 lines!

# m h dom mon dow command
00 06 02 06 * sudo /home/pi/bin/
00 06 16 06 * sudo /home/pi/bin/
00 06 07 07 * sudo /home/pi/bin/
00 06 21 07 * sudo /home/pi/bin/
# etc, on and on until the end of the year


# First monday of month jobs
00 06 * * 1 run-if-today 1 Mon && sudo /home/pi/bin/
# Third monday jobs
00 06 * * 1 run-if-today 3 Mon && sudo /home/pi/bin/

Much better, it will run forever on the first and third Monday. Yea.

So credit where credit is due: I found this on github cron-last-sunday it’s under an MIT license and Copyright (c) 2014 Manuel Gutierrez.  Nice work.  I had a friend Debianize the script into a nice easily installable Debian package, which I need to figure out where to stash it so others can install it on their RPi, because it really simplifies using cron for certain conditions.


A New Project

Posted: June 2, 2014 in Debian, General, Hacking, Hardware, Raspberry PI, RPi, Software
Tags: ,

A New Project – Water Sprinkler Controller

I find myself starting a new project not necessarily because I want to but because of our local three year drought and the need to water my lawn under Stage 3 watering restrictions. Unfortunately, my sprinkler controller finally gave up the ghost. Sounds simple doesn’t it? Simply order a new controller off of ebay, amazon or head down to the local big box hardware store Lowes or Home Depot and buy a replacement. After all there are at least 5 or 6 different units that one can buy for under $100 USD.

Ah, well that is where the drought comes in, and the Stage 3 Watering Restrictions. You see, because of the drought we are only allowed to water every other week on a specific day; on top of that we are not allowed to have any run off into the street. This presents several problems to an off the shelf sprinkler controller: 1) Everyone I’ve found for under $300 works on a weekly pattern, and does not have a specific calendar day or the ability to water every other Monday at 06:00 and be done by 10:00 and if not done kill the water anyway as it’s a $200 fine the first time you water past 10:00 AM and $1000 the second time, progressively getting more expensive; 2) Our soil is mostly clay and water soaks in slowly. So you really need to water in short cycles, wet the ground and then move on to the next zone and keep doing it until you have gotten enough water into the ground without run off. Now some of the $300 units can do this but still don’t have the monthly scheduling ability.

So I’m stuck, either I fix this with a new unit that does not really do what I need thereby forcing me to go into my garage every time I have to water and set off a manual cycle, which seems a bit ridiculous. If I’m going to spend the cash to get a new system I want it to be automatic, not be stuck in the same manual cycle I’ve been in for more then a year as there is no end in sight in terms of the drought1. My other choice is to do the entire thing manually with jumper wires and stand in my garage for 2 hours manually activating each zone by hand and then switching to the next zone as needed, yea, like I have so much spare time in my life that I’m going to do that every two weeks!!!!

1And as it turns out my grass is nicely green even with the watering every 2 weeks so even of the drought breaks I’m unlikely to go back to the weekly watering schedule, I mean why waste water and money (I have to pay for city water to water the grass).

What Features do I want/need

So seems like the only think I can do at this point is to hack something together and make my own sprinkler controller from scratch. 🙂 So what do I want in a sprinkler controller1:

1Your list might vary from mine but this will be an open source project and as such feel free once the code is “over the wall” to add other features or accelerate some.

  1. Friendly user interface, web based so you don’t need to stand in the garage in 110f weather programming the stupid thing system.
  2. Can set any interval, daily, every 2nd day, every 3rd day, every 4th day, every 5th day, every 6th day, every 7th day, weekly, monthly, semi-monthly, annually, or a list of calendar days.
    1. Can set start time and hard end (stop) time
      1. If hard stop time is set system will not allow water to flow after that time.
      2. If hard stop time is set, when programming a “???? set” if you ask for more water then the start time and end time would allow the system will warn you and suggest a new start time that will allow all water to be sent and stop watering by the hard end time.
  3. Real Time Clock so it knows what today is.
  4. Zones can be scheduled independently from each other. So I could set zone 1 – 9 to water every other week according to the local rules, but zone 10 (which is a soaker hose on my foundation) can be run every other day as needed to keep the clay moist near my foundation. 1
  5. Each zone can be set for total length of watering, independent of other zones.
  6. Duration of water applied to a zone. If the duration is shorter then the length of time set for the zone the zone will be watered for the duration and the system will keep coming back to the zone until all water has been delivered. This will keep run off from happing with our clay soil.
  7. Might be nice if durations can be set by zone but this would be an enhancement.
  8. Use any standard off the shelf parts for a sprinkler system available at your local hardware store. No requirement for expensive special water control valves or other specialty hardware. Everything low voltage (most sprinkler systems today use 24VAC as their control voltage on zone valves), no 120/220 in the sprinkler control box.
  9. The ability to easily skip a zone on a once time basis in case you discover a sprinkler head is broken but you want to water the rest of the zones.
  10. Connected to my house network so I don’t have to go digging into my garage to know what is going on. Additionally would be nice to be able to do testing of the system remotely when I’m watering in the yard looking at a zone to make sure it’s working correctly. While not hard it’s a pain to have to go back into the garage to trigger each zone and then walk back to the zone to see what works and is broken several times as I fix issues.2
    1. Expand this to remote control from anywhere in the world via the Internet. Clearly need SSH/SSL/VPN security setup so that bad things can’t happen easily.
  11. Expandable, I have nine (9) zones and I can see adding a tenth (10th) zone soon (soaker hose).
  12. Rain Sensor, including volume of rain fall, so if it rains hard enough 24-48 hours before watering time, cancel the scheduled watering.
  13. Ground moisture sensors, multiple zones so you can if desired analyze by zone the need for water.. Would allow skipping areas if they already are moist enough and don’t need to be watered.
  14. Integration to Internet weather sources so you can see if it rained yesterday or is about to rain tomorrow.
  15. Display on the front panel of what the system is doing now or about to do. Time and date displayed when doing nothing else.
  16. Permanent memory so watering instructions are not lost on power fail.
    1. Not require battery backup, I really dislike 9VDC battery backup systems, the battery always dies at the wrong time.
  17. System resume after power loss, including resuming watering if system was running when power failed.
  18. Record what was done over time in a log. What zones were watered, how long, or what zones were skipped and why (raining, rain predicted, soil already moist, etc.)
  19. Run the entire system on a single wall plug. Use a 24VAC wall wart transformer and make any other voltages needed internally to the system. You should not need more then a single source of power.
  20. External temperature sensor, so if its near or below freezing we don’t water.
  21. An emergency off button, so if you see an issue, like for example a broken sprinkler head that is pouring water into the street you can stop it NOW.
  22. This would include the ability to restart to continue watering if the problem is resolved or you tell the system to skip a zone one time and do the rest.



1Without watering on a regular basis the foundation can crack and that is a big $$$$$ repair. Because of this local law allows watering your foundation as needed vs every two weeks. Crazy isn’t it? Water your house?????

2Yes in ground sprinklers need regular service, lawn mowers shave off heads, heads stick with dirt, tops just break off from age. Lots goes wrong, and run off = $$$ in fines.

Next Steps

Turns out I had a bigger list then I understood when I started. Too big to get done in a single pass. So I’m going to break it up into chunks. This was how I wanted to proceed but as usual your plans go out the window when they intersect reality.

  1. Get the hardware.
    1. Assemble all hardware including the parts we are not going to use right now like:
    2. Raspberry Pi Computer (RPi)
    3. 2 banks of 5VDC relays
    4. 2×18 LCD display
    5. AtoD converter to input moisture sensors and rain sensor.
    6. 40V DC DctoDC converter
    7. Full Wave Bridge Rectifier
    8. 1000uf 50VDC Electrolytic Cap
  2. Installed on the garage wall where the existing controller is.
  3. Modify the init scripts to read the RTC and set the date even if the unit can’t see the Internet for any reason.
  4. Basic cron job that will water the lawn on the specific days allowed:
    1. cron tab of:

00 06 05 06 * sudo /bin/bash /home/pi/bin/
00 06 05 21 * sudo /bin/bash /home/pi/bin/

You see I ordered a bunch of the hardware and it won’t come in until the day after I need to water the grass for the next cycle 😦 So I’m going to have to take just the Raspberry Pi and Relay board and put them in temporally so the grass can get watered. So the actual order will look more like this:

  1. Get some hardware
    1. Raspberry Pi Computer (RPi)
    2. 1 banks of 5VDC relays
    3. Some jumper wires
    4. 40V DC DctoDC converter
    5. Full Wave Bridge Rectifier
    6. 1000uf 50VDC Electrolytic Cap
  2. Disassemble the old control system and leave parts of it in the box on the wall and keep the 24VAC transformer.
  3. Solder the full wave bridge rectifier and cap directly to the DCtoDC converter
  4. Use a chunk of cardboard to zip tie the RPi, relay board, and the new little 5VDC power supply to it.
  5. Using jumper wires connect up everything. Power the RPi via the GPIO pins and not the micro USB connector

Examine the existing connections and wires

Old Sprinkler Controller Connection Board

The old system was made by Irritrol an RD-900 unit, which consists of a control unit and a separate connection board. I don’t care about the control unit as its dead and I”m building a new one BUT I do care about the old connection board and the wires that control the sprinklers that come out of the ground. So time to document them. It’s pretty clear from a closer inspection of the board that the RD-900 is a pretty simple system there are lots of areas not populated on the board. But it’s pretty clear I can use the ribbon cable that came out of the old control unit and attach to this connection board and save some time and cost.

Connection on Old Wall Board Barrier Terminal
1 24 VAC after going through a 2A SLO-BLO Fuse
3 #9 Zone
4 #12 Zone
5 #5 & #7 Bridged to AC Common
6 #11 Zone
7 #5 & #7 Bridged to AC Common
8 #10 Zone
9 #3 Zone
10 #1 Zone
11 #4 Zone
12 #2 Zone
13 #6 Zone
14 #5 Zone
15 #8 Zone
16 #7 Zone

All connections on the Barrier Strip have an MOV for protection but it was never hooked up by the original contractor. Another example of the shoddy work that gets done on these development homes.

Old Sprinkler Controller Connection Board

Old Sprinkler Controller Connection Board

The Barrier Terminal Strip has all of the zone wires connected to it and the 24VAC power. It also has a slo-blo fuse which is quite handy since I’m bypassing the fuse on the RPi by supplying power on the GPIO pins directly.

Barrier Terminal
Strip Label
Wire Color
1 Black (Solid Wire)
2 Blue (Solid Wire)
3 Red (Solid Wire)
4 Green (Solid Wire)
5 Yellow (Solid Wire)
6 Orange (Solid Wire)
7 Brown (Solid Wire)
8 Grey (Solid Wire)
VC White (Solid Wire)
24 Black (Stranded Wire from 24VAC
VAC Black (Stranded Wire from 24VAC

OK ignoring the shoddy workmanship issues I can make use of this board. I’ll be using the following pins listed in the table below, I’m going to skip the 9th zone as I don’t need to water it right now.

Pins Description Connection Point
1 24 VAC after going through a 2A SLO-BLO Fuse DC2DC Converter Full Wave Bridge input
5 #5 & #7 Bridged to AC Common DC2DC Converter Full Wave Bridge input
7 #5 & #7 Bridged to AC Common Bridge to all relays NO Connection
9 #3 Zone Relay 3 Center contact
10 #1 Zone Relay 1 Center contact
11 #4 Zone Relay 1 Center contact
12 #2 Zone Relay 2 Center contact
13 #6 Zone Relay 6 Center contact
14 #5 Zone Relay 5 Center contact
15 #8 Zone Relay 8 Center contact
16 #7 Zone Relay 7 Center contact

Easy to wire up, and test. All good.

First Install and Test

Interesting morning, put the old sprinkler connection board back in the box, hooked up all the wires in the correct spots. Then mounted the RPi/Relay temporary cardboard mount into the lid of the old system, then used jumper cables to connect the 5VDC power supply and the relay board to the connection board.

RPi, Relay, Full wave bridge rectifier, filter cap and DC to DC power Supply

RPi, Relay, Full wave bridge rectifier, filter cap and DC to DC power Supply

Old Connection board jumped to RPi and Relay's

Old Connection board jumped to RPi and Relay’s

Jumped onto my network and checked yep, the RPi is on right where it should be. Sure enough the system set it’s time from the Internet, and SSH is working. Sweet. Ran a test program of 30 seconds per zone to see what happens, YEA success, or sort of, anyway, zones 1,2,4-8 all work as expected. Zone 3 dead, no joy, ugh, what did I do wrong?

So got out a jumper wire and shorted out zone 1 to AC common, on it comes, did the same with all the zones (this bypasses my RPi/Relay setup completely), again all zones except zone 3 work, zone 3 still dead. Looks like the zone valve in the ground is dead. Not really a surprise, this will be the second valve in the last year that has died1, and at least it failed in a better way then the first valve, which failed on, this one failed off, who knows how long it’s been dead, could be just short of a year when I last fixed zone valves. Of course we would have not noticed it, its not like I stand outside and watch my sprinklers go on and off. The only reason I did today was to test my new contraption. Since I now have full SSH access to the RPi I don’t have to go into the garage to manage the grass watering. SCORE 🙂

So I call this a total success, my controller is working, I have a crontab that will water the lawn in June without any attention, so I can now get the rest of the parts in and work on software. And better yet my wife is happy that I completed stage one of the build. Of course I still have to complete the rest of the stages but at this point the grass is getting watered on schedule so its a win.

Now I have to design the web pages to program the system, right now it’s hard coded and that won’t do, I want my wife to be able to change this from anywhere in the world without having to resort to C or Python programming. More about that another day.

1No real surprise, the zone valves are more then 12 years old and have been covered over in clay and dirt and water over that entire time. More shoddy workmanship, no dirt blocking fabric, no gravel under the zone valves just stick them in the ground, put a too small box over them and let it rip. No one is going to notice until years later.