OpenSprinkler Recent News and Updates (Feb 2015)

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.

Work in Progress: OpenSprinkler Pi (OSPi) A+ will Finally Close the Gap

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!

OpenSprinkler Firmware 2.1.1 New Feature: Control Remote Power Sockets

In the past I’ve written several blog posts about how to use Arduino to interface with remote power sockets. For home automation involving powerline devices (e.g. lights, heaters, pumps, fans), this is my favorite solution, because it’s low-cost (remote power sockets are widely available at cheap price) and convenient (no messing around with relays and powerline wires). Also, one Arduino plus transmitter can simultaneously talk to many power sockets, making this a scalable solution too.

With the just released OpenSprinkler firmware 2.1.1, support for interfacing with remote power sockets has finally arrived. So you can now use OpenSprinkler not only to control sprinkler valves, but also powerline devices. Trying to find a programmable way to control your Christmas lights? Look no further! With OpenSprinkler’s easy-to-use web interface and flexible programming capability, you can enable automated control of lights, heaters, pumps, fans — anything that can be plugged into wall outlets.

Here is a quick video tour on how to get started:

Below are detailed instructions.

Required Parts:

How does this work?
Let me briefly explain how the whole thing works. First, common remote power sockets operate in the 433MHz radio frequency band. When you press a button on the remote, it sends out a signal to the power socket, which gets decoded and acted upon. If we can sniff the signal, we can use a microcontroller plus a 433MHz transmitter to replicate the signal, thus be able to directly control the power socket in software. The RFToy is a gadget that I’ve designed to easily decode signals from common remote power sockets. Once we have the code, we can use OpenSprinkler to simulate the code, thus be able to control remote devices.

Heads-up: the following steps require a small amount of soldering. The estimate time for modification is 15 to 20 minutes.

Step 1: Decode Remote Power Sockets
Take out the RFToy, plug in a 433MHz receiver (making sure the VCC and GND pins on the receiver match the +5V and GND pins on the RFToy). Follow the on-screen instructions to record the on/off signal of a power socket. Once decoded, the signal will be converted to a 16-character hexademical code.

To test if the code works, take out the 433MHz transmitter, and solder a 17cm (6.7inch) long wire antenna to the ANT pin. Then plug it into the RFToy (making sure the DATA and GND pins on the transmitter match the DATA and GND pins on the RFToy). Bend the pins as necessary. Now click button S3 or S1 on the RFToy, the power socket should be toggle on or off just like when you press the buttons on the remote. Keep in mind that although most remote power sockets work in the 433MHz band, there are some that work in the 315MHz band. In that case, just use a 315MHz transmitter-receiver pair.

Step 2: Install RF Transmitter to OpenSprinkler
Remove the OpenSprinkler enclosure, and locate the RF transmitter pinouts (marked A3 VIN GND). The pinouts are located either close to the top of the PCB, or next to the Ethernet jack. Plug in the transmitter to the pinouts, making sure the DATA-VCC-GND pins on the transmitter match the A3-VIN-GND pins on the circuit board. Then solder the three pins at the back of the circuit board, and clip as necessary. Carefully arrange the wire antenna around the LCD and re-install the enclosure.

It’s important to use a wire antenna of sufficient length, otherwise the transmission range will be severely limited.

Step 3: Final Testing
Make sure your OpenSprinkler is running firmware 2.1.1 or above. If not, please follow the firmware instructions to upgrade your firmware first. Then go to Edit Stations, select the station you’d like to use as an RF station, and change its name to the 16-character hexademical code recorded on the RFToy. Any station with a name of this form will be automatically recognized as an RF station. When the station is turned on, the controller will automatically send out the signal through the installed RF transmitter, thus turning on the corresponding power socket (and vice versa for turning off the station).

Three quick notes:

  • The normal station function still works (i.e. if there is a sprinkler valve connected to that station, it will be switched on/off accordingly).
  • Most likely you want to turn off the ‘sequential’ flag for RF stations. This is because unlike sprinkler stations, you probably don’t want RF stations to be serialized with other stations.
  • If you are short of stations, just increase the number of expansion boards. You don’t need to have the physical expansion boards (think of RF stations as virtual sprinkler valves). Firmware 2.1.1 supports up to 48 stations in total.

With this feature, you can now use OpenSprinkler to programmably switch a large number of powerline devices, such as Christmas lights, landscape lights, water pumps, heaters, fans.

Keep in mind that because this is still an experimental feature, don’t use it on anything critical (i.e. those that can cause damages if accidentally left on). Depending on the distance and obstacles between OpenSprinkler and remote power sockets, it might not reliably switch on/off power sockets. So take time to do plenty of testing before you finalize the setup.


That’s it. We encourage you to try out firmware 2.1.1 and let us know your comments / suggestions / feedback. Don’t forget to post pictures of your projects. We would greatly appreciate your efforts. Thanks!

Verified: OpenSprinkler Pi (OSPi) 1.4 works with Raspberry Pi A+

As you’ve probably heard: the Raspberry Pi Foundation recently released RPi A+, which is the first RPi that’s smaller in size than any other RPi. It is essentially a B+ with less memory (256 MB vs. 512 MB), one USB port (instead of four), and a compact form factor (65mm vs. 85mm). Not only is it smaller, but it’s lighter, consumes less power, and best of all, it’s cheaper — only $20!

There is a famous Chinese saying: “A sparrow may be small but it has all the vital organs”. This is exactly what I feel about RPi A+. Although it’s almost 25% smaller than any other RPi, it retains all the essential features. Similar to B+, it has a microSD card slot, and hybrid audio / composite video port. This helps reduce the overall size of the assembly. It doesn’t have a built-in Ethernet controller and connector (which contributed to the lower price tag), but most people will likely use a USB WiFi dongle anyways so it’s not a big loss. What’s clever about its design is that it’s pin compatible with B+ — in fact it’s basically B+ with 20mm chopped off from the right edge. All the connectors, pin headers, screw hole locations are exactly the same as B+. This means any shield / extension board that works for B+ is likely to work for A+ with no modification.

Such is the case with OpenSprinkler Pi (OSPi) — the B+ version works perfectly fine for A+. Below are two pictures showing OSPi v1.4 (B+ version) with A+ installed. As you can see, it leaves extra space on the right-hand side to fit additional components.


As you may have guessed: given the extra space, the first components I will consider adding are three pushbuttons. This makes a lot of sense. So far OSPi has been using the same enclosure as the microcontroller-based OpenSprinkler. Because the enclosure is unfortunately not tailored to OSPi, there are several cutouts left unused, such as the pushbutton cutouts, Ethernet, LCD, USB, and power switch. With the extra space on the right, pushbuttons are the easiest to add back. Ethernet controller and connector can also be added, although as I said above I am not sure how useful they are, since most people would probably prefer using USB WiFi dongle.

LCD is another popular feature that has been requested. This is a bit tricky to add because there is simply not enough space in height to fit a standard 1602 LCD like the microcontroller-based OpenSprinkler. However, I’ve got a wild idea that I think is going to work. If this is feasible, then OSPi will truly look just like the microcontroller-based OpenSprinkler. I will post an update as soon as my idea is verified. Stay tuned!

Sneak Peak Preview of SquareWear Esimal

Since SquareWear 2.0 and Mini, there will soon be a new member in the SquareWear family. This is a sneak peak preview of SquareWear Esimal — the tiniest SquareWear ever made 🙂


How does it differ from the other two members? First, it’s tiny and measure only 1.1″ x 0.7″. It’s designed to be small, low-cost, and suitable for breadboard experiments. It has two rows of 1×11 0.1″-pitch pin headers and can fit directly onto a breadboard. Second, it uses a micro-USB connector, which helps reduce the overall footprint. Although the big sewable pins are gone (so are the built-in buzzer and rechargeable battery), the Esimal keeps the most essential features of SquareWear — it has ATmega328 running at 3.3V, 12MHz, with built-in USB port and USBasp bootloader, light sensor (using a photoresistor), temperature sensor (using a thermistor), general-purpose button, and LED. Overall it will be a very low-cost, breadboard friendly SquareWear, for learning Arduino programming, organizing workshops, and general-purpose microcontroller projects.


Since this post is a preview, I will not dwell too much on the details. Expect Esimal to be available in a few weeks time!

Introducing RFToy 1.0

Today I am introducing the first version of RFToy — an Arduino-compatible gadget for interfacing with Radio Frequency (RF) modules. First, let me show you a few pictures of RFToy and a video introduction:


RFToy is available for purchase at Rayshobby Store.

  • ATmega328p @ 3.3V, 8MHz, with CH340G USB-serial converter and Arduino bootloader.
  • Programming in Arduino using the on-board mini-USB port.
  • One 128×64 OLED display, three tactile buttons.
  • 20mm coin battery holder, and slide switch to select between USB or battery power.
  • Pin headers for plugging in 433/315 MHz RF transmitter and receiver modules, and MOSFET power switches for them.
  • 3.5mm audio jack to output receiver signals to a computer’s line-in port, to monitor RF waves.
  • Pin headers for plugging in nRF24L01 transceiver.
  • Pin headers for connecting external components and/or breadboard experiments.

So in essence, RFToy is a 8MHz Arduino with buttons, OLED display, battery holder. It’s compact (1.5″ x 2.3″) and it’s suitable for a variety of projects involving RF modules.



As shown in the video above, I’ve written a couple of examples to demonstrate the basic features of the RFToy.

  • RF Recorder: this demo shows how to use RFToy to decode signals from the remote control of a typical wireless power socket, store the decoded signal in EEPROM, and play it back to simulate the remote control. You can store up to 7 different signals, allowing you to control up to 7 power sockets. The demo is based on the RCSwitch library, and it has a basic UI using the OLED display and buttons.
  • Wireless Temperature Sensor: this demo uses a pair of RFToys — one RFToy has a thermistor (connected to analog pin A1) and sends out the temperature reading periodically through its 433MHz transmitter; the other has a 433MHz receiver, and displays the received value to the OLED. This demo is based on the VirtualWire library, and uses the watchdog timer and power-down sleep to save battery life when the sensor is not transmitting data. A variant of this demo is also provided using a pair of nRF24L01 transceivers and the Mirf library.
  • Interfacing with Off-the-Shelf Wireless Sensors: previously I’ve written several blog posts about using Arduino to interface with off-the-shelf wireless temperature, humidity, rain, and soil moisture sensors. Since these sensors all work in the 433MHz frequency band, these demos can all run on RFToy, with sensor values displayed onto the OLED.

With the built-in buttons, display, and Arduino compatibility, there are tons of other projects you can build with RFToy.

User Manual

RFToy is open-source. You can check out its Arduino library code at, and hardware design files at Some technical details are provided below:

Note: the content on this page is published under Creative Commons Attribution-ShareALike (CC BY-SA) 3.0 License. Content reuse is allowed. If you have a project/product based on RFToy, please acknowledge my contribution. The software code and hardware design are published for educational purpose.

Purchase Link

Dead-Simple Driver Installation for USBasp and USBtiny on Windows

Today I came across a surprisingly simple approach to installing USBasp and USBtiny drivers for all versions of Windows — XP, 7, 8, 8.1, whether 32-bit or 64-bit, all inclusive! As you may know, installing open-source drivers such as USBasp and USBtiny have been a great pain on some of the recent Windows OS, due to the enforcement of signed drivers. The typical solution involves rebooting Windows into a mode that disables driver signature enforcement. Even after you’ve done it once, if you boot into the normal mode next time, it may fail to recognize the driver again (reporting it’s not digitally signed). A huge source of frustration.

Anyways, while searching for ‘fully signed USBasp driver’, I came across this tool called Zadig, which can be used to install libusb drivers on all versions of Windows, and it’s digitally signed. Since USBasp and USBtiny are both based on libusb, could it be the right solution? To my great surprise it worked really well — I was able to install both drivers on Windows XP, 7 (32-bit and 64-bit), 8, and 8.1 instantly, without messing with driver signature enforcement at all. I was mostly surprised such a great solution wasn’t documented more widely online.

  • Go to and download the software (note that Windows XP has a separate link).
  • Plug in your USBasp or USBtiny device. In case your microcontroller uses a USBasp or USBtiny bootloader, enter bootloading mode, and let Windows detect the device (it will report driver not found). If a window pops up asking to search for driver, just close it or click on Cancel.
  • At this point, run Zadig, it should detect the USBasp or USBtiny, or any libusb device that you have. Then in the selection box (see below), choose libusb-win32 (v1.2.6.0), and click on Install Driver, and wait for the installation to complete.

That’s it! Because the drivers are digitally signed, there is no hassle installing it in Windows 7 64-bit and Windows 8.1.

I will be updating the driver installation instructions for OpenSprinkler 2.1 and SquareWear right away, as they both use USBasp bootloader. Users have often complained that it’s frustrating to install USBasp driver for Windows 7 64-bit and Windows 8.1. Those days are now past!

Sneak Peak Preview of SquareWear 2.3

There is an upcoming MakerJam at Mount Holyoke College and I’ve been commissioned to create a new version of SquareWear, numbered 2.3. Following the suggestions I’ve received in the past, I made the first prototype of SquareWear 2.3:


Below I list the main changes / improvements:

  • Added Hardware USB-serial Chip (CH340G) : this pretty much follows the same recent change on OpenSprinkler 2.2u. CH340G is a very inexpensive, easy-to-use USB-serial converter. It’s a low-cost replacement of the popular FTDI chip. With a hardware USB-serial chip, SquareWear can now use the same optiboot bootloader as standard Arduinos use. Also, cloud-based Arduino platform, like CodeBender would also work well with SquareWear. Even better, CH340G is supported out of box on Windows 7 and 8, so no more messing with installing USBasp driver, ever!
  • Added Breadboard Pins (dual-purpose): people asked about the possibility of adding breadboard pins, so in this version there are 13 pins on the right edge with standard 0.1″ spacing. These pins are also neatly laid out to serve a second purpose: they match some of the common I2C sensors (particularly MPU6050 6-axis accelerometer) and bluetooth transceiver. This way you can easily plug in sensors and bluetooth transceiver as optional add-ons! The picture on the right above shows how the board looks like with an MPU6050 and bluetooth transceiver plugged in. With this setup, you can easily make a project that involves motion sensor, and even transmit the signal wirelessly to a nearby computer!
  • Upgraded the 3.3V LDO to a bigger chip (SOT-89 packaging) that can provide higher current.
  • Added AT24C128 (16KB) EEPROM: this follows SquareWear Mini, where the added EEPROM can be useful for storing logging data and animation frames.
  • Removed Build-in Rechargeable Coin Cell: I was quite reluctant to make this change, because the built-in rechargeable coin has been one of the main selling points of the original SquareWear. But to make space for the added USB-serial chip, and also to add the breadboard pins, the built-in battery has to go. On the plus side, this makes the design focus on using external LiPo battery, which has higher capacity and the charging current is also suitable increased.

I will look forward to the MakerJam to receive some feedback / comments on the new design.

Announcing OpenSprinkler Firmware 2.1.0 (Major Upgrade)

I am excited to announce that OpenSprinkler Firmware 2.1.0 is officially release. This is a major upgrade that includes a number of new features, including:

  • Automatic Weather-based Water Time Adjustment using real-time weather data obtained from Wunderground (thanks to Rich Zimmerman who introduced the method, the adjustment method is named after him).
  • Improved Program Settings including per-station water time, flexible start times, custom name, per-program weather adjustment control, and up to 14 different programs.
  • Automatic Timezone and DST Detection based on your location. No need to select time zone and mess with DST any more — once you set your location, the firmware can automatically determine your time zone and DST.
  • Improved Station Attributes and Scheduler including station ‘disable’ attribute, ‘activate relay’ attribute, test station feature (replacing the previous manual mode), automatic serialization of overlapping schedules, and the ability to manually start a program on the controller using buttons.
  • Numerous UI Improvements (thanks to Samer’s hard work) including unified mobile interface, export / import configurations, improved visualization of logging data, and the number of supported languages has expanded to 17 (thanks to all who contributed)!

This is a pretty major milestone as it not only addresses the previous limitations but also introduced critical new features including weather-based control. Furthermore, consider all these are implemented on a small microcontroller with only 64KB flash memory and 4KB RAM 🙂 These significant changes are worth making a new video for. So here is the video tutorial for firmware 2.1.0 (it’s a bit long, but gives you a comprehensive overview of the main features);


With this firmware I’ve also written a more detailed user manual, and API documentation. These are available on the Support page of our new website In addition, there are a total of 4 tutorial videos that walk you through the hardware installation, WiFi connection, firmware features, and upgrading firmware. Be sure to check them out first.

Upgrade to Firmware 2.1.0

All OpenSprinkler 2.x devices (including 2.0, 2.1, and 2.2) are eligible to upgrade to firmware 2.1.0. Please check the ‘Firmware Update’ instructions on the support page to download and run the firmware updater. OpenSprinkler 2.0 and 2.2 are the easiest as drivers are pretty straightforward to install, and there is no bootloading procedure; OpenSprinkler 2.1 is tricky because the driver installation is more involved, and there is a bootloading procedure you need to follow. In any case, the firmware upgrade tutorial video gives you a quick walk-through of all the steps.

To use the weather feature, you need to apply for a Wunderground API key. Again, instructions can be found on the support page.

Firmware 2.1.0 has gone through internal alpha testing and external beta testing, so it should be pretty stable. For issues and suggestions, please use the forum, or the support page to submit support tickets.


When I say ‘all these are implemented on a small microcontroller with only 64KB flash memory and 4KB RAM’, it’s not entirely true — the weather feature and timezone / DST detection are actually implemented using Python scripts hosted at Why? Because these require fairly heavy processing power that’s simply beyond the capability of a small microcontroller. So they are implemented by using Python scripts that serve as the ‘middle man’ — retrieving data from weather websites, perform the necessary parsing and computation, and produce the final results to send back to OpenSprinkler. This way the heavy computation is done in the cloud, and OpenSprinkler only needs to poll the server once in a while to update the results. If you are interested in customizing the scripts, you can download the Python scripts from OpenSprinkler Github repository, modify them and host them on your own server. But for most people the default provided script should work pretty well.

Upcoming Features

As this firmware has been rolled out, we are getting excited to decide on the new features for the next round. Some planned features include:

  • Additional station attributes including soil type, slope type, serial group.
  • Support to store programs and station settings onto the microSD card (effectively allowing unlimited programs).
  • Adding firmware support to interface with remote power sockets, so you can use OpenSprinkler to control power line devices like heaters, fan, Christmas lights etc.
  • Support to use sunset and sunrise times for program start times (the sunset and sunrise times are already being detected using the timezone / DST script).
  • Support for flow sensor to monitor water consumption.
  • Cloud support: no more messing with port forwarding.

Suggestions and comments are welcome. Please post them below, or on the forum. Thanks!


Sneakpeak Preview of OpenSprinkler DIY kit v2.2u

We are getting ready to release the next minor revision of OpenSprinkler DIY kit, numbered 2.2u. This revision is largely the same with the current 2.1u, with three main differences:

  1. MCU clock speed is increased to 16MHz (from 12MHz previous), by using a 16MHz crystal.
  2. Built-in USB-Serial chip is added, by using CH340G, which is a common chip in low-cost USB-serial converters.
  3. With the hardware serial chip, the bootloader is also changed to use Arduino Optiboot, at 115200 bps baud rate and a bootloader size of only 512 bytes.


The first change above is to increase the processing speed and hopefully make the controller faster at handling complex algorithms and transferring data with the Ethernet controller. The second change above is mainly to solve the issue that it has been increasingly painful to install USBasp driver on Windows 8+. To understand the background, all of these have to do with firmware upgrade — how to reflash the microcontroller with new firmwares. Back in OpenSprinkler 2.0, I used to have a separate ATtiny45 chip on board to function as a USBtinyISP programmer, which can reflash the main MCU (ATmega644). This is not an ideal design because it involves an extra chip that we have to program; also USBtinyISP is not particularly fast. So when I designed OpenSprinkler 2.1, I made the conscious decision to get rid of ATtiny45. Instead, I decided to implement a USBasp bootloader for ATmega644, which can present the MCU itself as a USBasp programmer when a button is pressed on start-up. This is quite appealing because no extra chip is required, and the programming speed is considerably faster. The only caveat is that to use USBasp in Windows, you need to install the open-source USBasp driver. This was not the most pleasant thing to do, but wasn’t a big deal as the driver was fairly easy to install.

That is until when Windows 8 came out, with this feature called driver signature enforcement. It basically means the driver needs to be digitally signed with Microsoft, otherwise it won’t allow you to install the driver. Let’s be honest, for open-source developers, who wants to pay the big bucks to get the driver signed? So suddenly this has created an even bigger barrier for average users. The only way around the issue is to boot Windows 8 into a mode that disables driver signature enforcement. This step turns out to be unnecessarily complicated. I’ve often received comments about how it’s painful to install USBasp driver for Windows 8. I recently made a video to demonstrate how to update OpenSprinkler firmware — in this 11-minute video, 6 minutes were spent purely on explaining how to install USBasp driver for Windows 8. That’s an evidence of how unnecessarily complicated it is!

Anyways, I set out to find a better solution, and was glad that I discovered the CH340 chip. It’s basically a USB-serial chip that is often found in low-cost USB-serial cables / converters. It’s really inexpensive (less than 30 cents) and requires very few peripheral elements (just a crystal and filter caps). With this chip, you can now use the standard serial monitor to debug your program, and the bootloader can also now use the standard Arduino bootloader.


What I like the most about this chip though, is that it does not require driver for Windows 7, 8 and above. What? Is that even possible? Yup, I’ve verified it — Windows 7, 8 and 8.1 all recognized it right away. The fact that it doesn’t require driver just makes it a whole lot easier to upgrade firmware. Windows XP and Mac OS still require driver for it, though, but that’s light years better than installing driver for Windows 8.

You may be wondering: wait a minute, what about the FT232 chip, which has been available on the standard Arduino since the beginning? Isn’t what I am trying to do here already done? Sure, CH340 is basically a replacement for FT232 — both are USB-serial converters. But there is an economic reason to go for it: even at volume quantity like 1000, FT232 costs about $3 to $4 per chip. That compared to 30 cents for CH340? You tell me. Another nice thing about CH340 is that it comes with SOIC-16 packaging, which is very easy to solder even by hand. This makes it more appealing than other low-cost alternatives like PL2303 and CP2102.

OK, I’ve done enough advertisement. I am not in any ways associated with the company that makes this chip, I am just excited, and regret that I didn’t know about it earlier 🙂