[Ray]

OK, I think I found a potential solution to the issue. First of all, the 1 second delay is because the program only checks and performs bookkeeping of running time once every second. This is to give sufficient time share to the Ethernet controller in order to improve response time to web requests. Therefore, after a schedule is finished, the program goes back to the beginning of the loop (where it checks web requests), and does not perform scheduling until a new second comes. So the quick fix is that after a schedule is finished, let the program re-do schedule checking before going back to the beginning of the loop, and this should solve the problem.

Specifically, you need to add the following two lines in inverval_program.pde:
1. Before the comment // ====== Schedule program data ====== and after svc.rainsensor_status();, add a label, such as:
svc.rainsensor_status();
CHECK_PROGRAM_SCHEDULE:
// ====== Schedule program data ======

2. Locate code “mas = svc.options[OPTION_MASTER_STATION].value;” around line 307, and add the following line after that:
goto CHECK_PROGRAM_SCHEDULE;

Basically this directs the program to go back to schedule check after a previous program is finished, and it should eliminate the 1 second delay.

Note that this only works when sequential option is turned on. If you want to run the controller in parallel mode, there is an additional change you should make. Also, keep in mind that this has not been tested thoroughly, it’s a rather ad hoc solution. Give it a try and see if it works.

[Ray]

Regarding the serial port: please follow the re-programming instructions — you only need to select board and then click on Upload, there is no step to select a serial port. This is because OpenSprinkler does not have a USB-serial chip (which the standard Arduino has).

I will take a look at the timing issue as soon as I can. Meanwhile, have you considered adding a UPS backup power supply? That may be the simplest solution to the power interruption problem.

[Ray]

Without knowing the internal circuitry of your manual controller, it’s hard to tell. For example, on some controllers the COM wire is the logic ground of the circuit, while on OpenSprinkler it’s not. If you try to connect the two in parallel without knowing these details, it may directly short the sprinkler transformer. So unless if you are confident about how the manual controller works internally, I don’t recommend connecting them in parallel.

[Ray]

That’s a good suggestion. I am planning to use mcu’s watchdog timer for this. The very first version of the firmware actually did use watchdog timer to prevent deadlocks. But I removed it later. The shift register is now refreshed every second.

[Ray]

You can install VirtualBox and run a virtual Linux system in Windows, as described here:
http://rayshobby.net/?page_id=732#compile
I recommend Ubuntu 12.04 or Linux Mint 13, which comes with avr-gcc 4.5.3.

[Ray]

That’s probably because the program did not clean up the GPIO when it terminated during the last run. I think I’ve added code to call GPIO.cleanup upon pressing CTRL+C, but maybe the program terminated in some other way.

[Ray]

Hi Ric,

Thanks for pointing this out. Indeed I had no idea there are two versions. I suppose this is a Python library/software thing (since you said the c program worked). I will post about this on my blog.

[Ray]

OpenSprinkler does have a few GPIO pins for reading sensor values and actuating devices. For controlling garage door, you may want to look into examples of RF remote control: most garage door remotes work in 434 or 315MHz RF range. You can capture the remote control signal and simulate it using an RF transmitter plus on microcontroller pin. I have a blog post about this:
http://rayshobby.net/?p=3381

[Ray]

I have not planned to add soil moisture monitoring to OpenSprinkler yet. This is mainly because I suspect most users still prefer a time-based program, with potentially some weather-based refinement. Adding soil moisture sensor will potentially complicate the scheduling, and in case the sensor fails to return correct reading it can be come a source of reliability issues.

I do have an upcoming product called OpenSprinkler Sip, which is designed for indoor plant watering and it does use a soil moisture sensor. You can take a look at the picture on this webpage:
http://rayshobby.net/

[Ray]

OK, I’ve added a note about this. Thanks for the suggestion.

[Ray]

The 540 minutes limit is mainly because the duration time is stored in a signed integer. So the maximum duration is 32767 seconds (roughly 546 minutes). This should be easy to change to twice as much, by using unsigned integer. I will put it on the todo list for the next update.

Regarding the solution to frequent power loss. The way you described seems to be the best. I just did a test on my controller: setting 1 minute duration with 1 minute interval seems to do what it’s supposed to (except there is a 1-second delay). I cannot reproduce the problem you described as ‘run 1 minute, stop 1 minute’. The 1-second delay can be avoided by deleting the + 1 in the following line:
unsigned long accumulate_time = curr_time + 1;
at function ‘void schedule_all_stations’ in interval_program.pde

[Ray]

The controller doesn’t need to access the Internet in order to run. But the browser (i.e. http client) you are using to access the controller homepage needs to be able to access the Internet. This is because rendering the controller webpage requires Javascripts that are by default stored on rayshobby server. Alternatively you can store these Javascripts on your local server (such as a raspi as several people have done).

[Ray]

@Gyro: the Javascripts have been recently updated. Please check again and let me know if the day is still incorrect.

Regarding automatically going back to program mode: I suggest you use the run-once program (which automatically goes back to program mode after it’s done), not the manual operation mode (which is mainly used for testing stations and for users who want to use a script to send command to the controller).

[Ray]

@Gyro: you are right, the fuse is rated at 750mA, so having 4-5 solenoid running at the same time is likely to trigger it. The triacs are rated at 800mA continuous current and 8A impulse current. To be honest, when I designed the circuit, I didn’t realize that the PTC fuse is a slow-action type. So by the time it triggers, the triac may already be destroyed (say, if a solenoid is defective and short circuited). Therefore the PTC fuse may not be very useful.

[Ray]

You can send the picture to [email protected]

[Ray]

If voltages are correct under USB, that means 5V->3.3V is working fine. The problem is most likely in the 24VAC->5V conversion. The Resistance Between PTC (top leg) and D1 (left leg) doesn’t tell much because these two pins are connected by PCB trace. Here are my suggestions:
– check if you have any missing component
– did you insert IC1 (MC34063)?
– does the PTC fuse feel very hot?
it would definitely help if you can post an image of the lower-left side of your board (the 24VAC->5V conversion part).

[Ray]

This should be possible. For exemplar, the OpenSprinkler can be connected to Pi with a cross-over cable, and then Pi is connected to the main router through USB WiFi.

Just to give everyone a heads up: I am working on an OpenSprinkler Pi edition: basically it’s a shield that’s wired to Pi through the GPIO pins, so the Pi can directly control the shift register and hence the solenoids. The board is essentially a subset of the current OpenSprinkler hardware, with 24VAC->5V power conversion, shift register and triacs, and DS1307 RTC. The 24VAC->5V is capable of outputting 1A current, so it can power a PI board together with a WiFi USB dongle. The hardware has been tested and is working fine. It’s pretty straightforward and the nice thing is that I designed some copper pillars to support the Pi board on top of the shield, so that everything can fit inside the existing OpenSprinkler enclosure. The software is not finished yet: I’ve written a piece of Python code that runs a very simple http server, presenting a list of buttons and allows you to control solenoids manually (very much like the first manual control program for OpenSprinkler which I wrote a long time ago). I am hoping to post about it some time this week and next week. This should probably attract some interests from people who have a Pi at hand.

Some pictures for the curious:

[Ray]

@aradke: you are right, that’s the command to change the water percentage.

A few weeks ago I posted a more complete list of HTTP GET commands on the website:
http://rayshobby.net/?page_id=730#httpget
(click on the PDF link). The commands to change option values (such as the water percentage) are kind of messy and obscure, but hopefully this document will help.

@grondo: the ‘cycle-and-soak’ program is an interesting idea. aradke’s suggestion should work (e.g. a single program for each ‘cycle-and-soak’ station with 20 minutes interval time and 10 minutes water time).

[Ray]

There is no server function for this, however, the stations names are returned as a Javascript array called ‘snames’ on most pages (for example, the homepage /, the view stations page /vs, the view programs page /vp, etc).

[Ray]

Cool, nice to hear that it’s working. Thanks for the update.

[Ray]

Wouldn’t it be easier to use a phone or pad to control stations? That way you can walk around the house and test your sprinkler valves. There is also an iPhone app for OpenSprinkler:
http://rayshobby.net/?p=4973

[Ray]

Please check this blog post:
http://rayshobby.net/?p=4233

[Ray]

There are two places you need to change:
1. the call to ENC28J60::initialize takes csPin as a parameter, so find where that function is called and change that to your desired number.
2. inside ENC28J60::initialize function, notice there is a line where selectBit is calculated. This is hackish way to compute selectBit assuming the csPin is a PORB pin. The author of the library probably did this to speed up changing pin values, but you need to verify if this is valid with the csPin you selected. The simplest way is probably to find where selectBit appears, and just change them to use digitalWrite.

[Ray]

Sounds like an issue with your browser not able to access the Javascript. If you type in the following in your browser:
http://rayshobby.net/scripts/java/svc1.8/home.js
what do you get? Note that because the Javascripts are stored on the rayshobby server, your browser needs to be able to access the Internet. On the other hand, the controller itself does not need to access the Internet in order to run programs.

For the noise problem: it’s normal to have an audible noise. But if it’s loud vibrating noise, you should check 1) if the solenoid is ok (the easiest way is to try a few solenoids and see if they all make that kind of noise); and 2) check if you’ve soldered the resistor networks correctly — the two resistor networks (RN2, RN3) above the triacs must be of type 330ohmx4 or 220ohmx4, if the resistance is more than 330ohm, the triac won’t fully open, causing the noise problem.

[Ray]

The view program page (http://x.x.x.x/vp) returns the complete list of current programs. You can check the bfill_programdata() function in server.pde to see the relevant Javascript variables.

[Author]

Posts