[R_W]

Looks good!
Since the calibration values are measured for each zone, and Rotor and Spray have the same unit of measure, I don’t see why both are necessary. Would Sprinkler and Drip be enough?
Showing the user the calibration value and calculated watering duration would be good for debugging and system operation confidence at a glance.

[R_W]

I think most drip systems publish GPM and GPH.

One more thought on what is certainly a corner use case scenario: A few years ago I set up a flood and drain hydroponic system with an AVR controlling a fountain pump for the fill cycle. It was very crude compared to OpenSprinkler. As well as being amazed at the accelerated growth rate possible with hydroponics, I found myself constantly having to increase the fill frequency and duration by small increments almost daily. I could literally watch the plants start to wilt and revive as the pump cycled. A simple slider for fine tuning zone time/water amount would have saved me a lot of repetitive hand coding.
Ultimately the hydroponic system had a catastrophic failure (for the plants) due to a missed watering day. There is absolutely no room for error in that type of system. Growing in soil may be slower, but it is much more forgiving.

[R_W]

@scottsh,
Normalizing on inches (or millimeters) of water makes a lot more sense to me than using uncalibrated time units for irrigation.
The not-to-exceed watering time to prevent runoff is a great idea.
Defining zones as overhead irrigation such as lawn sprinklers (rated in inches per hour) vs drip tape (rated in gallons per hour) for crop and vegetable irrigation would be a useful addition.

Long term for your next plug-in 🙂 , Fertigation valves in series with the irrigation valves that know the crop type and nutrient requirements over the growth cycle of the plant once the planting date has been specified would be awesome.

[R_W]

For turf irrigation, the ability to specify zone inches of water rather than zone watering time could make for a better user experience.
Measuring inches per hour output for each zone , entering them as parameters, and subtracting rain gauge readings would be straight forward.

The not-quite-viral PhD cat food can sprinkler calibration video: http://www.youtube.com/watch?v=W_wn-hwLNtg

[R_W]

Python is not my native language so to speak, but Dan should be able to verify rain gauge type input interrupts in about five minutes with this tutorial and source code for the Pi.
http://raspi.tv/2013/how-to-use-interrupts-with-python-on-the-raspberry-pi-and-rpi-

Edit: There does seem to be more than a few open bug tickets for the RPi.GPIO library concerning interrupts. Perhaps a rain gauge is better suited for the AVR on the OSBee.
http://sourceforge.net/p/raspberry-gpio-python/tickets/search/?q=!status%3AVerified+%26%26+!status%3AInvalid+%26%26+!status%3ADuplicate+%26%26+!status%3ADone+%26%26+!status%3AWontFix+%26%26+!status%3AFixed

[R_W]

I’m not sure if the Raspberry or Beagle have reliable interrupt driven inputs like the AVR’s. This $4.99 rain gauge has a dry contact reed relay output and a phone jack style connector. I haven’t measured the rain amount per pulse yet. In any case, measured rain total readings would take some of the guess work out of watering time adjustments. http://www.ambientweather.com/amws1180rg.html
Some photos of the internal mechanism: http://www.philpot.me/weatherinsider.html

[R_W]

I’ve wired up a nRF24L01 directly to the expansion connector of a Raspberry Pi. It does not use any of the pins that OSPi uses, so no coflicts there. I’ve also tested basic one-way communication to a remote atmega168 with another nRF24L01. So far so good.
I use the wiringPi library and a bit-bang SPI communication routine on the Pi written in C.
Now for my question to Dan and Ray. Have you defined the radio data payload structure yet? Sending [zone_num,seconds_on] from the host to the remote for immediate execution would seem to be the minimum. Is the OSBee going to have multiple zones and inputs as well as outputs?

[R_W]

Extending battery life on the OSBee will require powering off the radio and putting the AVR into a sleep mode most of the time.
On a project I built a few years ago, I had the mains-powered host send a heartbeat every two seconds. The battery powered AVR remote device had a 32khz crystal for a RTC function. The first time the remote device read the heartbeat through the radio, it would zero it’s internal counter/timer to only wake up, power up the radio, and listen for commands during a 10 mS window every two seconds. This control scheme made a huge difference in battery life.

[Author]

Posts