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.
Really?! Sounds interesting!
Another question for you: provided you would have (for free) an old PC available with built-in wifi and usb, what would be the cheapest design to achieve the same functionalities? I mean, would I still need the same kit (without the wifi router) or could you think of something even simpler and cheaper?
It will save you a Ethernet controller and perhaps you don’t need LCD and buttons either. You will still need a microcontroller and the traics in order to switch sprinkler solenoids. Also, your PC needs to be placed fairly close to the controller, since USB doesn’t run very far.
The fw need js to be placed on a web server or any path is accepted?
Is a path \\ip-address\folder\my_file.js ok for the fw?
I ask this because in case of internet connection fault is impossibile to use the web interface.. but a router with USB port that, with an usb disk/stick, can be used as network drive.. can jump over this issue..
It works as long as there is a way for the client (i.e. your web browser) to access the files. For example, something like http://ip-address/folder/my_file.js will work as long as your browser can access the ip-address specified. The scripts cannot be stored on the controller because there is not enough flash memory space. I think there may be a way to store them locally on your computer, but I haven’t tried that.
Ok.. so no need to have an http connection.. it can work with a nas without a webserver but with folder sharing. Great!
What do you think about adding sdcard support to the board? With a “plain” arduino this can be done through SPI pins (or with a storage shield). This could open to local files storage, data logging and so on… 🙂
I don’t have any plan currently to add sdcard support. You are right that it uses SPI interface and should be easy to add. However, it’s difficult to make space on the PCB to fit an sd card slot; in addition, I am worried that there is just not enough program space to add software support for sd card. So this probably has to wait.