Forum Replies Created
-
Posts
-
Yes, you can host the weather script on other servers, or a local server on your network. The firmware currently doesn’t support changing the weather script path in the UI (this will be added in the next version). But you can also re-compile the firmware to change the weather script path.
One possibility is that the firmware sends requests periodically to query weather, and it’s possible that the incoming packets from the weather script are being blocked by your network. Not sure what the cause is, but I’ve seen one or two cases in the past that this happens, and the controller stops responding while waiting for weather result. However, it will become responsible again when the call expires.
What kind of solenoid valves do you plan to use? OpenSprinkler is designed to work with 24V AC solenoid valves. If your heating solenoid valves are compatible, you can use it directly. Otherwise you may need some hardware modification.
800mA per zone is reaching the limit of the triac. You should use a relay to drive your LED if it consumes that much current. Also, if you drive LED with AC power, keep in mind you will get flickring (roughly 30Hz). This may or may not be an issue depending on your application. 6A supply is fine — the current rating just means the power supply is capable at outputting 6A while still maintaining 24V AC voltage.
You may be over-thinking about the difficulty: the way I described involves changing less than 10 lines of code.
To make sure we are on the same page: did you try DHCP at office? If not, is it because your office network does not offer DHCP? The arrow displayed on the LCD means the controller is trying to reach the gateway. If it takes more than half a second, that means it can’t reach the gateway. So the first thing to check is whether the gateway IP is indeed correct. If you’ve used DHCP, you shouldn’t need to bother with it since the gateway IP would be automatically obtained through DHCP.
@rongross: while OpenSprinkler Pi and Beagle would be able to make weather queries directly, the microcontroller-based OpenSprinkler is not powerful enough to parse the queries directly, due to the difficulty of processing complex XML data. Therefore it’s necessary to relay it through a cloud server (you can use your own server if needed). Basically the server parses the XML data and reduces it to a few simple numbers and return it to OpenSprinkler.
It’s actually not that difficult to modify the unified firmware to support relay board. I assume what you mean is that each station is controlled by an individual GPIO pin. I believe the following two functions need to be changed:
– in OpenSprinkler.cpp, function apply_all_station_bits(): this is where the station status bits are pushed to the shift register on OpenSprinkler. Change this to assigning status to each station GPIO pin instead.
– in OpenSprinkler.cpp, function begin(): this is where you need to initialize the GPIO pins. So change the first 6 lines (configure shift register) to configure your GPIO pins.The log doesn’t keep track of network events/issues. One thing we know for sure is that when using static IP, the firmware assumes the netmask is 255.255.255.0, so it doesn’t give you the option to change netmask. This can be easily fixed. I wanted to ask you about the netmask of your office network, in order to confirm whether this is indeed the cause of the issue.
On the other hand, the DHCP should work — i.e. if you try the controller at office with DHCP, does it still not work?
The announcement has explained it:
“The purpose of this is to make a fully consistent firmware for OS, OSPi and OSBo. The program is written in C++, so it’s not as modification-friendly compared to Dan’s Python-based interval_program. Also, there is no plugin architecture currently. However, as I said, the primary goal of this is to make OSPi and OSBo’s firmware maximally compatible with OS, so that any new features introduced in OS will also be simultaneously available to OSPi and OSBo.”OK, I see. Well, that’s not something the firmware supports currently — because it’s focused on sprinkler programs, it currently only supports ‘start a program at some specific time’, run for a specific amount of time, and then stop. It’s kind of like calendar events — each event has a start time, and fixed duration.
What you want to achieve (turn lights on from dusk to dawn) is somewhat different in that the duration varies and it requires introducing an ‘end time’ . There is no reason why it can’t be supported, but it does require changing the program data structure. I will think about how to add this support.
What do you mean by ‘end program feature’ — the end time has already been removed since firmware 2.1.0. Can you clarify what you mean?
Samer saw your post, and brought it to my attention that the firmware code does not handle netmasks other than 255.255.255.0. Are you using DHCP or static IP? I know for sure that the static IP option does not give you a way to modify netmasks, which is very likely the cause of the issue you’ve seen. However, I assume the DHCP library we are using should handle that automatically. Do you know if your office network use a netmask other than 255.255.255.0?
Can you use a multimeter to measure the resistance of each valve? It should be between 25 to 50 ohm. If it’s too low, chances are that your solenoid may be shorted somewhere. There is a non-zero chance that the triac may be damaged due to solenoid shorting, but the triac is very easy to replace. I suggest that you send an email to [email protected] to arrange for further support. Thanks.
It can, especially if you use the iPhone or iPad app. However, do keep in mind that without Internet the controller cannot query the weather script and sunrise/sunset times.
To source sprinkler solenoids in Australia, I suggest that you contact openlab.com.au — our distributor in Australia.
The first thing to check the status of the green and orange LEDs on the Ethernet jack. The green LED should be constant on, and orange LED blinking occasionally. If not, you should check whether you have soldered all pins on the Ethernet jack, and check whether you have plugged in the ENC28J60 chip correctly.
Rich’s sprinklers_pi program doesn’t work with our iOS app. I strongly recommend trying the unified firmware which got just released yesterday:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-3-for-avrrpibbblinux/
Most features available in the sprinklers_pi program are available in the unified firmware, and it’s supported by our iOS app.The main purpose of removing ospi.py is to make sure there is no port conflict on 8080. The error you encountered seems to suggest that ospi is not installed or not installed in the way officially documented. You can simply open a browser and type http://ospi:8080 where ospi is your Pi’s IP address. If nothing shows up, that means nothing is occupying port 8080, and you can just proceed to install the unified firmware.
FW 2.1.3 has been announced in this thread:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-3-for-avrrpibbblinux/
thanks.This looks like a mechanical sprinkler controller, which I’ve never seen to be honest. My guess is that the 240V AC output is connected to a pump. I am curios how many zones do you have? The only manual I can find is this one:
http://lib.store.yahoo.net/lib/kingpumps/LEG-CTL-R88169101C-Intermatic-Manual.pdf
which doesn’t tell much.Most sprinkler solenoid these days work with 24V AC (note: NOT 240V AC!). That’s also what most sprinkler controllers work with. If you have a 240V AC pump, you can use a ‘pump start relay’, which you can think of as a sprinkler solenoid, except it’s used to switch a 240V AC pump.
To understand your situation: how many zones do you have? Do you have a pump?
My goal is to announce it this weekend. It has been a very hectic week, and I didn’t have time to work on it during the weekdays. Sorry about that.
I understand what you want to achieve: run programs back to back, and also allow for varying program run times (due to weather adjustment). There is not a simple way to achieve this currently, due to the way the firmware handles station runs.
Fundamentally, this is due to the fact that the firmware is centered around ‘stations’ and not ‘programs’. Conceptually the OpenSprinkler does not treat a program as an entity, so the concept of ‘queuing’ a program does not apply here. Rather, it treats each station as an entity. The reason it’s done this way is to accommodate both sequential and parallel stations. The firmware gives each station one run-time slot. If the slot is non-empty, it does not allow additional schedule to overwrite that slot. That’s why if a station is already scheduled while it’s being requested to run again, it can’t achieve that.
The main point to compare with Pro-C’s features is to explain that the limitations come from prioritizing the limited resources towards different goals. Pro-C allows only up to 16 stations, 3 programs, and 4 start times; while OpenSprinkler allows up to 48 stations, 14 programs, unlimited start times. On top of that, OpenSprinkler allows both sequential and parallel stations, allows individually setting each station to ignore rain, to activate a master station. As a result, the concept of ‘queuing programs’ does not apply here. I chose to implement the scheduling algorithm and data structures in a different way to accommodate the capabilities.
Firmwware 2.1.0’s preview has a bug itself — I am pretty sure that overlapping programs will be ignored by the firmware. Firmware 2.1.2 is the first that can actually handle overlapping programs to some extent, albeit with the limitation that it can’t handle overlapping stations.
Regarding the extreme case I brought up “repeat every 1 minute, for 100 times, and the program takes 60 minutes to run” — I don’t expect the sprinkler controller to be able to handle unlimited cases like this — it has to cut off somewhere. There may be other programs that are scheduled while the 100 runs are going on, so if you think about having a stack, that is going to overflow at some point if you don’t have any limit of such repeating schedules. On the microcontroller the resources are very limited — it’s not like a Raspberry Pi that has fairly large amount of RAM and virtual memory system. It will have to set a cutoff point somewhere, and decide that it can’t accommodate additional runs until some existing ones complete.
My main point here is that different high-level goals impose different limitations. I will think about how to solve the issue — for example, by having a station queue that allows the same station to appear multiple times in the queue, as opposed to reserving one and only one slot for each station. I think this can absolutely solve the issue that you have encountered. Still, the queue will have a limited size, so if there are too many station runs being requested, it will have to still abandon additional station runs until some slots are freed up in the queue. It will always have to cut off somewhere.
For the sake of comparison: here are some details from the Pro-C feature list:
http://www.hunterindustries.com/irrigation-product/controllers/pro-crIndependent irrigation programs: 3
Start times per program: 4So we are talking about 3 different programs on Pro-C vs. 14 on OpenSprinkler; 4 start times per program on Pro-C vs. unlimited (practically limited by the number of minutes per day) start times on OpenSprinkler.
I am not sure what you mean by ‘Corrupt’ a program. The program is not being corrupted at all. Firmware 2.1.0 and 2.1.2 have use different implementations. Specifically, firmware 2.1.0 will ignore overlapping programs — if a program is still running when a new program is scheduled to start, the new program will be ignored. In firmware 2.1.2, it can stack programs except stations that are already in the queue to run. For example, if program 2 is trying to start while program 1 is running, all stations that have finished running program 1 will be scheduled. However, if a station is running or in the queue to run while the same station is being requested to run by program 2, that station cannot be scheduled.
I don’t know how Pro-C automatically stacks programs, but I consider this a non-trivial problem. The reason is that you can set the repeat cycle so small that it causes the program to stack forever. For example, if you request the program to repeat every 1 minute, for 100 times, and the program takes 60 minutes to run, what do you expect to happen? I don’t think Pro-C even supports such flexible repeating programs. Also, OpenSprinkler supports up to 14 different programs. With this level of capability, it needs to conserve resources.
If you set your program to repeat every 47 minutes, it WILL run immediately after the previous run finishes.
Regarding your first question: the preview is showing the correct run sequence. The issue is that your program takes 47 minutes to run, but your repeat cycle is set to 45 minutes. That means it’s trying to schedule the program again while the first run is still running. Therefore some stations cannot be rescheduled because it conflicts with the first run. You should set the repeat cycle time to at least 47 minutes.
Regarding your second question: it has always been our intention to have preview accurately reflect what the controller does. However, since these are two different programs — the controller runs firmware, and the preview is written in Javascript, there are inevitably some differences. When bugs are introduced, that will cause the preview to have different prediction than what the controller actually does.
