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 Zimmermans 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 programs 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, Zimmermans 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.
I have worked with some pretty large sprinkler systems (250+ Stations) and most larger systems use what are called “Decoders”(Hunter ICD-100 or Rainbird ESP-LXD Series). Essentially the you run two wires that carry 25 VAC to every controller and then the decoder communicates over the AC wire similar to how X10 works I believe. What I’m trying to get to is, I was wondering is there was every the possibility that open sprinkler could support decoders instead of just using shift registers to control the solenoids?
P.S. – I also have access to wireless remotes that are used to help test the sprinkler system when a technician comes to your house and I think supporting these remotes with open sprinkler would really open up the product to more than just DIY hobbyists.
Hunter Remote: Uses a 3 wire connection (2 power and 1 for communication I think.)
http://www.hunterindustries.com/irrigation-product/remotes/roam-xl
Rainbird Remote: Uses a 5/6 wire connection (Unsure of the wire usage, but the remote uses XBee Radios internally for communication.)
http://www.rainbird.com/landscape/products/controllers/LIMR.htm
Hi Daniel, because decoder valves and those remotes you mentioned are proprietary, we don’t know how to encode the signal to work with these systems. So unfortunately we are not able to support them. Regarding remote: the main feature of OpenSprinkler is web-based sprinkler controller. If you can allow technicians to log on to your wifi network (or if you’ve set up port forwarding so they can access it remotely), then they can test your sprinkler systems using our mobile app.
Hi Ray
Solenoid short detection sounds great !! Hope you are planning for a DC version that integrates with Raspberry Pi.
Could you also throw optocouplers into the design to isolate the higher voltage for the solenoids from the lower voltage that the more sensitive Raspberry Pi electronics use? Other relay designs for RPi has this.
I’ve just burned a brand new RPi beyond repair using just a connected OpenSprinkler Pi system (also brand new), a brand new 24V AC power source (tested, works, delivers 26VAC with floating outputs) and a rather old 24VAC / 125mA solenoid (tested after everything smoked – works fine, but is old, so suspect…). Not sure what happened, other than the pin wasn’t inserted into the solenoid (although it should have been off via software).
Long story short, isolation between the controller and the driver parts of the board would be really, really nice !!
It’s possible to have optocoupler on the DC version — it’s difficult to put optocouplers on the AC version due to the space limitation (optocouplers are pretty big). To be fair, if you look at the commercial sprinkler controllers, many of them don’t have opti-isolation, partly due to the added cost and partly due to the space constraint.
Hi Ray,
I have been using OSPi for years and enjoy it very much. One of the challenges I faced in replacing my standard 8 zone controller with the OSPi was the reality of a standard controller supporting 8 zones and a master zone whereas the OSPi only supports 7 zones plus the master. I’ve owned two houses with “8 zone” controllers so this seems like a common situation. Anyhow, my solution was to write a plugin that lets me implement a 9th zone using the builtin relay. That has been working fine for me with the python program but I see you are eliminating the relay and also not supporting it in this new C++ version. Since you have already shipped a lot of boards with a relay, it seems a bit harsh to stop supporting people who use it right now. Any chance I can convince you to consider adding support for the relay and help out by submitting a patch to get the job done?
thanks,
Greg
Well, since the relay is such a rarely used feature, we removed it and stopped software support for it to avoid confusing users. The current OSPi firmware supports GPIO stations, and it allows you to use spare GPIO pins to define a station. The way this works is you can first set the number of stations to 16, allowing more stations to show up. Then set one of them as a GPIO station, and if your OSPi has a built-in relay you can use the GPIO pin assigned to that relay. This way the built-in relay would still work for you.