Forum Replies Created
-
Posts
-
Unlike other analog sensors, DHT22 requires only a digital pin (and on OpenSprinkler all analog pins can be used as digital pins as well). Adafruit has a tutorial on it:
https://learn.adafruit.com/dht
Basically you just need VCC, GND, and any spare pin to connect to DHT22. You do have to modify the firmware to read the value from DHT22. You can also display it to the LCD.If you prefer using other sensors, like the MCP9700 analog sensor, you can use any of the spare analog pins.
Yes, I saw this article a couple of days ago. It’s great that Ars blogged about it. I wish the wiring in the picture could look more elegant 🙂
I see, so you want the run-once to preserve the program repeat settings. There is currently no easy way to get around it — run-once works differently from a normal program, and as its name suggests, run-once is just an one-off program that does not repeat. For a repeat schedule to work, it has to be set as a normal program. At the moment you will have to keep using your current way: change the program start time.
That’s interesting. I think there was a previous report that the Zadig driver somehow hindered Windows to find the correct driver for the USB-serial chip on OS 2.2. I don’t understand how this can happen, but I should see if I can reproduce the same issue. Glad that you figured it out.
If you just purchased recently (from us or from MicroCenter?) it must be 2.2. You do not need Zadig driver — in fact, I would recommend uninstalling Zadig driver if you can. As I said, 2.2 does not require driver on most Windows versions (except Windows XP).
Do you have another computer, possible a different operating system, that you can try it on?
“but i have to set it on a schedule to work” — can you specify the schedule? Do you need the repeat time to be below 1 minute?
Try this:
avrdude -c usbtiny -p m644p -U lfuse:w:0xFF:m -U hfuse:w:0xD6:m -U efuse:w:0xFF:m
A blank ATmega chip is set to run on internal 1MHz clock. The above sets the fuse bits to use external crystal clock. Since you don’t have CH340G yet, you don’t need to flash the bootloader.If you have purchased recently, chances are that you have 2.2. Is this a DIY kit, or fully assembled? If it’s DIY, the instructions you followed indicate the version number. Note that both 2.1 and 2.2 use orange terminal block. Only 2.1 requires entering bootloader; for 2.2 you just plug in USB cable and flash firmware directly (there is no need to enter bootloader). Also, 2.2 does not require driver in Windows and Linux (except if you are in Windows XP or using MacOSX, for which the driver can be downloaded following the firmware upgrade instructions).
Firmware 2.1.3 is pretty much ready to be released. The plan is to release it when Apple approves OpenSprinkler iOS app 1.2.9, which may take a few additional days. The reason is that the new app now supports md5-hashed password on firmware 2.1.3, so we need to make sure the app is available before the firmware is released. Right now the app has already been updated on most platforms except iOS.
As a quick heads-up, firmware 2.1.3 will be the first unified firmware that runs on all OpenSprinkler platforms, including the standard OS (microcontroller-based), OSPi, and OSBo. Feature-wise, it has added support to use sunrise/sunset times (with up to 4 hours of offset) in program start times. For example, you can define a program to start at sunrise + 30 minutes, or sunset – 45 minutes and so on. I will make an announcement with details when it’s officially released.
A quick update on this thread: the current preview script has a bug that only shows the first runtime of a station and ignore additional run times of the same station. The fix has been implemented and we will release a new version of the UI as soon as possible. Thanks, and sorry aobut the issue.
This is a preview script bug, we’ve just found the source of the problem (which was introduced when fixing a previous bug). It’s only a preview issue, and doesn’t affect how the controller runs the programs.
The preview fix will be released as soon as possible, thanks for your patience.
Wow, 1.4 has been discontinued a long time ago and I have to remind myself how the contrast works on this version. If I recall correctly, 1.4 uses a resistor voltage divider to create the voltage that controls contrast. It’s possible that you may have soldered the wrong resistor — according to the instructions (http://rayshobby.net/opensprinkler/svc-build/opensprinkler-v1-4-build-instructions/) RLED is a 100 ohm resistor. Please confirm this is the case. If you soldered a different resistor to RLED, that will create the wrong voltage for contrast.
Firmware 2.1.2 does not have the 3 program issue.
Let’s isolate the problems first. You reported that 1) you can’t connect to OpenSprinkler remotely; 2) the weather adjustment isn’t changing. For question 1, are you able to access it when you are at home? If yes, it sounds like OpenSprinkler cannot reach the Internet, and that will also explain why the weather adjustment isn’t changing. If you can’t access OpenSprinkler while you are at home either, it sounds like it can’t connect to your router. Click the first button (B1) to check if its IP address has changed.
OK, thanks for reporting this. So far I have been unsuccessful at acquiring an RPi 2. I will try to get one asap and test it.
The original bug reported in this thread has been fixed. Perhaps you can post your export so that we can check your program data and see what went wrong with the preview.
The best solution is probably to customize the weather script (it’s written in Python) and host it on your own server somewhere (it can even by a Raspberry Pi sitting at your home). But this does require re-compiling the firmware because the weather script location is currently hard coded and cannot be modified through the web interface.
Another workaround is to use two programs to simulate what you need: one program is set to start, say at 8am, with 6 minutes of water time (i.e. your minimum), set ‘use weather’ to ‘off’; the second program is set start after the first program finishes (e.g. 8:06), and 6 minutes of water time as well, but ‘use weather’ is enabled. The overall effect of the two programs is that you have a minimum of 6 minutes of water time, average of 12 minutes of water time (assuming watering percentage is 100%), and a maximum of 21 minutes of water time (6 + 6 * 250%).
Received your package. After checking, it turns out that the shift registers (all three — one on OSPi and two on expansion board) are all damaged. This is quite rare because the shift registers are usually very robust. I can’t think of a good reason, the fact that all three are damaged probably implies some sort of over-voltage situation. It’s also rare that the shift registers are damaged but the other components are fine (fuse, triac). When there is a shorted solenoid, the fuse may break, or triac may be damaged, but I’ve never seen shift registers damaged, particularly with no other components damaged.
My only suggestion is that when plugging in the expansion board, make sure to power off everything before connecting the expansion board. ‘Hot’ plugging in can be a potential issue. Anyways, I’ve replaced the shift registers and made sure both have passed functional test. It will be shipped back to you tomorrow. Thanks.
You can find a complete description of Zimmerman’s algorithm on the support document page, specifically this page:
https://opensprinkler.freshdesk.com/solution/categories/5000022938/folders/5000099525/articles/5000017312-using-weather-adjustments1) Zimmerman’s algorithm computes a watering percentage — a scaling factor that is multiplied with the user-set program water time. So it adjusts the duration and not frequency.
2) The baseline is set by the user — the user decides how long to water assuming average weather condition.
@wgtn28: Odd-day restriction skipping 31st and Feb 29th is a pretty standard practice — most sprinkler controllers that support odd day restriction do the same. The reason is that the day following the 31st (as well as Feb 29th) is another odd day, so this avoids watering two days in a roll.
Program not executing on Jan 29th is unusual. To make sure there is no other factor: are you using weather-based water time adjustment? Did you set your program to run on specific days of a week? I didn’t quite understand what you said here: “Odd programs set to run on the 29th day appear in the UI “Program Preview” page in advance before and after the 29th date, but once the current date is the 29th changes to “No stations set to run on this day.” and no watering is activated.”. Do you mean the Program Preview shows “No stations set to run on this day” or do you mean the Log shows “No stations ran on this day”? If the preview shows no stations set to run on this day, it would be either the weather-based adjustment set it to zero, or your programs are set to run only selected days of a week. Hope this makes sense.
OK, just saw your pull request. That’s great, thanks for making it work with the new Google Calendar API! I will check it out in a couple of days and merge your request. Thanks.
First, just to be sure we are on the same page: you have the Raspberry Pi-based OpenSprinkler (OSPi), is that right? You are posting this question under OSPi so I assume you have OSPi. If you have the fully-assembled, microcontroller-based OpenSprinkler, the first thing to check is whether your router has Internet connection. The reason is that the microcontorller-based OpenSprinkler references external Javascripts stored on remote servers. If your router does not have Internet connection, you can still use the OpenSprinkler mobile app (or Chrome app) to access it.
Speaking of protection: all OpenSprinklers have built-in fuse (two of them, one for 24V AC line, one for 5V line), zener diode, and per-stations transient voltage suppressor. We’ve integrated most protective components we can think of. Of course these won’t prevent all kinds of damages, but I don’t think the circuit protection is any worse than other commercial controllers on the market.
Adding sensor control is often easily said than done. Because there are many different types of sensors, their outputs vary significantly, and there are different ways to determine how each sensor should affect the sprinkler programs, it’s hard to have a one for all solution. If you have a specific sensor in mind, it’s not too hard to wire it to OpenSprinkler, and modify the code to add custom control tailored to your specific application. Part of the reason OpenSprinkler is open-source is to give users the flexibility to customize.
