Forum Replies Created
-
Posts
-
It sounds like there is a problem in reading the time values from DS1307 RTC. I will check the schematic and the firmware to see if there is any bug there. If it can’t read time reliably, that may be the cause of controller becoming irresponsive.
By the way, could you tell me if your controller has a black PCB or green PCB?
It is supposed to show your local time. After you changed time zone, did you restart the controller? Every time you change the time zone, you need to restart the controller so it can grab the correct time from the Internet.
OK, keep me updated. As I am going to officially release 2.0 soon, it would certainly be good for me to iron out any technical issue quickly. Thanks.
OK, if anyone can please send me back your OpenSprinkler 2.0, I will take a look and diagnose the problem. I have a 2.0 board at hand and I have not encountered a similar problem. Please contact me directly at [email protected]. Thanks.
I can add this to the todo list, but to be honest, detecting conflict is not as easy as it appears: the conflict may happen at some arbitrary day in the future (say if one program is a weekly schedule, one is an interval day schedule), so even with an algorithm to automatically detect this, it will have to simulate through a potentially large number of days until it finds a conflict.
If you just want to quickly scale up/down the water time, you can use the ‘Watering Level’ option. It defaults to 100%, but can go anywhere from 0% up to 250%. The watering percentage will be multiplied with the program’s water time, so it’s a quick way to adjust water time globally.
@Benoitm234, glad to hear that it worked finally, and thanks in advance to help spread the word.
By the way, I have recently set up a Wiki page for Rayshobby, in order to host user-contributed content. This is suggested by Andrew from Australia. He wrote down some initial notes about how to set up RPi to work with OSPi. The Wikipage is at this link:
http://rayshobby.net/mediawiki/We will gradually refine the Wikipage, and hopefully it will receive more community support from users.
It doesn’t have such a feature yet. Will put it on todo list. In the meantime, note that each program can be individually enabled or disabled. So you can add two sets of programs, one for the summer, one for the winter. To switch, just enable all programs in one set and disable those in the other set.
There may be a stability issue that I am not aware of (although I have a test 2.0 circuit that has been running weeks without a problem). Do keep me updated about your findings.
You are right, there is no rain sensor connector on board. There is not much room to put another connector, and also the ultimate goal is to make use of online weather data to detect rain.
If you want to add a rain sensor connector, you can use any of the available GPIO pins. Just connect the rain sensor (which has two wires) between teh GPIO and GND. Make sure to set the pin to input, and you may want to add a pull-up resistor if the GPIO pins do not have internal pull-up.
Denny,
To diagnose the problem, could you please first specify which version of OpenSprinkler you have, and whether it’s DIY or fully assembled?
In manual mode, the normal programs will stop running. This is explained in the online user manual:
http://rayshobby.net/?page_id=730#manualManual mode is mainly designed for users who want to use another device to control OpenSprinkler through HTTP commands. If you want the controller to automatically turn back to program mode after a manual session, please consider using the Run-Once program.
The traic has a maximum continuous current of 800mA, so it should be able to run two valves together.
As additional information, this page contains some tips on sprinkler valves:
http://rayshobby.net/?page_id=207#sprinkler_valvesIngo,
The USB is only used for flashing the microcontroller, it cannot be used for communication.
For interfacing with other automation systems, the easiest way is probably through the HTTP GET commands:
http://rayshobby.net/?page_id=730#httpgetAll commands are implemented with HTTP GET command, including Enable/Disable Operation. For example:
http://x.x.x.x/cv?pw=opendoor&en=0
will disable the controller. For details, please check this section of the user manual:
http://rayshobby.net/?page_id=730#httpgetWell, you can tell if the controller crashes when running a particular zone. OpenSprinkler currently does not have circuitry to automatically detect defective solenoids, so you need to find it out manually. I don’t have much experience with defective solenoid, but I guess there are quicker ways to test, such as testing the coil resistance (if the resistance is too low compared to other good solenoids, that indicates a problem).
The first thing to try is to unplug the common wire terminal (so the solenoids will not be activated) and see if the controller still crashes. If not, that means the problem is either a defective solenoid, or the PTC fuse under high temperature (as discussed in this thread: viewtopic.php?f=9&t=84). If the controller still crashes even after the common wire is disconnected, you should return the controller for a replacement. Send email to [email protected] for support.
I see, I thought you have 1.4.2u (which does not have 1N4148 but a 5.1V zener diode instead).
Anyways, it looks like you have the 1.4u. Is your PCB showing July 2012 as the date or Oct 2012? D4 only appears on July 2012 PCB. I grayed that part of the instructions out because I assumed anyone who has bought the July 2012 batch would have finished building the circuit by now.
When this happened, did you power the controller via USB or 24VAC? If you powered controller through USB, it doesn’t go through the power switch so the screen will be always on. If you powered through 24VAC, you should check the power switch and see if there is any solder joint shorting. The 24VAC goes through the power switch so it should cut off power when you switch it off.
I think this has been explained in the user manual. Specifically, in the online user manual, there is a section that describes ‘Understand how the programs are executed’:
http://rayshobby.net/?page_id=730#program
and the third bullet says ‘While a scheduled list is running, no other programs will be scheduled even if a match is found.’. Perhaps I should make it more explicitly by saying that ‘The other programs will be ignored’. I recall that the video also briefly describes the way programs are executed.So if two different programs have exactly the same time settings, they will always be scheduled together and the stations will be serialized. If one happens to be a minute behind the other, it won’t get executed. The reason is mainly because if you push the second program behind the first one, it may get into conflict with a third program, and as a result all the programs will be pushed back. This can potentially lead to a stack overflow problem. I am not saying this will necessarily happen, but for robustness it’s important to make sure the algorithm does not crash under any circumstance.
More intuitively, if you have a number of tasks you have to do, and one is behind schedule, you could keep pushing tasks back but you might run into the risk of never get back on schedule, or the other solution is to simply ignore the task that’s behind. The current firmware uses the second approach, and so it is up to the user to make sure programs are not ignored unintentionally. The program preview feature is particularly designed to help you find these potential problems. If you find a problem in the preview, you can modify the program time settings accordingly.
