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);
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!
Ray, is this also for the OSBo?
Unforuntately not. This is for the microcontroller-based OpenSprinkler, it’s not compatible with OSBo and OSPi.
Maybe you could add the ESP8266 module for easy WiFi connectivity. See this site (https://nurdspace.nl/ESP8266) for details about this new module … found from HackADay.
Sure, definitely considering the possibility. I’ve already blogged out ESP8266: http://rayshobby.net/?p=9734
Ray,
I hope you will publish detailed instructions for hosting the Python scripts and everything else “cloud”. If, for whatever reason opensprinkler.com won’t be available (now or in unforeseeable future), I don’t want my controlled stops working.
This is the primary reason I’d personally stay with the old firmware (mine is 2.0.7), besides disliking the new UI.
If I’m not mistaken, the firmware is automatically updated on the latest versions …
Hi Guys
I need to have multiple masters or an “and” function.
I have different masters for different zones and in some case I just need one zone to always come on when another starts. EG a pump starts with zone 2
But can’t just use a single master.
Thanks.
You should update to firmware 2.1.2 — it supports per-station ‘sequential’ flag. For each master station you have, just set its sequential flag off, and then assign it in a program with other stations. This will allow you to achieve multiple master stations.
Love it! Love it! Love it!
I’ve replaced my Hunter X-Core irrigation controller and it works like a charm. I do miss the benefits I had with the Hunter Solar-Sync sensor which in addition to being a rain sensor, is also an evapotranspiration (ET) sensor which is send to the controller after every 24 hours to globally adjust the run-times up or down, based the water lost from the soil.
http://www.hunterindustries.com/en-metric/irrigation-product/sensors/solar-synctm
The Hunter Solar Sync sensor still only connects with two wires, so I’m guessing some sort of serial message from the sensor is pulsed to provide an adjustment of 10%-150% of the configured run-times. Any ideas on how we can incorporate this into open sprinkler? I’d be happy to help in anyway I can (I’m not an electronics savvy person though).
ET is tracked by most meteorological bureau’s and considered the best indicator of how much water is needed to replace the moisture in the soil, so another way ET can be used is directly from a meteorological service, for example our local one is here: http://www.bom.gov.au/watl/eto/
Other links:
http://www.bom.gov.au/watl/eto/about.shtml
That’s a very interesting thought. I’m aware of the Solar Sync sensor but I’ve never thought about reverse engineering it. Now that you’ve mentioned it I think I will get one to try it out. I do see that there is the sensor itself (which can be used with some of the advanced controllers), and a module which can be used with controllers that don’t have built-in support for the sensor. I am wondering if it would be possible to use this with any controller — not very likely but maybe the module is cleverly using the rain sensor port as a way to turn stations on and off in some sort of PWM fashion to simulate the calculated ET watering percentage.
Thanks for reply!
I quite like where you are going with a possible “universal-like” application, extending it to the OpenSprinkler as a general ET capable sensor. I happen to have the model that has the remote wireless sensor, and the wireless receiver that connects direct to the X-Core controller (as it apparently understands the Solar-Sync signal and does not need the additional “integration module”).
I tried very clumsily with a likely flawed approach to see if I can “pick-up” any thing from the receiver module when I manually trigger the remote sensor. The receiver module only has two wires and I tried reading via the analog input on an Arduino Uno clone (which I setup as a type of poor-man’s oscilloscope for PWM signalling).
I was unable to get anything from the receiver (no noise just a clean clear HI/LO), but I was only running the receiver over the 5v power line (it did power-up but it didn’t seem to successfully pair with the sensor). I’m not sure if I need to give the receiver a separate power source, higher voltage / current or even 24VAC like that used by the controller – I’m out of my depth here, so I don’t know how to proceed further really.
And so one of my other thoughts pointed me towards the wireless sensor unit – thinking that if the receiver does some sort of clever encoding/decoding, perhaps I could glean some insight from the likely RF signal (transmitted from the sensor unit directly). This could be a natural extension as to whether your clever RFToy would be suited to try and figure it out, something along the lines of hooking it up to the sound card and following your related posts about reverse engineering a signal? I don’t have one, so I’ll have to order one to Australia first.
I’m making assumptions here and I don’t even now if the sensor is using 433Mhz.
I’m sure you have other things you’re more interested in, but please do let me know if you make any progress in this area.
So I just received a SolarSync sensor with module yesterday and I’ve started checking the signals. I have some basic findings: first, there are three wires that go back to the main controller: the orange and yellow wires that go to the rain sensor port, and the blue wire that goes to the REM port (i.e. SmartPort). It looks pretty clear to me that the rain sensor wires are completely separate from the REM wire, and the watering percentage value that the module calculates is only transmitted through the REM wire. So that simplifies things a little bit. My understanding is that the REM port can also be used to hook up with a Hunter remote control module — so it must be using some kind of encoding scheme to send program signals through this port, and this would be something interesting to reverse engineer.
What’s strange to me though, is that the blue wire actually carries 24VAC signal, not logic level signal. I am guessing this is done because the two circuits (main controller and solar sync module) do not share a ground wire. Therefore you can’t send logic level signals as that would require the two circuits to share a ground wire. In any case, I’ve make a little circuit hooked up with an Arduino to monitor the signal on the blue wire. It has been running for a few hours and I don’t see any actual signal yet. I guess the module sends data to the main controller very infrequently (maybe once a day)? So I will have to keep it running for a day or two to see if I can get something out of it.
Hi Ray! Are you able to make any inroads with decoding the signal?
On my end, progress has inched along. Received a RSToy v1.1 from a local Australian supplier earlier this week. I’ve managed to capture the RF signal from the SolarSync (WSS wireless model) Rain+ET Sensor unit. I’m half guessing that the signal combines the ET measurement as well as the RainSensor On/Off indication and so I’ve triggered the sensor with a ‘rain’ state and again with a ‘no-rain’ state in succession to try and ensure all other data (that makes up ET component) is remains the same and only the rain bit/bits flipped.
Once in Audacity, I can see that the same “data packet” is repeated 10 times in a burst. Each of these 10 “data packets” are the same.
Comparing the individual data packet from the ‘raining’ signal to the ‘not-raining’ signal I can clearly see there is a bit or two flipped. Please see this link for a screenshot of the ‘on’ and the ‘off’ signals aligned and the difference highlighted: http://1drv.ms/1H8aiot
What I’m struggling with is interpreting this wave protocol as binary bits.
Not sure if it’s proprietary protocol, but it doesn’t seem encoded or anything that I can tell.
Also, should I read anything into the fact that the signal seems to be on the negative biased relative to the y-axis?
Thanks, all of this is fun!
I have a wired sensor with a decoding module (http://www.amazon.com/Hunter-Solar-Sync-Rain-Sensor/dp/B0026Q8AHQ), so the signals I am looking at may be different with yours. I have not made much progress since my last reply. I am able to observe the data on the REM wire, which I believe carries the ‘watering percentage’ value that ranges from 0% to 300%. But I’ve set it up for several days and it’s giving me 10% all the time. Without any variations in the data I can’t reverse engineer the signal. The decoding module sends out one signal every day at midnight (12:00am) so I can manually change the time on the module to force it to resend a signal, but as I said it has never changed over the last few days. The other weird thing is that the signal on the REM wire is modulated by 24VAC (i.e. 50 to 60Hz carrier frequency), which is quite interesting. I am not sure why this is done. In any case, I am still pretty far from figuring it out.
From the irrigation side I know that 10% is the minimum that the controller will adjust to. I would suggest you actually place the sensor in direct sunlight and also pour a little water over it to trigger the rain switch and then measure the evaporation along with the direct sun. Mine doesn’t seem to vary unless there is actual sunlight on it for a long time – maybe even up to a day. You may notice some condensation on the inside of the sensor dome too. Hope that helps.