Forum Replies Created
-
Posts
-
If you want to quickly test, you don’t need to wait till the next day morning, you can create a new program with a start time that’s a minute after the current time, that would allow you to see if the program will run in the next minute or two. If that works, the main program should work too (unless if that program is disabled).
Well the only possibility I can think of is perhaps the timing is a bit skewed. What version of RPi are you using? RPi 2 or RPi 1?
I am a bit surprised that RFToy cannot detect the signal sent from RPi — even if the timing is a bit skewed, it should still be able to pick it up. To make sure I am on the same page: assume the transmitter is connected to pin 15, when you send a signal, do you hear the relay noise? I understand that it made a noise when your RF transmitter is not connected to that pin, my question is when the transmitter is connected to pin 15, does the relay make the noise? This is a indication that the controller is actually sending signals out. If not, that means the controller does not recognize the code and is not sending the signal out.
If it is indeed sending signal out, ideally RFtoy should be able to pick up that signal and shows the decoded hex code. You can compare it with the original code and find out how much the timing (last four bytes of the hex code) differ.
The OpenSprinkler Pi user manual has a couple of diagrams that may help understand how to wire sprinkler valves:
http://rayshobby.net/docs/ospi14_manual.pdf
page 6. Most sprinkler controllers use the same wiring interface (COM + individual station wires).OK, I made some progress: I was able to reproduce the issue and it seems to have to do with the way the Ethernet library handles multiple packets. I modified the code to address the issue and updated the firmwares. You should launch the firmware updater, click on ‘Download Firmware’ to grab the latest firmware files, and update firmware. You don’t need to re-import. Let me know if this fixes the issue. Thanks.
This will be fine if the program has only one station to run. But what if the user selects multiple stations, and they are all sequential, then it’s not clear to me how the controller should execute this program. For example, if you set station 1 to end at 5pm and station 2 to end at 6pm, does it mean station 1 will run first, and station 2 then runs till 6pm? Since both stations are sequential, they shouldn’t overlap. We need a clear definition of what it means when you have multiple stations in a program and each has a specified end time.
I think this has to do with DHCP: you are using static IP (dhcp=0). Right after firmware upgrade, the controller is back to DHCP mode. During the import process, the IP address will immediately change after the DHCP is set to 0, and therefore the import cannot continue and complete. We highly recommend keeping DHCP but use your router’s DHCP reservation to create a fixed IP. This way there will be no issue with import, and you are less likely to get into IP conflict issues.
In any case, if you restart and try ‘import configuration’ again it should be able to complete the import.
I’ve just responded to this question here:
https://opensprinkler.com/forums/topic/station-end-time/#post-37337By the way, since you’ve set your program’s start time based on the sunrise time — you should first check if the controller is getting the correct sunrise time. You can click the weather icon on the homepage, and the first sunriset time (i.e. today’s) is the one that the controller receives. If it looks incorrect, you may want to check if you’ve set your location correctly. The firmware queries the cloud server to obtain sunrise / sunset times, so another possibility is that for some reason it’s not getting the query result back.
Cool. Thanks for sharing. I just want to point out that for those using the OpenSprinkler Unified Firmware — it also supports using sunrise or sunset times to define a program’s start time, and additional you can set a station’s run time to be sunrise to sunset time or sunset to sunrise time.
This was a bug in the early versions of firmware 2.1.3. If you do a ‘git pull’ to obtain the current version (firmware 2.1.4) and recompile the bug should be fixed.
This is on our todo list, however, I am not sure when this will get implemented, primarily because introducing the concept of ‘end time’ would incur some significant changes to the program’s data structure and the UI. I will keep thinking about what’s the easiest way to handle this.
You may be able to compile the OpenSprinkler unified firmware directly using cygwin, assuming Win10 supports cygwin.
First, I apologize for not responding to RobTX’s first post. I must have lost track. I don’t have enough knowledge to comment on commercial 2-wire systems. These systems are closed source so we don’t know the encoding mechanism without some serious reverse engineer efforts. I also suspect different companies use different schemes, so I don’t know how practical it is to add support for these systems.
Second, I believe it’s possible to use expansion board with a custom extension cable of a couple hundred feet long. I’ve heard some users have done this using a long Ethernet cable.
Next, we will soon add support for remote sprinkler stations installed on a different OpenSprinkler — say if you have two OpenSprinklers, you can use one as a master controller, and specify stations that physically exist on the second OpenSprinkler. This should be a fairly simple firmware change — as of now the firmware already supports remote RF stations, which allows OpenSprinkler to switch remote power sockets.
Regarding Paul’s comments: the OpenSprinkler expansion board is already a board that has shift registers and triacs. It’s basically a way to use cascaded shift registers to extend the number of stations. Is this similar to what you described?
I’m confused: I thought you said the transmitter worked with the RFtoy, which means the transmitter itself is working, is that right?
Not sure when you checked out firmware 2.1.3, but it had a bug which causes the scheduler to not run if the OpenSprinkler app or web interface is closed. Can you do a git pull to update to the most recent version and try again?
You can check that information from the OSPi user manual:
http://rayshobby.net/docs/ospi14_manual.pdf
page 10.If the cable is very coiled, it will have non-zero inductance, and hence its resistance to AC will be higher (causing high voltage drops).
0.42 ohm / meter does sound quite high. According to this, even without considering inductance, it will be dropping 0.42 * 52 * 0.29 = 6.33V, which is quite a bit higher than your measured voltage drop.
Dan’s Python interval program might be able to run on Windows 10. The unified firmware might be able to run on Windows 10 too, using cygwin. I’ve never tried either so I have no idea.
Samer is right. I feel like I need to write a blog post about this because it has been such a common question. Technically a power adapter rated at 2 amp means it’s capable of supplying 2 amp while still maintaining the rated voltage. But it’s not like the power adapter is constantly pumping out 2 amp — it just means that if your circuit draws 2 amp, it will still be able to guarantee the rated voltage. If the circuit draws more than 2 amp, the output voltage will start to drop and eventually collapse (which typically triggers a reset of the device). However, if your circuit only draws 1 amp, that’s totally fine, it’s not going to be destroyed or anything.
OK, I am a bit surprised that it’s adding -D, because it should usually do a flash erase before uploading a new firmware. Alternatively, try or OpenSprinkler Firmware Updater, which is basically a GUI wrapper for the avrdude command.
I don’t have enough knowledge about GFCI. But I did some Google search and my understanding is that it trips when the difference between the supplied current and returned current is more than, say 6mA. This is often due to leakage current, unexpected shorting to ground, or anything that causes the current to leak out without returning. I can’t think of an obvious reason for your case, but I suspect if there is a wire that is worn out or exposed, it can result in leakage which trips the GFCI.
