[Ray]

First, did you select to use Zimmerman method for weather adjustment? From your configuration files, the ‘uwt’ option is 0, which means it’s set to use manual adjustment.

Second, I tried your location (zip code 80538) and as of today the watering adjustment is indeed 0%. You have an average of 50% humidity, and your temperature is 48 F. According to Zimmerman’s algorithm, the watering percentage is 0. So I guess today’s weather is not a good test case.

[Ray]

@gary, this is already discussed here:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-3-for-avrrpibbblinux/
basically, setting an ‘end time’ to a program is not supported at the moment, but we will consider it for future firmware upgrades.

[Ray]

1. This is similar to adding per-station note, which someone mentioned on the forum previously. Ideally this should be stored in EEPROM space on the controller (along with other station attributes), but because the EEPROM space is pretty limited, it might be better to store this information in the app and not on the controller.

2. Display controller name in the main screen: this should be easy to do.

3. Hide unused zones: this is already supported. You can disable a station and when disabled, the station will not be shown.

4. Access levels: this is harder to achieve, especially on the microcontroller-based OpenSprinkler, which does not run a Linux system.

5. Per-zone query: this is fairly easy to do and is mainly a UI change.

6 and 7: geolocation — these are pretty difficult to implement. Well, first, if you don’t allow remote access all together, then already users can only access the controller when they are within your WiFi range, so it sort of does what you need already. Otherwise, limiting access based on geolocation is pretty difficult, because one can always send fake GPS location to fool the controller, and I don’t see an easy way to prevent that.

[Ray]

You are right that the current firmware support up to 14 programs. Because programs must be stored in non-volatile memory (EEPROM) space, and there is only a limited amount of EEPROM on the microcontroller (2K bytes), it has to be limited. Earlier firmwares (2.0.9 and prior) do not support individual water time per station within a program, hence they allow a large number of programs. The current firmware supports individual water time per stations within a program, therefore the number of programs is significantly lower. Still, for most users 14 programs are well above sufficient.

If you are not using all 48 stations, one immediately solution you can use is to modify the firmware code to limit the number of stations. Specifically, change the MAX_EXT_BOARDS:
https://github.com/OpenSprinkler/OpenSprinklerGen2/blob/master/defines.h#L37
to fit exactly the number you need. For example, if you only have 24 stations, change MAX_EXT_BOARDS to 2 (e.g. for a total of (1+2)*8 = 24 stations). This will halve the data per program, and consequently should allow almost twice as many programs. This does require you to compile the firmware code, but will definitely allow you to use more programs.

[Ray]

@munnecke, the link you included seems to be a page that doesn’t exist. Are you referring to this meter:
http://www.amazon.com/Dwyer%C2%AE-Multi-Jet-Pulsed-Output–C-03-1/dp/B00D2ME5MC
I was actually thinking of buying this meter a while back but it was out of stock. Just found that it’s still available so I will be getting my hand on one to try out.

[Ray]

Well, since you are using your own hardware, it’s difficult for me to help you diagnose. I think the issue boils down to activating your relay board — you can write a very simple program to test if each GPIO pin can activate the relay board. If this works, then it’s just the matter of plugging in this code to the OpenSprinkler firmware code, the rest of the firmware code should work as is.

[Ray]

I think we need the precise definition of what counts as ‘it has rained’ — like in terms of the amount of precipitation, what’s the threshold? Once we know the quantitative measure, we can modify the Zimmerman method to implement a hard constraint.

[Ray]

The firmware does not limit the number of parallel stations — the limit depends on the current rating of your sprinkler transformer. Just to give you an idea: each solenoid, when open, draws about 180 to 250mA of current. So if your sprinkler transformer is 750mA, you can most likely run 4 valves at the same time — in practice it can be more, because as more valves are open, the total current draw increases, which drives down the output voltage of the transformer (AC transformers are un-regulated), thus the current per station reduces, and consequently more valves can open. I did some tests a while back, with a 750mA transformer I can open 8 valves at the same time.

[Ray]

So are you suggesting that we create ‘virtual stations’ and they are by default parallel? We can certainly do that but I don’t see how it’s fundamentally different from the current ‘sequential’ attribute. You can think of a ‘sequential’ station as a ‘virtual station’.

[Ray]

The most likely reason I can think of is the controller is not getting weather data correctly (the weather data you see in the app are data directly from WUnderground website, and do not necessarily represent what the controller receives). Are you setting OpenSprinkler to use static IP? If so, please make sure you also set the correct router (i.e. gateway) IP, otherwise the controller cannot receive data from weather website. We strongly recommend keep OpenSprinkler in DHCP mode, and use the router’s DHCP reservation feature to set a fixed IP to OpenSprinkler.

[Ray]

The valve you linked to is a DC latching solenoid valve, which does not work with the standard OpenSprinkler. The only product we have that works with latching solenoid is the OpenSprinkler Bee Sheild for Arduino, but it’s not a standalone product:
http://rayshobby.net/cart/osbeeshield

Latching valves are common in battery powered controllers. However, my understanding is that 24VAC valves are more common in sprinkler systems. Unless if you already own latching valves, you should as well get 24VAC valves, which are about the same price:
http://www.homedepot.com/p/Orbit-3-4-in-FPT-Auto-Inline-NFC-Valve-57100/100025518

[Ray]

The way the current firmware works is that when a program is scheduled, it calculates the start times of all stations involved in the program. If a station is manually turned off, it doesn’t automatically move stations upwards. This behavior can certainly be changed by modifying the code, but it’s unclear to me whether the user wants to move the stations immediately upward or not. So all scheduled stations remain in their originally planned start time. We can add an option in the future, where when manually turning off a station, the user is prompted with the option of moving all other schedules upward or not.

Also, because there is no queuing structure, each station is only allowed one schedule at any given time. If the station hasn’t finished running, requests to run the station again will be ignored (unless if you manually turn off that station first, then you can schedule a new run time).

This can be solved by using a run-time queue, which should be fairly easy to implement. It’s already on my todo list.

[Ray]

The ‘parallel stations’ are mainly intended for non-sprinkler stations — now that OpenSprinkler supports radio frequency (RF) stations (such as remote power sockets), you can use it to switch landscape lights, or other general-purpose powerline devices with OpenSprinkler. Obviously these stations should not be serialized with sprinkler stations, and should be allows to run in parallel. So the ‘sequential’ station attribute is configurable mainly for that purpose.

[Ray]

Sorry, the DIY kit is permanently discontinued. Micro Center still has some available stock (even through the website says 2.1 what they have is version 2.2):
http://www.microcenter.com/

[Ray]

I am not sure what you mean by run all programs. Do you mean run each program one after another? Or do you mean run each station one after another? To run all stations (such as testing stations) you can use the Run-Once Program feature. Certainly you can also create a program that activates all stations.

[Ray]

Sorry to chime in late. @Rob, to briefly answer your questions:

1) As Alan said, most residential sprinkler valves (particularly underground sprinkler system) are 24VAC type. Latching type is more common in battery powered controllers as it’s more power efficient. The simplest way to tell them apart is: 24VAC valves have two wires that have the same color; latching valve usually have a red wire and a black wire (since it’s polarized). The only product that we sell that can work with latching solenoids is the OSBee Arduino Shield:
http://rayshobby.net/cart/osbeeshield/
the video has a good explanation of 24VAC vs. latching valves.

2) AC adapters are usually unregulated. 24VAC means the output voltage is 24V when it’s at the rated current draw (say 500mA or 750mA). At no load or light load, the output voltage is typically higher than 24.

3) It’s hard to tell which RPi is better, I would think the newer models (like A+/B+) are better, but I don’t have any experimental data myself.

4) 24VAC valves (since they are non-latching) will simply turn off when power is gone — they require power to remain activated.

5) The following wiki page has instructions on watchdog timer;
http://rayshobby.net/mediawiki/index.php/Set_Up_RPi,_RTC,_WiFi,_Data_Log#Hardware_watchdog
If you use the pre-configured SD card image, I believe it has configured watchdog timer.

[Ray]

Is your OpenSprinkler connected to router through wired connection or WiFi adapter? If WiFi adapter, I suggest that you try wired connection and see if that reduces packet loss and latency. If so, it’s probably a WiFi related issue.

[Ray]

If you use static IP, we strongly recommend using the router’s DHCP reservation to manage static IP, and do NOT set static IP on OpenSprinkler. The reason is that users often set a static IP on OpenSprinkler, but forget to set the correct gateway (i.e. router’s) IP, resulting in OpenSprinkler not able to reach the weather website. Using router’s DHCP reservation can easily avoid such issues. We’ve just released a new video tutorial that goes through DHCP reservation and port forwarding:
https://opensprinkler.freshdesk.com/solution/categories/5000022938/folders/5000099521/articles/5000569763-video-how-to-set-up-port-forwarding-for-remote-access

[Ray]

There are two common issues with upgrading 2.1:
1. If the button is pressed too long, Windows will think the device has lost response. So make sure the button is released within 1-2 seconds after the USB cable is plugged in (this has been mentioned in the instructions).
2. If you click on ‘Auto Detect’, the controller will exist the bootloading mode, so before clicking on ‘Upload Firmware’ please enter bootloading mode again. In fact, if you already know you have OS 2.1, you can directly select it from the dropdown list, and there is no need to do ‘Auto Detect’. Auto detect is only there for users who don’t remember which hardware version they have.

Hope this helps.

[Ray]

That really depends on RPi — what’s the highest frequency of interrupt its pins can handle. I assume it should handle at least a few kilo-hertz.

[Ray]

Well, the Unified Firmware for OSPi is currently in Beta testing stage (as I mentioned in the post). So there is very minimal documentation at the moment. The goal is that as soon as it becomes stable, and potential bugs are fixed, we will make a pre-configured SD card so that users can just burn and use it right away. These have all been described in the original post about the Unified Firmware. Thanks.

[Ray]

Adding a short sleep has very little impact on the accuracy of running times — because the running times are all controlled by timer values (each station is given a start time and stop time, both of which are system times), the delay will not add up to affect the running time.

[Ray]

That’s a very good point, I haven’t thought about it — for the initial implementation I focused on getting the firmware compatible with OS, but I haven’t thought about making it more efficient for RPi. Right now the inner loop uses nonblocking socket, and repeatedly checks schedule data and so on. Although the GPIO pins are only read/write once every second, the busy poll of the loop is probably consuming the entire CPU. One solution is to add a short sleep at the end of the loop to give the CPU some spare time. A more ideal solution is probably to make the algorithm event driven or interrupt driven. I will do a few tests this weekend, in the meantime, feel free to experiment with it and post your findings. Thanks.

[Ray]

Note that after you click on ‘Detect Device’, the controller will exit bootloading mode, therefore you will need to re-enter bootloading mode before clicking on ‘Upload Firmware’. If you already know your OpenSprinkler hardware version (2.1 according to you), there is no need to click on ‘Detect Device’ — you can simply select the hardware version from the dropdown list — the ‘Detect Device’ feature is really meant for users who don’t know or forgot which version they have.

[Ray]

While OS should be able to drive a WiFi adapter, this is not tested rigorously, and it depends on how much current the adapter actually draws in practice. When WiFi signal is good, this may work fine, but when WiFi signal is poor, the adapter draws more power and this may exceed the capability of OS. So my suggestion is to still use the WiFi adapter’s own power supply.

[Author]

Posts