Dan K. from California wrote an excellent blog post about how to set up a Raspberry Pi to work with OpenSprinkler. The link to the blog post can be found here:
http://xperimentia.com/2012/12/14/setting-up-a-raspberry-pi-to-work-with-opensprinkler/

and you can download his scripts from the OpenSprinkler GitHub repository (link given in his post). The scripts basically consist of two parts: 1) storing and serving Javascripts required by OpenSprinkler on a Pi server (recall that currently these Javascripts are served on the rayshobby.net server); 2) using Pi to log OpenSprinkler status (this part is based on Dave Gustavson’s PHP scripts). As Raspi is compact, low-cost, and low-power, it is becoming an increasingly popular embedded Linux platform. The combination of Pi with OpenSprinkler also makes it possible to develop sophisticated features in the future like weather-based irrigation control, or leaning-based control like the Nest thermostat. Perhaps it’s time for me to think about an OpenSprinkler Pi Edition 🙂

Recently I’ve received questions about how to check out a previous version of the OpenSprinkler repository. One reason to do so is to recover features that have been eliminated in the most recent firmware, such as the parallel / concurrent running mode. As in any version control tool, GitHub allows you to do this pretty easily. Here is how.

First, go to the OpenSprinkler Github page, at https://github.com/rayshobby/opensprinkler, and click on the ‘XX commits’ link on the right side, shown below:

This brings you to the commit history, which lists all previous versions of the repository. Next, from the commit message or date, figure out the entry that you need to check out. Say, I want to check out firmware 1.7, and I found the entry here:

After clicking on ‘Browse Code’, you will be directed to a new page, which looks just like the homepage but with a different version number. Now, simply click on the ‘.Zip’ icon on the upper left to download the whole repository as a zip file. That’s it. Simple, isn’t it?

As I’ve given you a heads up in the previous post, there is now an iOS app for OpenSprinkler called SprinklerAce, developed by Michael at FeedFriendly.com. I know many people have requested an OpenSprinkler mobile app. I haven’t been able to split time to work on it myself. I am happy that Michael went ahead and wrote the first version. Here I will give a brief overview of the app. For details please refer to the SprinklerAce website.

SprinklerAce is extended from its previous version called IC Sprinkler, which was dedicated to the IrrigationCaddy. IrrigationCaddy is another Internet-based sprinkler controller on the market. It has nice polished UI design, but on the other hand it’s closed-source, has no LCD display, no support for extension board, and a limited set of three programs. Well, what I am trying to say here is that OpenSprinkler is better, more flexible, and actually comes at a lower price tag :). Michael made a clever choice to extend the app to support both OpenSprinkler and IrrigationCaddy, so the same app can be used for both.

Once installed, you will see the SprinklerAce app on your iOS desktop. The app is pretty self-explanatory and simple to use. Below I am going to mix screenshots captured on my iPad and those from the app website. The homepage shows a list of the current controllers. You can add a new controller by providing a name, ip address, port number, and password. You don’t need to input UserName because OpenSprinkler does not require that. You can add many controllers: for example, you may have more than one controller units, or you may create one with internal ip and one with external ip so that you can use it both at home and remotely. Once you click on a specific controller, it will show the list of stations. If you have defined custom station names, they are also supported here.

The app is currently designed to only manually open and close stations with a specified amount of time. Basically it makes use of the OpenSprinkler’s manual operation mode to control sprinkler stations. Program mode is not supported yet, so you won’t be able to add/modify/delete programs in the app (you need to use a web browser to perform program changes). It is mainly used for manual control and troubleshooting purposes. Once a station is turned on, the homepage will show running status and display the remaining water time. Internally the app reads back the OpenSprinkler homepage once every 5 seconds and makes use of the returned data to update its status accordingly. This is somewhat similar to how Dave’s logging script works. For example, if the controller is running a normal program schedule, you will be able to see the station status and remaining time in the app.

That’s it. It’s pretty easy to figure out how to use it. The app doesn’t do a whole lot yet, but hopefully Michael will continue improving it, including adding support for program mode, changing options and stations names. Basically you can view an app as another way to format the webpages: a web browser makes use of Javascripts to format the pages, and currently OpenSprinkler requires these Javascripts to be stored externally due to its limited program memory space; an app can store formatting code natively so it doesn’t need to rely on a whole lot of Javascripts.

Anyways, if you are interested or cannot live without an app :), feel free to give it a try. The app is now available in Apple store and supports both iPhone and iPad.

DISCLAIMER: FeedFriendly.com is an independent company and is not associated with Rayshobby LLC by any means. If you encounter any problem using the app, or has comments/suggestions, please contact them directly.

Hi everyone, Christmas is coming in a few days, and soon we will be entering the year 2013. I figured this is time that I post about recent progress on OpenSprinkler. Sorry that I haven’t blogged for a while. Various projects have been keeping me busy. I am excited to post and talk about the details of these new projects in the near future. Anyways, what’s new at Rayshobby shop in the past month or so?

Sale Update. A few weeks ago we’ve just shipped the 600th OpenSprinkler. The sale really starting going up quickly ever since the Bay Area Maker Faire this year. I am hopeful that by the end of spring next year we will reach the 1000 mark. That would be awesome :). With a growing community of users, I’ve also started seeing people contributing to this project, including feature testing, debugging, writing scripts and mobile apps (see below). I am really thankful to everyone who supported and contributed to this project.

Software Revision. The latest firmware shipped with OpenSprinkler is 1.8.2. It has been relatively stable and I haven’t seen or received report of any major issue with it. Some of the commonly requested features are 1) adding back the parallel running mode (which was available in firmware 1.7 but disabled in 1.8.x to make space to other features); 2) adding a weather feature; 3) adding a microSD card for logging and storing Javascripts. I am hoping to get the first request done soon: since the feature already exists in previous versions, I just need some patience to sit down, optimize and reduce the current code and put it back in. As for the second request, a friend of mine has been helping me to implement the weather feature in Python script. The plan is to host the Python code on Rayshobby server. This way, the controller can periodically send requests to the server with the user’s zip code, and the Python script will return a simple number that reflects how the water time should be adjusted that day. This will free the microcontroller from having to carry out the necessary computation. It would be a simple scheme to fit a basic weather feature into the current generation of hardware. The third request cannot be implemented with the current hardware, due to the program memory limit. If you need logging, please use David’s Sprinkler Logger script that I blogged about in a previous post. It is available in the OpenSprinkler GitHub repository.

iOS/Android App. I’ve been holding back on developing an iOS or Android app for OpenSprinkler, partly because I am not familiar with programming mobile apps, and partly because the OpenSprinkler’s web interface is already functioning on mobile devices through their web browsers. But I do agree that a dedicated app would look much more appealing and make the product stand out. Fortunately the folks at FeedFriendly.com have developed an iOS app for OpenSprinkler called SprinklerAce. I’m quite excited and I’ve already seen the pre-release version of it. The app is extended from the previous version, which was dedicated to the IrrigationCaddy. It makes use of the manual operation mode on OpenSprinkler to directly control station valves. It’s currently undergoing the Apple Store approval process. I will make a separate post about it once it becomes available. Stay tuned!

Hardware Revision. The latest hardware version is 1.4, and we still carry both the full-assembled products (1.4s) as well as the DIY kits (1.4u). A while back when the last batch of DIY kits sold out, I was considering discontinuing it and start carrying semi-assembled kits, similar to the OpenSprinkler extension boards. But due to the popular requests from users, I decided to still offer the DIY kits, not only because its price is significantly lower than the fully-assembled versions, but also because many people enjoy the process of building a kit regardless of the price. In October 2012, I made some minor revisions to both 1.4u and 1.4s, mainly to improve the reliability of the power conversion circuit. Again, the hardware design is pretty much stable and I do not anticipate any major changes to it.

Also, I’ve been working with SeeedStudios to make a injection-molded case for OpenSprinkler. I’m quite excited because this is the first time I’m working on an injection-molded case. The folks at Seeed are awesome and very helpful. I will certainly learn a lot through the process.

Another bit of news is that I’ve started prototyping OpenSprinkler 2.0. The current plan is to simply upgrade the microncontroller to ATmega644 in order to fit in features like microSD card and more sophisticated weather-based control. Because I am planning to design it to fit the new project case, it will not be available until the case design has been finalized. So most likely it won’t be released until some time in late spring and early summer next year. I do have two prototype images to show off here. I was curious to experiment with different PCB colors, so I ordered a white version as well as a black version:

They both look gorgeous, but I personally prefer the black version because the dark background looks really cool. Feel free to let me know your preference/opinion. In addition to upgrading the microcontroller and adding the microSD card slot, I’ve also changed more components to surface mount packaging to facilitate manufacturing, and adding support pillars for the 16×2 LCD. Again, this is just a hardware prototype, I haven’t started working on the software code yet. The final version will also have to be designed together with the new case. So a lot of things need to be orchestrated before its release.

Upcoming New Products. As I mentioned above, I’ve been working on several new projects. Among which there is the OpenSprinkler Bee, which is an open-source controller for battery-operated sprinnkler valves. I already have a prototype and have demonstrated it at Maker Faire. I am working on making the kits ready soon.

Another product is a controller for watering indoor plants. It has built-in humidity, temperature, and light sensors, and will interface with a compact water pump to automatically water plants for you. I’ve temporarily named it OpenSprinkler Sip. This is a very exciting project that I hope to blog about soon.

All right, so much for the end-of-the-year OpenSprinkler Update. I hope everyone have a Merry Christmas, and see you again in 2013!

Logging is a useful feature which allows you to find out how OpenSprinkler has worked say, in the past week. While you can check the scheduled water programs using the ‘Program Preview’ feature, it does not account for dynamic changes like rain delay, power loss etc. This is where logging comes in handy: you can find out what OpenSprinkler has actually done in the past. Unfortunately I have not been able to include logging in the firmware because of the memory space that it would require to store the log data.

Recently, David Gustavson, an OpenSprinkler user, successfully implemented logging by using a PHP script that he wrote. The way it works is to have a computer that periodically polls the OpenSprinkler status say, every 20 seconds, and the script checks the differences between every two consecutive polls to record status changes. This is quite clever, as it does not require any modification on the OpenSprinkler side. All that it needs is for OpenSprinkler to return the status of each station, which it already does. Of course this does require a computer running on the side (or even remotely), but it’s pretty easy to set up, and you can use a plug computer or a Raspberry Pi which has very low power consumption.

David is kind enough to share his scripts and I’ve checked them in to the OpenSprinkler GitHub repository under the script/PHP/ directory. He also wrote a blog post about OpenSprinkler, which you can read about here. Thanks David!

Recently I received a request to customize OpenSprinkler for a 12V DC external relay board. It turns out to be relatively easy to do. Since it may be useful for other folks, I am writing a post here to briefly describe the modifications. First of all, the relay board has built-in opto-couplers and flyback diodes. It is designed to work directly with microcontroller pins. This particular relay board I received is an active low type. This means normally the relay control pin is pulled high; when the control pin is set low by the microcontroller, the relay will be activated. So before you go ahead and make changes, make sure to find out the type of your relay board.

OpenSprinkler can run on 12V DC power supply without any modification. As long as you keep in mind the polarity, it should work right away. Even if you connect the power supply in the wrong direction, it shouldn’t cause any damage because there is a protecting diode D1 that prevents reverse polarity. The only modification I needed to do is to replace the triacs (used to drive AC solenoids) by NPN transistors. Any common NPN transistor is fine. For example, 2N3904. The remaining step is to connect the station wires to the corresponding relay control pins.

The way it works is that normally the shift register outputs low. So all NPN transistors are turned off, and the collectors are pulled high by the relay board. When a station is open, the shift register pin outputs high, turning on the corresponding NPN transistor, and driving its collector low (to ground). This in turn activates the relay. That’s it.

Here is a video showing the relay board in action. The OpenSprinkler running a self test that turns on each station for 3 seconds.

It is also possible to use the NPN transistors to directly drive the relays. However, in this case, you need to add an additional flyback diode (between the collector of the transistor and the +12V line). The flyback diode is important to protect the transistor under inductive load. To accommodate this, I am planning to add PCB holes for these diodes in the future, which will make it easy to solder these extra components.

I had the urge to send this out a week ago, but I was holding on to it because I had to hear some feedback, suggestions, and issue reports from the initial users. Now I am ready to spread the words:

If you haven’t updated firmware before, here are the Firmware Update Instructions.

As always, the first question I need to answer is: what’s new in this version? Here is a list of highlights:
• New features:

• Custom station names: each station can have a custom name up to 12 letters long.
• Per-station master operation control: each station can individually activate the master station.
• Run-once program: similar to the manual override feature on some sprinkler timers.
• Station delay time, and master on/off adjusted time: fine tune station turn-on and turn-off time.
• Water level/percentage: globally scales water time up and down based on local weather conditions.
• Automatically reconnect: improves reliability on unreliable networks.
• Support for RTC and automatic RTC detection: keeps time running even when power or network is lost.
• Full range of time zones: living in Nepal? No problem.

• Improved features:

• Program now has an ‘enable’ flag which allows you to enable or disable each program individually.
• Improved Graphical Preview feature, which shows each station’s name and scheduled on/off time.

So this is another major upgrade since Firmware 1.6. So what happened to Firmware 1.7? Well, that was a quick update for the preparation of OpenSprinkler 1.4 orders: except for added support of RTC, it didn’t have any major changes. So I had to number this one 1.8 to distinguish it from the previous version.

Also taking a suggestion from the Forum, I’ve starting using minor revision numbers (1.8.0, 1.8.1 etc.) to keep track of changes in between major releases. This way you can easily find out whether your version is up to date.

I’ve also made a video tutorial (above) for those who want a video guide on how to use this firmware. I ended up having to switch between different ways of recording, so the audio quality is not consistent. Sorry about that, and enjoy the video!

I am glad to announce that the new interval program has been released and available for download at the OpenSprinkler GitHub page. This is a major software update since the initial release in October last year. Here is a list of new features in this version:

• Program-based scheduling. Each program consists of a set of days (including weekdays, odd/even day restriction, and interval days), stations, start, ending, interval, and water time. The firmware supports up to 64 programs.
• Choice of running stations either sequentially or concurrently.
• Graphical Preview of each day’s program.
• Integrated Manual Mode. When activated, the manual mode allows turning on or off stations using buttons on the homepage. An optional timer can be set to automatically shut stations off.
• Support for rain sensor and location-based weather checking.

Details can be found in the video below, and the OpenSprinkler Instructions of Use page. This software version is compatible with all existing hardware versions, including v1.0, v1.1, and v1.2u. Feel free to give it a try. To find out how to re-program the MCU with new firmwares, please refer to the Re-programming Instructions. From now onw, the new interval program will replace the previous svc_full_schedule program, and become the default program shipped with all pre-flashed MCUs.

Technical Details

You will find that the new program has significantly improved the web user interface. This is made possible by using external Javascripts. As I described in a previous post, a major challenge in designing full-featured web interface is the limited program memory (flash) size of the ATmega328 MCU. The trick to get around with this limitation is by using external Javascripts stored on remote servers to ‘beautify’ the webpages. When you access the OpenSprinkler webpage in a browser, two pieces of information are combined in the browser: one is the essential data provided by the controller, the other is the set of Javascripts used to format webpages. The process to combine the two actually happens in your browser, which can interpret and execute complex Javascripts. This is called Client-Side processing. In addition to releasing the MCU from carrying the heavy ‘formattting’ code, another advantage of this separation is that you can easily replace the Javascripts to present data in a different format. This is in a sense similar to web Templates. Finally, debugging Javascripts is also a lot faster and easier than debugging microcontroller code, because it requires no re-flashing of the MCU, and most modern browsers support checking and error reporting of Javascript code.

One downside with this approach is that the Javascripts must be placed on a server that’s constantly available. Currently the scripts are stored on the Rayshobby web server, which is quite reliable. The path to the scripts is:
http://rayshobby.net/scripts/java/svc1.6/
There are 7 scripts involved: home.js, progmode.js viewoptions.js, viewprog.js, plotprog.js, modprog.js, manualmode.js. These are used to format various pages, including the homepage, program modification page, program preview page etc. However, if you ever want to customize the Javascripts yourself, you need to make a copy of these scripts and put them on your home server, a cloud server, or any file hosting server that can provide direct file access links. Note that the Javascript files are simply text files that store (human-readable) Javascript code. So any server that can host a text file is ok. If you decide to direct the scripts to your own server, simply modify JAVASCRIPT_PATH macro defined at the beginning of interval_program.pde, and point it to your new path.

You don’t have to worry about the security of using scripts stored on the Rayshobby server. Remember, in client-side processing, your controller data is never sent to the server; rather, it is sent to the browser that you are using to view the webpages. The browser will then retrieve the Javascripts and combine them with the data to present the webpages. Clearly there is no way we can ‘log’ your data or keep a record of your data, so it’s safe.

The Weather feature you saw in the demo video above is implemented using a Python script and Google Weather API installed on the Rayshobby server. This is an example of Server-Side processing, because the Python script runs on the server and not in your browser. The reason this requires server-side processing is because first, the Google Weather API returns fairly long XML data that cannot be directly parsed by the MCU, second, the MCU needs to periodically retrieve weather data, so it needs to initiate requests on its own and cannot rely on the existance of a web browser. Thus the Python script serves as a mechanism to convert complex XML data to microcontroller-readable format, and since it runs on the server, the microcontroller can send requests to it at any time.

OK, so much for the technical details. There is no way to cover all details in a single post. If you want to find out more about how the software works, please refer to the source code, or post a message on the forum.