How to Switch Gardena 1251 Latching Valve using OpenSprinkler Bee (OSBee)

Recently when helping a customer, I came across an interesting case of how to control Gardena 1251 latching solenoid valve using OpenSprinkler Bee. This valve is mostly sold in the European market and isn’t very popular in the US market. On spec, it’s operated using a single 9V battery, and to use this valve you need to buy a Gardena 1250 controller unit. The whole assembly including the valve and controller unit are quite pricy (close to 100 bucks), so it’s not a very cost-effective solution compared to other brands. Nonetheless, it’s an interesting case that helped me understand how these latching solenoids work.

Measure the Control Voltages

The initial request to look into this valve was due to the fact that OSBee can’t seem to operate this valve correctly: it can open the valve but never manages to close the valve. This was reported by a German customer, and it caught my curiosity. To figure out the issue, the first thing I did was to check how the control unit (1250) is sending out control voltages to the valve. It’s pretty common that when operating latching solenoid valves, the control circuit sends an impulse voltage to open the valve, and another impulse voltage in the reverse polarity to close the valve. On most solenoid valves I’ve seen, the two impulse voltage (of opposite polarity) are roughly the same, and that’s also how the OSBee circuit works.

Upon connecting the control unit to an oscilloscope, I noticed something strange: no matter how I press the on/off button, it’s only sending a very short (a few milliseconds) pulse, which cannot possibly operate the valve. Then it became clear to me that the controller is in fact actively sensing the existence of the valve, and would not send control voltages if the valve is not detected. I measured the resistance of the solenoid valve, which is about 35 ohm. So I connected a 33 ohm resistor to the controller as a dummy load, and there you go, now we can observe the control voltages and pulse lengths.

It’s pretty easy to notice the asymmetry here: while opening the valve requires a pulse of 250 ms and -7.84 voltage (this is roughly the battery voltage since my 9V battery isn’t fully charged), closing the valve only requires a very short pulse of 62 ms and very low voltage — 2.5V. This is quite strange to me: how come closing the valve only requires such a short pulse and such low voltage?

How Does This Latching Valve Work?

In order to figure out what’s going on here, I un-tightened a bunch of screws and opened up the valve.

At the bottom of the valve is a pressure chamber with a spring. This is very similar to other valves I’ve seen.

The top section contains, supposedly, a coil and magnet inside, and a small cone-shaped metal piece that can be attracted to the magnet or released. It’s quite easy to observe that when opening the valve, the metal piece gets attracted (left picture above), this supposedly releases the pressure in the bottom chamber, thus allowing the water to flow through the valve. Conversely, when closing the valve, the metal piece is released and dropped to block the hole at the bottom, this supposedly allows water pressure to build up in the bottom chamber, thus stopping the water flow.

The key in making this latching is that an impulse voltage can permanently magnetize the core, thus permanently attracting the metal piece. This makes it possible for the valve to remain in the ‘open’ status without contiguously drawing current from the power source (which is unlike non-latching valves like 24VAC valves).

Observing this mechanism, it became clear to me that ‘closing’ the valve basically requires de-magnetizing the core, and that requires just a short pulse of low voltage in the opposite polarity. If you apply the same voltage and strength as before, it will start magnetizing the core the other way, thus the magnetic pole changes direction but the metal piece will still be permanently attracted!

Anyways, this is very interesting to me because previously I had no idea how latching solenoid valves work internally. Now at least I know understand this particular valve works, and this understanding will help me figure out how to get OpenSprinkler Bee to control this valve.

Use OSBee to Control the Gardena 1251 Valve

There are several issues that make OSBee incompatible with the Gardena 1251 valve, but it turns out they can all be solved without too much difficulties. The first is that OSBee by default boost the input voltage (which is 5V from USB) up to 22VDC, which is significantly higher than 9V required by the valve. This is reasonably easy to solve — by fine tuning the boosting time, I can find the sweet spot where the boosted voltage is just around 9V. This boosting time turns out to be around 80 to 100ms.

Second, OSBee by default uses 100ms pulse in both directions (i.e. both opening and closing the valve). This is very easy to change to 250ms and 62ms respectively to match the Gardena controller.

The last issue deserves more thinking, that is, opening the valve requires 9V, but closing the valve requires only 2.5V. Because the input voltage is from USB and it’s 5V, there is no obvious way to step that down to 2.5V since the boost converter can only bump up the voltage and never reduce the voltage. How do we create this asymmetric voltage in opposite polarities? Turns out that you can do so by making use of a diode connected in parallel with a 100 ohm resistor. Why? The diode is a one-way gate: when positively biased, it turns on almost fully (except the 0.7V voltage drop across it, which can be ignored here); but when reversely biased, it turns off, thus current has to flow through the resistor (connected in parallel to the diode), and that resistor will divide the voltage, ensuring that only about 2.5V falls on the valve.

I’ve attached here a diagram showing the connection. The diode can be almost any general-purpose rectifier, like 1N4148, 1N4001 and so on. I’ve also included two photos showing the actual components connected to OSBee and the valve. With this modification, OSBee can now both open and close the Gardena 1251 valve successfully. Mission accomplished!

Introducing OpenSprinkler Bee 2.0 — a WiFi-enabled Universal Sprinkler Controller

Today I am very excited to introduce OpenSprinkler Bee (OSBee) 2.0: it’s an open-source, WiFi-enabled, universal sprinkler controller. It is suitable for garden and lawn watering, plant and flower irrigation, hydroponics, and other types of watering project. This is the first OpenSprinkler product built upon the popular ESP8266 WiFi chip. It’s designed primarily for latching solenoid valves, but can also switch non-latching solenoid valves (such as standard 24VAC valves), low-voltage fish tank pumps (which can be used to feed water to flower pots and indoor plants), and other types of low-voltage DC valves and pumps. All of them can be powered from a single USB port. This is made possible by using a unique circuit design that leverages a boost regulator and a new solenoid driver circuit. Hence I call it a Universal sprinkler controller. Among the software features, it introduces the concept of Program Tasks, which provides maximal flexibility in programming the zones. In contrast to the first version of OSBee, which was in the form of an Arduino shield and relies on an additional Arduino, OSBee 2.0 is a standalone controller with built-in WiFi, OLED display, laser cut acrylic enclosure, and can switch up to 3 zones independently.

Here is not-so-short video introduction to OSBee 2.0:

Here are two photos of the OSBee 2.0 circuit board:

osbeewifi_1 osbeewifi_2

Screenshots of the web interface and Blynk app:
osbee_screenshots

In summary, in terms of Hardware Design, it has the following features:

A single ESP8266 chip serves as the microcontroller and handles WiFi connectivity.
On-board 128×64 OLED display, real-time clock with backup battery, USB-serial chip. Can switch up to 3 zones independently.
Boost converter and a new H-bridge design that allows the same controller to switch both lathing and non-latching solenoid valves, all powered from a single 5V USB port.
An easy-to-assemble laser cut acrylic enclosure.

In terms of Software Features:

It has a built-in web interface that allows you to easily change settings, perform manual control, and create automatic sprinkler programs. It also provides logging and program preview features.
It introduces Program Tasks to allow maximal flexibility in programming zones. For example, you can define arbitrary ordering of zones, have multiple zones run at the same time, and insert delays between tasks. Zone water time is programmed at precision of seconds.
It allows remote control through the Blynk app and Blynk cloud server.
Firmware update can be performed either wirelessly using the web interface (OTA), or through the on-board USB port with a USB cable.

It improves upon the current OpenSprinkler 2.3 by adding built-in WiFi capability, and using a unified solenoid driver that can handle both latching and non-latching solenoid valves. On the other hand, it can only switch up to 3 zones, and the number cannot be expanded. It’s also missing a few advanced features at the moment, such as weather-based water time, virtual stations (e.g. HTTP and RF stations), and support for sensors. Some of these features are purely software, and can be easily added in the future.

OpenSprinkler Bee 2.0 is now available for purchase at our online store:

OpenSprinkler Bee 2.0 product page

The package includes a fully assembled OSBee 2.0 circuit board, laser cut acrylic enclosure, instructions, USB cable, and optionally an USB adapter.

Resources and Technical Details

OSBee 2.0 is an open-source project. Its hardware schematic, firmware source code, user manual, and API document are all available at the OpenSprinkler Github repository (look for the prefix OSBee in the repository).

Below I will briefly go over the technical details of the boost converter and the solenoid driver, as I think it’s an interesting design that’s potentially applicable elsewhere. The boost converter is borrowed directly from the OpenSprinkler DC circuit. It’s a simple MC34063-based boost regulator that bumps the input 5V up to 24V DC, and stores the charge into a 2200uF capacitor.

osbee_circuit_1

The Booster is controlled by two MOSFET-based high-side switches. The first one controls the input power: the microcontroller uses it to feed the input 5V to the booster, which quickly raises the voltage to 24V. After a couple of seconds, high-side switch 1 is turned off and the microcontroller prepares the states of the half H-bridges (COM, Z1, Z2, Z3). Let me first explain how the states are set for Latching solenoids. The solenoids for the three zone are connected between COM-Z1, COM-Z2, and COM-Z3 respectively. Normally all four half bridges are in ‘High’ state, so the net voltage across every solenoid is 0. To activate a solenoid (say Z1), the corresponding half-bridge will be pulled down to ground (i.e. ‘Low’ state). The microcontroller then turns on high-side switch 2 momentarily to dump the charge from the 2200uF capacitor to the solenoid. This turns on the valve. To deactivate the solenoid, the microcontroller pulls all half-bridges to Low, except the zone that is to be deactivated which remains in High state. It then turns on high-side switch 2 momentarily, again dumping the capacitor charge to the solenoid, but now in reverse polarity, thus closing the valve. This is basically how it operates latching solenoids.

So how does the same circuit work for Non-Latching Solenoids, such as 24VAC valve commonly used in residential sprinkler system? It turns out that just like latching solenoids, non-latching ones also require a pretty high impulse current (called inrush current) to get activated. The difference, however, is that to keep it on, it needs to draw current continuously from the power source. When the power cuts off, the solenoid is deactivated. This is called the holding current and is considerably lower than the inrush current. So to operate non-latching solenoids, all I need is an additional diode that provides a path from the input 5V to the solenoids to provide the holding current. This diode could be software switched by the microcontroller, but because ESP8266 has very few number of GPIO pins, (and I want to avoid having to use an IO expander), I opted to enable this diode path using a solder jumper. To operate non-latching valves, this jumper needs to be soldered on.

osbee_circuit_2

On the Software side, the firmware uses an option to allow the user to choose the valve type (unfortunately the controller can’t automatically detect the valve type yet). For non-latching valves, the half-bridge states are actually easier to manage than the latching case: now COM is always in ‘High’ state, and Z1, Z2 or Z3 are kept ‘Low’ for as long as needed to keep the valves on. That’s it.

You may be wondering how does this even work for valves rated at 24VAC? How can we drive them using DC, and just 5V? The short answer is that this is due to the way such solenoids behave under AC. Specifically, when you first connect the solenoid to 24VAC, it immediately draws a high inrush current, which reliably energizes the solenoid and opens the valve. Once energized, the solenoid presents a large inductance and high reactance to AC, thus limiting the effective current flowing through it. This results in lower holding current, which is enough to keep it on and saves the coil’s lifespan. We can exploit this behavior and achieve the same effect using a DC-based circuit: the booster produces a high voltage initially to provide the inrush current needed to energize the solenoid, and then lowers the voltage to the input level to provide the holding current. Exactly how much holding current is needed is not clearly defined, but for all 24VAC solenoids I’ve tested, once energized, they can remain on at just 5V input voltage.

Now we are left with the last part of the technical details: the Half H-Bridge Design. From the circuit diagram above, it seems we can easily implement the half bridges using relays. While this is totally true, relays are bulky, expensive, slow to switch, and difficult to replace. For these reasons, modern electronics prefer to use semi-conductors as much as possible in place of relays. So I decided to use a MOSFET-based H-Bridge design, and it’s a more interesting design than just throwing relays everywhere.

Typically when you want to switch between GND and a voltage considerably higher than the microcontroller’s output, you can use a half H-bridge design as show in the left image below. It uses a low-power N-MOSFET to drive the high-power P-MOS on the bridge, making it possible to use a GPIO pin to switch a high voltage. However, this generally requires 2 GPIO pins (i.e. A and B) per half bridge. Because ESP8266 has a small number of GPIO pins, the challenge is how to use just 1 GPIO pin per half bridge.

osbee_hbridge_1 osbee_hbridge_2

So I came up with a slightly modified half bridge design, as shown in the right image above. It leverages two low-power N-MOSFETs to drive the high-power P-MOS and N-MOS on the bridge. This allows using just 1 GPIO pin (A) to switch the bridge. When A is Low, both input N-MOSFETs turn off, and the gates of the P-MOS and N-MOS are both pulled high, so the P-MOS turns off and N-MOS conducts, pulling the OUTPUT to Low. When A is High, the reverse happens, and the OUTPUT is also High.

Using two input N-MOSFETs also makes it easy to prevent shoot-through problem, which is often an issue with H-bridge. Shoot-through happens when the control signal A transitions from Low to High (or conversely from High to Low), and at some point the P-MOS and N-MOS may both be in conducting state, causing a shorting. To avoid this, I chose to use two different types of input N-MOSFETs: one with lower gate threshold voltage (such as BSS138) and one with higher gate threshold voltage (such as 2N7002). This way, as the control signal A swings between Low and High, the two input N-MOSFETs will turn on and off at different times, ensuring that the P-MOS and N-MOS will not both conduct at the same time. As for the choices of the P-MOS and N-MOS, I opted to use the common AO3401 and AO3400, which provide ample room for continuous current as well as impulse current.

Sorry about going through these nitty-gritty details, but I think these are interesting design notes worth documenting and sharing. Feel free to chime in with your comments and suggestions. Thanks!

OpenSprinkler Black Friday / Cyber Monday Sales Are On

A quick note that our Black Friday / Cyber Monday sales are on now: all OpenSprinkler products are shown in discounted prices right now, and the deal only lasts till Monday Nov 28. This is the only time of the year that we offer discounted pricing, so if you are interested in buying OpenSprinkler, grasp this chance and don’t let it slip away!

If you are wondering whether you need to apply any coupon code. The answer is NO: the price you see is the discounted price. In the past when we used to have coupons, many customers forgot to apply the coupon in the end. To save you the trouble of having to enter coupon code, we directly discount the price, so you will definitely not miss it.

OpenSprinkler Pi Laser Cut Enclosure

For a long time, OpenSprinkler Pi (OSPi) has been using the OpenSprinkler injection molded enclosure. While this has worked fine, the enclosure is not particularly designed for OSPi, leaving some cutouts not aligned with Raspberry Pi. Recently I have started learning to design enclosures using laser cut acrylic pieces. This is a great way to design fully customized enclosures for circuits. Today the first batch of laser cut enclosures for OSPi has arrived, and we will be shipping these with OSPi kit right away.

Here is a picture of the enclosure pieces and screw bag:

And here is a picture of the enclosure after it’s fully assembled. After removing all the protective papers from the acrylic pieces, it produces a fully transparent look of OSPi, which is pretty cool.

It’s not necessary to remove all the protective papers. I would recommend leaving the papers on except the top panel. This way it gives a kind of wooden texture of the enclosure, and adds more protection to the enclosure.

Below is an instructional video that walks you through the assembly steps:

I will make a separate post shortly that explains how to automate the design of such laser cut enclosures.

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.

Using 24V AC Relays with OpenSprinkler

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.

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:

OpenSprinkler 2.0, 2.1, 2.2 or above.
433MHz Radio Frequency (RF) transmitter-receiver pair.
RFToy.
One or more remote power sockets, preferably those with separate on/off buttons.

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!

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);
http://youtu.be/iUrnf4nIuY4?list=UUl5dnj8oj_9dg6KIbudYmOw

Documentation

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 www.opensprinkler.com. 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.

Implementation

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 www.opensprinkler.com. 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:

MCU clock speed is increased to 16MHz (from 12MHz previous), by using a 16MHz crystal.
Built-in USB-Serial chip is added, by using CH340G, which is a common chip in low-cost USB-serial converters.
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 🙂

« Previous