Project Logs

Collapse

• 1-wire kernel module dependencies

  Christine Banek • 08/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 Banek • 08/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 Banek • 08/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:

  http://home.timeslicelabs.com:4000/
  

  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 Banek • 08/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: https://www.maximintegrated.com/en/app-notes/index.mvp/id/148

  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 Banek • 08/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:

  https://github.com/aeberhardo/phantomjs-linux-armv6l

  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 Banek • 08/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.

  Relays

  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.

  X10

  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 (https://sourceforge.net/projects/mochad/) 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 Banek • 07/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 Banek • 07/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