Forum Replies Created
-
Posts
-
In another thread someone mentioned this relay:
http://www.automationdirect.com/adc/Shopping/Catalog/Relays_-z-_Timers/Electro-Mechanical_Relays/Power_Relays,_Open-Style,_40A_(AD-PR40_Series)/AD-PR40-1C-24A
which seems to work well with OpenSprinkler. Also, I’ve recently bought the following relay:
http://www.amazon.com/gp/product/B005T742IA/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
which is what a lot of pump start relays use, and it works with 24VAC input as well.Beyond these, another option is to use a RF transmitter combined with a remote power socket to control any power line device, as described in this post:
https://opensprinkler.com/opensprinkler-firmware-2-1-1-new-feature-control-remote-power-sockets/
This method is a bit more complex to set up but if you want to control multiple devices it’s a more ideal solution and it’s easy to scale up.OSPi 1.1 was discontinued more than a year ago so we won’t be able to take it as a return. However, you can send an email to [email protected] to arrange for a repair or upgrade.
I think your post is broken or something, I can’t fully understand what you mean. If I guessed it correctly, you want a API that can return the list of programs for a specific station, is that right? To be honest I don’t think it’s worth adding this feature in the firmware — it can be easily done in your client software. For example, if you use Javascript, you can easily write some code to strip away programs that do not include a specific station.
Also, it will help to understand your application. Why are you using the /jp command directly, instead of using the GUI to check programs?
Well, it’s a chicken-egg problem: to see the web GUI you need to know the IP address first. The pre-configured SD card image is actually set to register host name ‘ospi’ with your network, so you can just use http://ospi or http://ospi:8080 to access it. However, I found that the host name registration is not always successfully on all routers — I’ve seen cases where this doesn’t work.
Yes, I have taken a look at Wink a little while back, but haven’t figured out how to get OpenSprinkler to work with it. There is also an OpenSprinkler plugin for Vera lite (a popular home automation controller), which is outdated and I was about to update the plugin myself. Alas, too many things at hand and I haven’t got around time to do either…
Thanks for sharing your work. In the OSBo user manual, I have actually documented the 1.8.3 version:
http://rayshobby.net/docs/osbo11_manual.pdf
page 9. It’s different from the version you found, but the differences are probably very minor.I took a quick look at your github repository, and it seems to use the Penman–Monteith equation, which if I understand correctly is an approximate ET algorithm. Is that correct? Would you mind sharing some more details about it? Thanks.
Regarding controlling remote power sockets: you are correct that the functionality hasn’t been added to the OSPi software yet. Also, OSPi doesn’t have designated pin headers to solder an RF transmitter, so you will need to solder some wires separately to connect a transmitter. If this functionality is important, you should probably consider the Arduino-based OpenSprinkler.
In general, the Arduino-based OpenSprinkler is targeted to typical customers who want an out-of-box working solution, and OSPi is targeted to advanced customers who have experience with RPi, want to tinker with it, and possibly modify the software to extend its functionality. Arduino-based OpenSprinkler also has LCD and buttons.
Regarding relay: on both versions there is a built-in relay, and the software supports the relay. So you don’t even need to hard wire an external relay. In the next revision, however, we are going to remove the relay from all versions, because it doesn’t seem to be that useful, and the original plan to use it for garage door opener would require additional components (like a reed switch or IR switch to read back the status of the garage door). So I feel the relay is a feature rarely used, and should be removed (although the software support can still remain).
Cool. Thanks for sharing. Keep us updated, and post a picture or two if possible. Much appreciated 🙂 Thanks.
I am pretty sure you can use software defined TX/RX — in other words you can designate any two GPIO pins to function as TX/RX.
Firmware 2.1.1 has a known bug, which causes the web interface to lose response if the number of programs is 3, 6, or any multiples of 3. So the first question is: do you know how many programs you have added? If it’s a multiple of 3, I suggest that you upgrade to the latest firmware 2.1.2. Alternatively, if you don’t want to upgrade firmware yet, the workaround is to add an additional program and disable it. Let me know if this solves the problem.
Hi, sorry about my late reply. I have been on vacation the past week and have just come back and started reply to forum posts. You are right — the part numbers are 2EDG5.08-8P and 2EDG5.08-2P. We actually carry these in our store:
http://rayshobby.net/cart/2edg5-8p
http://rayshobby.net/cart/2edg5-2p
Looks like you found them on eBay. Good find.The OSPi user manual has a few more pictures which will probably give you a better idea:
http://rayshobby.net/docs/ospi14_manual.pdf
I would say it’s pretty difficult to fit anything larger than the nano-size dongle. However, you can always modify the case, using a dremel to open a cutout or something, to fit a larger dongle.Hi Pete, sorry to hear that you had to go through such trouble to figure out the problem. From your description, I just checked and realized that it’s partly our fault because the MOSFET is supposed to be a MMBT3904 transistor but we substituted it with a 2N7002 MOSFET without realizing that this particular version doesn’t have a pull-down resistor. We did test all VIN-GND and VCC-GND resistances of the partially assembled boards and did not find any issue. But given that now the weather is dry and static electricity is high, it may have caused yours to trigger the MOSFET. Anyways, it’s great that you find out the cause. Thanks.
1) Rich is probably the best person to answer this question. You are right that it looks like the github hasn’t been updated for a year.
2) You are right that the sprinklers_pi program relies on wiringPi library, which isn’t available for Beagle yet. Theoretically there is no reason it can’t be made available for Beagle, it just seems that no one has made the effort to do so. If you would like to share your code, you can make a fork and release it under your own github repository I think.As a side onte, I have been working on a common source for OpenSprinkler, and that will be able to run on both Arduino and Linux-based OpenSprinklers. It does not use wiringPi. Some details are explained here:
https://opensprinkler.com/forums/topic/what-is-the-status-of-zoneprogramming-in-ospi-comparable-to-the-arduino-version/#post-351503) The Google Calendar program is provided as a quick demo. When I was working on the Google Calendar demo, I thought it had a lot of potentials, because the calendar interface itself is a front-end, and it’s cross-platform. But then I realized it’s hard to integrate weather-based adjustment, and it loses many of the other features.
I am surprised that you are still able to use it, because last time I tried it didn’t work. I think Google has retired the v2 api, which is what the demo is based on. I haven’t yet figured out how to use the new api. But if you can still manage to get it running, please drop me a note and I’d be interested in knowing. Thanks.
My understanding is that the sprinklers_pi program does not allow running multiple zones in parallel. However, it supports master zone, which is a zone that turns on when other zones turn on. So you can configure the associated zone as a master zone, and this way it will turn on automatically when your mist sprinklers turn on.
Unfortunately it’s hard to get the best of both (well, this is usually the case). The reason the common source has to be based on C++ is that that’s what the Arduino code is based on. This way it will maximally share the code base, with the goal of making the two versions fully compatible. You will see that the code isn’t that difficult to understand and expand. However, C++ is not a scripting language after all, so it’s definitely not as flexible as Python. I am not sure if there is a easy way to enable run-time plug ins. Most likely you will have to add code and recompile the program. But it’s not that hard.
As Linux is a multitask system, you can certainly run other programs in parallel.
Regarding the heat dissipation and reliability, that’s a commonly asked question and is certainly a concern. I honestly havne’t tested it thourougly myself. The Arudino version requiers less power and you are right that it boots quickly. So that’s an advantage. Overall as I’ve said elsewhere on the forum, the Arduino version is focused on providing an out-of-box working solution, while the Pi version is for users who have experience with RPi and prefer its flexiblity and extendability.
I’ve recently started working on a common source for both the microcontroller and Linux-based (i.e. Pi and Beagle) OpenSprinklers. This is inspired by Rich Zimmerman’s sprinklers_pi program, which can be cross-compiled between AVR and RPi. The code is written in C/C++, and can compile in both avr-gcc and the standard gcc. In Linux it uses the standard socket programming to handle web requests. So in a sense it can run on any Linux system (other than the GPIO stuff which doesn’t exist in standard Linux).
Note that this will be a depature from Dan’s Python-based program. On the plus side, the common source will allow Arduino, Pi, and Beagle to run exactly the same code; on the down side, it’s less easy to extend and does not have the nice plug-in architecture that Dan and other users developed. I will try to make this available as soon as I can.
Ok, that’s pretty easy to do and we can add it to the next firmware update. Thanks for the suggestion.
We are planning to add support for using sunset/sunrise times (with +/- offsets) in a program from the next firmware release. The current firmware can already obtain and display sunset/sunrise times (and it’s made available so we can collect feedback on it and check if there are any major issues). Support to use them in a program will be added next.
Could you post a link to your mechanical relay with 24VAC coil? The question of 24VAC relay often comes up and I am curious which one you’ve got. Thanks.
OK, thanks for the update. Keep me posted about your findings. In the next firmware we will reduce the call frequency so that at least it won’t exceed the limit even in the worst case.
Yes, there is a time out. As I explained in the posts above: if a previous call is successfully received, the next call will be in 15 minutes; if a previous call is NOT successfully received within 30 seconds the next call will immediately issued. So as you can see, normally it should be every 15 minutes; but if it continues to fail it will be repeatedly called every 30 seconds.
I just thought about one possibility: because the server response may have been slow, and your additional network modules (which scan the incoming packets) can slow down it further, so if the overhead added up together exceeds 30 seconds every time, it will result in a call being issued every 30 seconds. I think this is the most feasible cause. For the server response part, we are already preparing to migrate the script to Amazon servers to reduce the load on our own server; also, I will modify the firmware to reduce the call frequency so that it won’t exceed the call limit even in the worst case.
Forgot to ask: is your OpenSprinkler using the default HTTP port 80 or have you changed the HTTP port?
I checked the log file on our server and it’s pretty clear that your weather query is being sent every 30 seconds, which happens when the controller does not receive the last call result. That’s why I was asking if the sunrise/sunset time is correct, because if that’s not correct, the controller is clearly not receiving the call result, and hence repeatedly call again every 30 second. If the call is received correctly, the next call should be in 15 minutes.
We can change the firmware to reduce the call frequency upon failure. Unfortunately this doesn’t really fix the issue in your case because the root cause of issue is your controller is for some reason not receiving the call result, which is quite strange.
