Garden Squid

The garden squid is an open platform for indoor garden automation to bring software, hardware, and garden hackers together!

Similar projects worth following
The mission of the garden squid is to be the most open and accessible automation platform for all types of gardens.

Open because all the hardware, and software designs are open. Anyone can start with this platform and add new automation, new sensors, or repurpose it entirely.

Accessible because anyone can pick up this design and run with it.

To build the hardware yourself, only basic soldering skills are required. No need to deal with AC, surface mount, or even needing a PCB. By using X10 instead of relays, any kind of fan or pump can be automated, allowing all kinds of setups.

The software is basic, but written in common languages and frameworks. The backend is python / flask. The web frontend was made with yeoman and is angular. Software is available on github and is easily hackable.

Use this project as a base for your garden, science fair project, or home automation!

The garden squid is the open platform that sits at the intersection of hardware, software, and gardening. Many people love to garden, write software, and develop hardware, and sometimes these passions overlap. By keeping the design incredibly simple, I hope to build a platform that can automate simple gardening tasks out of the box, and easily allow for augmentation for your next garden hack.

Many gardening systems are custom built to a specific growing type (like NFT) and size, including lights and how many pumps are involved. The garden squid is different in that you use your current garden equipment (pumps, lights) that plug into AC outlets, and plug them into wireless X10 modules. Any combination of devices can be attached, with custom rules and timers about when to turn them on and off. By using X10 as opposed to soldering relays, we allow for less wires, less AC risk, and more flexibility over time.

By allowing the garden to grow, we also need the ability to sense the conditions in the garden. While CO2 and humidity levels are fairly constant in well mixed air, the temperature differences in a garden can be huge between the light, canopy, and undergrowth. Using 1-wire temperature sensors over ethernet cable, we can map the microclimate and provide more efficient temperature control to maximize efficiency and yield, and prevent plant burn.

Gardening is a great hobby, but having to tend to it every day can turn it into a chore - especially when you want to go on vacation. That's why the garden squid can be accessed via a web server to provide data on the go about your garden, to let you know everything is running smoothly.

The architecture of the garden squid is simple: sense the conditions, log the conditions, respond to the conditions. I hope to keep this project simple and flexible, so that it might be a base for both future expansion and repurposing for other home automation or data logging activities. By keeping the hardware approachable and safe (no need to touch AC power), the garden squid is safe and simple enough for someone to approach as a first project. The software will be written in python, using flask and other standard technologies. The sensor loop will also be modular to allow for new sensors, or omitting sensors from the design.


Eagle schematic of the garden squid

sch - 143.52 kB - 06/30/2016 at 08:50


View all 11 components

  • 1-wire kernel module dependencies

    Christine Banek08/29/2016 at 22:21 0 comments

    Yesterday I noticed that my garden squid was having problems graphing. Looking into it, I was out of space on my device, but it wasn't my fault this time.

    /var/log/messages and kern.log were spewing out about invalid GPIO for 1-wire bus.

    Apparently if you rmmod w1-therm without w1-gpio, you can have a bad time. There's some invalid memory going on, and it spews out a callstack every second or so until it fills up the disk. For some reason, modprobe must not be seeing the dependency.

    Just be warned my friends, if you see that your 1-wire GPIO of 1247578718 is not right, it's probably your kernel. I had to reboot to get it to work again.

  • Garden Automation Rule #1

    Christine Banek08/27/2016 at 13:14 0 comments

    Well I violated garden automation rule 1. It almost bit me, but I managed to catch it in time.

    What is the prime directive for garden automation?

    Never add water to the system without you there.

    If you are adding water to a system automatically, and without you being there to supervise it, there is always a possibility that it will fail. If it does fail, you must assume that you will have water flowing to the worst possible place, because as soon as it overflows, it will find a way to get there. And if you aren't there to stop it, within hours you could have a flood on your hands.

    By not filling or topping off a system automatically, but doing it by hand, it means that under no failure will there be more water in the system than you expect. By having a certain amount of water in the system, you can at least plan for that type of capacity in terms of other failures (such as that pump running for too long). Use rubbermaid containers or drip pans to cover up to your capacity so there won't be any problems.

    Avoiding carpet is of course key, but sometimes not possible. Put down a tarp and then some panda film on top if you are worried, and always plan for the worst, and all the water ending up in your drip pan.

    And never add water automatically to the system. Never.

  • Live prototype instance

    Christine Banek08/20/2016 at 09:46 0 comments

    Just want to give all my followers a heads up that I have opened up my garden squid prototype device to the web for everyone to look at:

    There's still a lot of work to go, mostly in the automation rules UI, which I hope to work on this weekend.

    Also note that saving the config settings is disabled, but you can view the graphs and look at how my temperatures change with my A/C and how the environment changes over time.

    Some interesting features are the shark wave like shapes (that's my A/C kicking on), the high CO2 levels (cooking on my natural gas burning stove / oven), and the temperatures up during the day when it's too hot to run the A/C in Vegas.

    Let me know what you think!

  • 1-wire network reflections

    Christine Banek08/19/2016 at 02:47 0 comments

    I'd just like to document some of my journey on building and running what I thought was a simple 1-wire network. While most of the examples are very simple, and usually only 1 temperature sensor hooked up on a breadboard, this is a more real world example.

    1-wire is a great protocol because it's simple, can be run over a variety of cable, and can run for relatively long distances (10s of meters). Compared with USB (maybe 3m), i2c and TTL logic (<1m), it provides a way to build a network that can easily encompass a room or multiple rooms of a house.

    1-wire actually uses 3 wires. Power, ground, and 1 data wire. The 1-wire bus is a master/slave shared bus, in that all the devices are on the same bus, and can pull the bus low, or let it float high.

    Of course, when the 1-wire bus is pulled low, either by a device, or by the host (a raspberry pi), this doesn't happen instantaneously, but goes quickly down each wire. The effects of the raising and lowering of the bus are different depending on the size of the network (how much conductive wire has to be pulled down), as well as the size of the network (longer wires take longer to propagate signals), and the shape of the network.

    All of this can make things sound complicated, and they can be. The bible for these design considerations is here:

    Now I want to tell you about my 1-wire network, and what I've tried, and how it turned out.

    First, cabling. Initially I started trying to use normal 4 conductor telephone wire. This stuff has proven to be a PITA. The gauge of wire is small, and hard to work with, strip, solder, or splice. I eventually went to CAT5 cable, which is much easier. The twisted pairs and increased wire gauge probably help with transmission problems. One important point is to only use 1 wire for the bus, don't use any wires you don't need. Tying those together is a recipe for wave reflections.

    Junction boxes. 1-wire networks are supposed to not be in a star configuration per the document referenced above. But for short networks, it seems to be fine. I bought an RJ11 1-5 junction box, which allowed me to use RJ11 connectors and plug in individual sensors and remove them at will.

    Overall, the junction boxes work great, but remember that each RJ11 junction crosses over wires 1-4 and wires 2-3. If you put a coupler and a junction box together, the crossovers cancel each other out, which is why I have a male cable from the pi. You can easily buy these boxes for <$10 at Home Depot.

    Wiring. I picked the inside wires (2,3) to hold power and the signal, which are both 5V signals. GND is on pins 1-4. I did this because with any risk of crossover, you risk damaging or destroying the temperature sensors. If the 5V lines are crossed, you won't get connectivity, but the sensor will be fine.

    Connectors. If you are running all your wires together, and splicing them yourself, you might not need connectors. I picked RJ11 connectors, because they allow me to use phone junction boxes. RJ45 connectors would require some kind of special board.

    Interference. When you are running a 1-wire network, the biggest problems are related to interference. If your garden uses a high power lamp, try to route wires away from the ballast or the line from the ballast to the bulb. Both of these are quite noisy even on a good ballast. I've noticed that when the lights turn on, I have about 2 minutes until the network stabilizes, but it comes back on its own.

    Waterproofing. I've noticed that some of the Adafruit DS18B20 sensors are not necessarily sealed completely. Putting one into a nutrient filled resevoir tank with a underwater pump has also caused interference. Sometimes the pumps themselves are not electrically sealed either, which can give just enough to knock the sensor off the network.

    Length of wire. I've bought 100m of cable, and am using about half. I haven't noticed any problems with the length of wire of a sensor, and I could easily see it working over...

    Read more »

  • Development Environment

    Christine Banek08/10/2016 at 02:16 0 comments

    Everyone who has done software knows that in order to write great code, you need to iterate, and iterate fast. This is why having a good development environment and the right tools are key.

    For embedded projects, this gets even more tricky than most software projects, since there is usually hardware involved and required, and while the hardware might be plenty powerful for your use case, compiling, and running in debug mode sometimes make things dog slow.

    Even on the raspberry pi, which I'm very pleased with, can be incredibly slow. Yesterday I tried to do an npm install of my app, and it took many hours to complete. I haven't tried profiling it yet, but I also saw anecdotal evidence that compiling phantomjs takes over 2 days! DAYS.

    Such compile times were fine in the 1980's, but these days we need something with a little more pep.

    This is why I want the garden squid to have a great development environment. Everything is based on linux, including both the raspberry pi and my development machine. They both run ubuntu, and by putting in some mock devices, I can exercise all the functionality of the front end and the back end (other than testing the hardware).

    This has been a great boon, since running `grunt` can easily take a minute, whereas on the dev machine it takes a few seconds.

    Architecture issues with packages are a constant problem, as trying to install phantomjs via npm has taught me. Apparently there is no binary package via npm for arm. I ended up downloading a binary from the following:

    and following those instructions.

    In the end, it makes sense to simply distribute a tarball of the minified site and not do the development on the pi, but it's always good to have that option for fast fixes.

  • X10 vs Relays

    Christine Banek08/09/2016 at 05:13 0 comments

    Since the Garden Squid is an open platform and designed to be tinkered with, I'm going to document some of the major design decisions. Hopefully this will help you understand the reasoning and allow you some insight when making your own changes.


    Many of the automation projects involve relays. Relays are great. They allow you to switch a larger amount of current than you would do with a transistor, and do it at a more mechanical level. The one problem with relays is that they have a larger amount of current and voltage, which present extra design challenges from parts to PCB on up. Most devices are tested and certified by Underwriters Laboratories (UL) to be safe, especially when they plug into an AC outlet.

    Automated gardens need to switch devices on and off, and many times these devices use AC wall voltages. The wattage for each device can be fairly low, for a small underwater pump (<50W), or it could be high (1000W) in the instances of a high wattage light.

    People should not take lightly playing with AC current at any amount. When you take a large amount of devices, and wire them close together, you should be even more careful. Since water is involved in any garden, you need to be even more careful.

    So let's recap the problems with relays:

    1. Need to be aware of design constraints for AC power. This really raises the bar for who can build the project, and I would never want anyone to risk life or limb for it. Safety is key.

    2. Need to put all the relays in a centralized, protected location. Centralizing a large amount of current is inherently dangerous, and possibly tricky given house wiring with 15A breakers.


    Now let's talk about X10. X10 is basically a wireless relay in a small box. You plug it into your wall outlet, and then plug your device into it. The relay inside is controlled by signals sent over the house wiring.

    X10 modules are freely available and have been around for 20+ years. The protocol is well known and understood, and the modules can be picked up on the cheap if you're on the look out for deals.

    X10 modules are tested by UL, and I have only had one fail on me in many years of use. This was because I was likely switching a larger current than it was rated for. X10 modules are well rated for current and wattage, and are even available in 240V models for high power lighting.

    The wireless nature is great because you don't need to run extension cords from a central location, and can simply plug in the module where it makes sense.

    The CM19A is a USB wireless X10 transciever. You can plug it into your raspberry pi and with the mochad server ( you can easily shell script or automate turning on and off X10 devices.

    For makers, this is great, because it reduces the risk of fire or electric shock because there is no AC current in the project, which means even a beginner can have some fun, do something amazing, and not risk a fire from bad soldering.

  • Web server under development!

    Christine Banek07/31/2016 at 11:56 0 comments

    Just want to pass along a quick update to those who may be interested. I've been working hard on the graphing frontend and server part of the Garden Squid, and have pushed my current work up to the dev branch on github.

    There's still a lot of work to go, but every day brings me a little closer!

  • Version 0.1 released!

    Christine Banek07/09/2016 at 02:16 0 comments

    Welcome gardeners, hackers, and makers!

    I'm happy to announce that the Garden Squid is ready to be built by people following along at home.

    The EAGLE schematic files have been uploaded, and there is a link to the github repository that contains the data logging code. The BOM has been fleshed out, so you should be able to obtain all the parts and get building very easily.

    Thanks for being patient, there's a lot more to come! Tell your friends!

View all 8 project logs

  • 1
    Step 1


    First, you want to setup your raspberry pi with Raspbian. You may need to configure settings like wifi connection settings and power management settings to prevent the pi from disconnecting.

    Clone the code here:

  • 2
    Step 2

    X10 (optional):

    If you want to use X10, connect your CM19A to the USB port on the raspberry pi. Plug in the wireless controller module to your outlet.

    Download mochad and run it to start the server that sends commands to the X10 modules.

    At this point, you should be able to run something like:

    echo "rf a1 on" | nc localhost 1099

    To turn on A1. This will prove that your X10 connectivity is good.

    Configure and add your garden devices.

  • 3
    Step 3

    K30 CO2 sensor (optional):

    The CO2 sensor is very simple, and works over TTL serial. Hook up the K30 (no extra components needed), making sure to cross rx and tx wires.

    Test out your CO2 sensor by running the in the code to take a CO2 sample.

    Make sure to run raspi-config and enable the serial port.

View all 6 instructions

Enjoy this project?



Christine Banek wrote 08/10/2016 at 06:11 point

Please don't worry about being the first person to ask a question.  Ask a question! :)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates