Feed on

Hey, it’s March already, that means spring will be here soon! Amid an unusually cold winter and freezing weather this winter in New England, we’re finally starting to see some warm winter days. No more snow please, we’ve had enough :)

Ars Technica
This post is to give you some recent updates on OpenSprinkler and upcoming plans. First of all, OpenSprinkler Pi got blogged by Ars Technica, which is super cool. It’s really a fun article to read. That caused a huge spike of orders, but we managed. I only wish that Cyrus Farivar, the author, had talked about the microcontorller-based OpenSprinkler as well, because appearance-wise it looks more elegant.

Unified Firmware 2.1.3

Next, we just released the first version of the Unified OpenSprinkler Firmware, numbered 2.1.3. The biggest benefit of this firmware is that it’s cross-platform — it can compile and run on all OpenSprinkler hardware platforms, including the standard OpenSprinkler (OS), OpenSprinkler Pi (OSPi), and OpenSprinkler Beagle (OSBo). The cross-platform idea was inspired by Rich Zimmerman’s sprinklers_pi program. The purpose is to make a fully consistent firmware for OS, OSPi and OSBo, so that the same firmware and same features are available on all of them.

Technically, the unified firmware is written in C++. It’s done this way to share the code between OS, OSPi and OSBo as much as possible. The major differences are that on OS, all non-volatile memory data (such as options, program settings) are stored in EEPROM, while for OSPi/OSBO, these are stored in a local file, which simulates EEPROM. Also, OSPi/OSBo uses the standard socket to handle Ethernet communication, while OS uses an Arduino EtherCard library. Other than these, the code is largely shared between them, making it easy to extend in the future. Folks may find C++ based programs less friendly to modify than Dan’s Python-based interval_program. However, as I said, the point is to make the three platforms maximally compatible, so that any new features introduced in OS will be simultaneously available to OSPi and OSBo.

The main added new feature of this firmware is the support of using sunrise/sunset times in program settings. Specifically, the program’s first start time (and any of the additional start times) can be defined using sunrise/sunset time +/- an offset (in steps of minutes) up to 4 hours. The program preview will also take into account the sunrise/sunset time of a specific day. Another change is the support for MD5 hashed password, which attempts to address the previous plain-text password to some extent. For the security-minded, I admit that this is far from sufficient, but better than before.

For OSPi/OSBo, all features currently implemented on the OS, such as individual station water time, Zimmerman’s weather-based water adjustment, and support for radio frequency stations, are also immediately available for OSPi/OSBo.

Details on this firmware and how to upgrade OS/OSPi/OSBo to use this firmware can be found in this forum post.

Upcoming Plans
There are quite a few things on our todo list. The top items include:

  • Getting OpenSprinkler certified by the EPA WaterSense program (which requires ET-based water time calculation).
  • Support for soil moisture sensor and flow sense (at least flow estimation).
  • Improve the scheduling algorithm to better handle overlapping schedules using a queue.
  • Adding firmware support for using sensors (either digital or analog) to trigger sprinkler events.
  • Adding cloud-support (long term goal).

Some of these are purely software, but some will entail hardware changes. For example, for cloud-support, we’ve come to the conclusion that it will require an upgraded microcontroller due to the resource limitations of the current hardware. So the cloud support will likely not happen until OpenSprinkler 3.0 comes into place. It seems that adopting ATmega1284 is the most straightforward solution — it’s totally pin compatible with the current ATmega644, but doubles the flash memory space and quadruples RAM size. If you have suggestions about desired hardware changes, please feel free to let me know. This is the time that your opinions will be factored into the future of OpenSprinkler :)

Besides the additional new features, we are also planning to remove some features which are rarely used. One immediate plan is to remove the built-in relay, which seems not very useful, only to add manufacturing cost. The original idea of including a built-in relay is to use it for general-purpose switching, such as garage doors, landscape lighting etc. However, there is no cutout dedicated to the relay wires, so it requires some modification to the enclosure. Also, now that we have support for Radio Frequency (RF) stations, the need for build-in relay is even lower. Alternatively, you can use an external 24V AC relay, which I blogged about previously. At any rate, it seems wise to retire the built-in relay.

Retiring OpenSprinkler DIY and OSPi Standard Version
To prioritize our business, we have decided to permanently discontinue OpenSprinkler DIY kit and OSPi Standard version. We will no longer stock these kits. I know that OpenSprinkler DIY kit has been a fun product for many makers and Arduino lovers. But the maintenance cost is also pretty high — even though we do not officially provide technical support for DIY kits, in practice we still help users a lot in fixing their soldering mistakes and diagnosing issues. This has taken too much overhead, and because of this reason, we will retire the DIY kit.

As for the OSPi Standard version — it will also be retired soon in favor of the Plus version. Most of Raspberry Pi’s new products, including A+/B+/2 use the same form factor, which is not compatible with the original A/B. The standard version is still compatible if you own a RPi 1 model A/B. But we are looking into the future, and expect the orders of the standard version to drop significantly in the upcoming season.

DC Powered OpenSprinkler
I’ve received several requests to make an OpenSprinkler variant for DC solenoids. Within the US, most sprinkler solenoids are still AC powered. But for International users, it can be painful and confusing to find a AC power source, especially since AC adapters are not regulated (i.e. you can’t plug in a 110VAC adapter to 220VAC socket). In contrast, DC adapters and solenoids are sometimes more common and cheaper to source, and DC adapters are usually regulated and universal.

In a previous blog post, entitled Understand 24V AC Sprinkler Solenoids, I analyzed the electric specs of a typical sprinkler solenoid. One interesting discovery there is that it’s totally possible to drive a 24V AC sprinkler solenoid using DC voltage. The trick is that it needs a high momentary voltage to activate, but once activated, it can remain open with a relatively low voltage (some where around 6~8 VDC). This means a DC powered OpenSprinkler not only works for DC solenoids, but can work for a typical 24V AC solenoid as well. In fact, combining this with the H-bridges that OpenSprinkler Bee uses, it’s even possible to use the same hardware to drive DC Latching solenoids as well! Perhaps I can call this the Unified OpenSprinkler Hardware design :)

Inspired by this idea, I am actually working on a DC version of OpenSprinkler. Besides the benefits to International users, another benefit of a DC design is that this makes it easy to add a current sensing circuit to monitor each station, and detect potential solenoid shorting / damage etc.

Around Thanksgiving last year, I received a request from a biology lab professor who commissioned me to modify OpenSprinkler to become a custom fluidics controller. The goal is to achieve web-based, programmable control of fluid selector valves, linear actuators, relays, and air valve, to automate a custom biology experiment. I don’t typically accept contract work, but felt this was a very interesting project, as I’m always keen to see wider applications of OpenSprinkler. Also, this particular project fits well with the existing software design of OpenSprinkler, since the control schedules are somewhat similar to typical sprinkler programs.

It took me a while to understand the design requirement and how various components worked. The main component is the fluid selector valve, which selects a specific type of fluid from several input fluid streams. The valve has a number of control wires which are normally pulled high. To set a specific position, you basically use open-collectors (one for each wire) to pull a subset of the wires to ground. This is pretty easy to achieve using OpenSprinkler — there are 8 stations on the main controller, each station is a open-collector that controls on wire. By activating a subset of stations, it sets the selector valve to a specific position.


The project also calls for two solid state relays (SSRs) to control 110V pumps. The SSR works with logic level signals, so I used two digital pins to interface with them. Next, there are two 12V linear actuators, and a 12V air valve. Because we don’t want to involve too many different power supplies, we decided to go with a single 12V power supply, which powers the OpenSprinkler, linear actuators and the air valve. OpenSprinkler already has a switching regulator inside that can work with 12V, so that’s not a problem. I then used the built-in relay on OpenSprinkler to switch the air valve. To control the linear actuators, I needed two high-power H-bridges. The way linear actuators work is that they each have two wires — apply positive 12V on the two wires, the actuator will start to extend; reverse the polarity, the actuator will retract. This is similar to how a motor works, and it’s typically done through an H-bridge. Because the linear actuator can draw up to several amps of current, I decided to use a 4-channel relay board (instead of MOSFETs) to implement two H-bridges. So four additional digital pins are used to toggle the 4 relays.


The right image above shows a CO2 sensor. It is used to conditionally open the air valve at the end of the experiment. The idea is that the air valve will only need to be open if the CO2 level is above a certain threshold. I didn’t have chemicals to generate CO2, but had plenty of soda at home, so it was quite easy to create varkous CO2 levels to help test the sensor :)

Then as soon as I started working on the software, I realized that the control schedules are actually not entirely the same as sprinkler programs. Specifically, each schedule contains multiple entries, where each entry indicates the status of every component and the time the status will last. It’s kind of like: upon starting the program, the components should be in status A, B, C; after 15 minutes, they will change to status D, E, F; and so on. So I decided to overhaul the existing OpenSprinkler firmware, and rewrite it with a new program data structure. The end result is that each program contains multiple entries. For each entry, you specify the status (such as on/off) of every component, and the duration (i.e. how long the status lasts). In a sense this can also be used to schedule sprinkler programs, and it’s actually very powerful, because it allows you to set almost arbitrary schedules, including scheduling multiple stations to open at the same time, and scheduling the same station to water multiple times within a program. So maybe once day I will make it an alternative OpenSprinkler firmware.

Anyways, it was a really fun project. I didn’t have very good documentations about the work, but I did shoot a couple of video clips. Check them out below.

The initial demo video:

The final demo video with web interface:

Back in early December last year, we introduced a new feature in OpenSprinkler Firmware 2.1.1 that allows OpenSprinkler to directly talk to remote power sockets. With this feature, you can use OpenSprinkler to not only switch sprinkler valves, but also switch powerline devices such as light, pump, heater, fan. While it’s a powerful feature, it is after all a wireless solution so it’s not the most reliable — sending wireless signals to remote power sockets is prone to interference and is limited by distance and barriers (e.g. walls, floors) in between.

If you still prefer using relays, whether because it’s more reliable, or because it’s the classic way, there are plenty of choices. I’ve often received questions about how to use OpenSprinkler with a relay. The easiest solution is to get a 24V AC relay. Then you can wire it up as if it’s a sprinkler valve — when OpenSprinkler turns on the corresponding station, the relay is activated, and that turns on the device connected to the relay. Because AC relays are not as common as DC relays, they tend to be more expensive. Here I list three choices I’ve found:

1. Omron G7L-2A-TUB-J-CB-AC24: this is available on Amazon. This is actually commonly used in sprinkler pump start relays — if you have a pump start relay, you can open it up and check if it has a 24V AC relay in side. This particular one has a contact rating of 25A @ 220VAC, which is sufficient for most applications. You can also find similar ones with different specifications: if you search for ‘Omron G7L-‘ you will find many choices, look for the ones ending with AC24, which are the 24V AC versions.


I am quite curious how such 24V AC relays work. It probably is constructed somewhat differently from a DC relay. So I ventured to open it up. As you can see in the picture on the right above, it has a big coil, a contact piece connected via a spring. When voltage is applied on the coil, the contact piece gets attracted and therefore connecting two contact pins together. That’s how a basic relay works.

Something strange I noticed is that when I try to measure the resistance on the coil, it gives me a very large value — several mega-ohms. The coil resistance can’t be that large. There is probably additional circuitry inside the relay. I then measured the forward voltage drop on the coil, at either polarity it gives about 1.25V drop, which strongly indicates there is a bridge (i.e. full-wave) rectifier inside. This makes sense, because a bridge rectifier is a standard way to convert AC to DC. So the additional ‘construction’ inside the AC relay (compared to DC) is probably the rectifier.

To verify it, I had to open it up even further, which involves cutting some pieces of the plastic. Eventually I was able to open it up completely. Check the bottom section of the relay:


Yup, there is a bridge rectifier and a MOV. Previously I was measuring the resistance through the bridge rectifier, which explained why the value I got was incorrect. Now I can measure the real resistance of the coil, which turns out to be about 294 ohm. That’s about right — under 24V AC, it will draw an average of about 80 mA AC current, which matches the specification.

So in case you are looking for a 24V AC relay to work with OpenSprinkler in order to switch high-voltage devices, this is an inexpensive (<$10) choice and is easy to find.

2. Schrack RT314524: This is a very small 24V AC relay that you can buy from Mouser or Digikey. It has a contact rating of 16A @ 250VAC, which is also plenty for common applications.


3. Other choices: There are some other choices which were brought up on the forum, including a open-style panel mount 24V AC relay, and even solid-state relays (SSRs).

In any case, if you are looking for a relay to work with OpenSprinkler, the above are the ones worth considering.

While playing with my ESPToy today, I discovered a rather bizarre issue. The symptom is that some ESP8266 (the ESP-01 version) modules became very hot to touch. In fact, a couple of them started smoking, and the red indicator LED started burning away! Shocking. What’s even more shocking is that these modules continue to function, as if the chip isn’t bothered by the magic smoke at all…

Not all of them have this mysterious problem. So what the heck is going on here? After some digging, I found that on the problematic ones, the tiny resistor next to the red power LED measures only 4.7 ohm?! This can’t be right. This resistor is a clearly a current limiting resistor for the LED — the LED and the resistor are connected in series between VCC and GND. A 4.7 ohm resistor means the current flowing through the LED would be somewhere around (3.3V – 2.1V) / 4.7 ohm = 255 mA! (2.1V is the typical forward drop voltage of red LED). No wonder why the LED (or resistor, or both) is smoking! Phew, that really scared me. To double check, I also measured this resistor on the good ones — they all measure 4.7 kilo-ohm. That’s about right. So clearly the manufacturer has made a mistake and this is really unfortunate. I’ve shot a video of the smoking ESP8266. See below.


Anyway, because some of these defective modules are shipped with the ESPToy, if you’ve bought ESPToy the past few days, you may end up getting some of these units. I sincerely apologize for this. It’s not anything I’ve anticipated. There are several options to solve the issue:

  • Option 1: let it burn (~~~). Once the LED is burned out and the magic smoke is gone, it will become open circuit and the problem is gone!
  • Option 2: if it’s scary to look at the magic smoke, or if the LED refuses to burn out, you can use a hot air gun or a soldering iron to remove either the red LED or the resistor next to it, or both.
  • Option 3: if neither option is ideal, send an email to support@rayshobby.net and we can arrange to send you replacements.

Well, this is just one of those headaches to deal with when buying goods from China. To be fair, we buy only from reputable sellers, even so, issues can happen, but we do gain more experience each time a lesson is learned :)

When I first had the idea to design OpenSprinkler Pi (OSPi), a secret motivation was that one day I figured out how to fit Raspberry Pi into the existing OpenSprinkler enclosure. Yes, it sounds silly, and you can laugh at it; but if you understand how much it costs to make an injection molded enclosure, and how difficult it is to predict the market and demand, you will see why I wasn’t quite ready to invest on a whole new enclosure for OSPi.

The experience last year has proven that OSPi is quite popular. I really enjoyed seeing the amount of community development on it, primarily due to the low cost of RPi and the flexibility in programming the RPi. We’ve also seen continued evolution of RPi, from the early A and B models to B+ and more recently A+. On the plus side, it’s exciting to see that RPi continues to become smaller and cheaper. The A+ version is now 25% smaller and you can get one for just $20. On the other hand, I am sure the different versions created some challenges in re-designing products powered by RPi. Because each version has different peripheral elements, size, screw hole locations, it’s quite difficult to design one board that fits all versions.

So in a way, I felt lucky that I wasn’t too hasty to invest on a dedicated enclosure for OSPi, because whatever I would have designed would probably not fit A+ in the end. But the lack of a dedicated enclosure has always been the major confusion about OSPi: from time to time I receive questions about why the cutouts on the enclosure do not match RPi, and then I have to explain. It’s not ideal.

Here comes the good news: with RPi A+, it looks like I may be able to ‘close the gap’ finally — that the injection-molded OpenSprinkler enclosure will finally fit OSPi, without confusing mis-alignment of the cutouts, and with buttons and LCD, just like the microcontroller-based OpenSprinkler!

Here are some pictures to show you the proof-of-concept:

Mounting RPi. The most dramatic change is that RPi A+ will be mounted at the back of the OSPi circuit board. This is necessary to make space for the LCD (explained below). This may look surprising, but because A+ is quite flat, there is sufficient space at the back of OSPI to fit it, except HDMI, USB, and other peripheral connectors, which I’ve made cutouts for.

There is no secret that I’ve always enjoyed solving the ‘how to fit RPi into the OpenSprinkler case’ problem. It’s like a geometry puzzle for me. Often constraints push me to think of new solutions. So bear with the nerdy side of me :)

LCD. Next, for the LCD I am using I2C LCD – it’s the standard 1602 LCD with a I2C module at the back. This turns out to be very important, because I2C LCD needs only 4 pins in total (VCC, GND, SDA, SCL), significantly reducing the pin requirement and saving space. You can buy these with pre-soldered I2C modules, at very small added cost.

Buttons. There is also space to fit 3 push-buttons on the right-hand side of the circuit board. The physical buttons can be quite useful for triggering events or performing manual sprinkler control.

Ethernet. Lastly, I don’t want to waste the cutout for Ethernet jack, so I even added a ENC28J60 Ethernet controller. This is a useful add-on for RPi A+, which doesn’t come with an Ethernet jack itself. It took me quite while to figure out how to re-compile the RPi kernel to support this Ethernet controller. Don’t expect it to be very fast, but it comes handy if you really need wired Ethernet connection. Most people will still prefer the WiFi dongle.


One of the biggest drawback of this design is that RPi A+ will now be permanently soldered onto OSPi, because there is simply no space in height to put pin headers. This is not ideal but I can’t think of a better choice. The other potential issue is the heat dissipation of RPi — although there is some space between RPi, OSPi, and the enclosure bottom, it can become an issue during hot summer days. There is some space on the board to make vent holes, so I will see what I can do.

To summarize, this is a proof-of-concept design for OSPi A+ — it will finally make the injection-molded enclosure work perfectly for OSPi. Because this is a very early prototype, don’t expect it to be available anytime soon, although I do hope to make it ready by summer time this year.

Feedback, comments, and suggestions are welcome. Thanks!

Older Posts »