Forum Replies Created
-
Posts
-
Are you running Dan’s interval program or Rich’s sprinklers_pi program? Rich’s program disables the station output by default, I think, and you need to go to settings to enable it first.
OK, I’ve received several requests to get OpenSprinkler WaterSense certified. I will be looking into it. Thanks for the suggestion.
Because OpenSprinkler has a USB port which can supply 5V to power an external device, you can actually use this adapter:
http://rayshobby.net/cart/accessories/acc-usb/usb-fa-mb
to power TP-Link from OpenSprinkler’s USB port.A separate 24V to 5V step-down converter is also fine.
The first thing to check is the fuse — it’s a small cylinder tube shaped fuse. Check if it’s blown. You said the LED lights up, so the fuse is likely still ok. Next thing to check is to see if there is any visible component damage on the circuit board.
Forgot to mention, another thing useful for us to debug is if you can go to the sidebar, and use Export Configuration to export your controller data to a file or plain text. You can post it here or if there is any sensitive information, you can submit it as a support ticket to us.
Actually I was wrong about firmware 2.1.0 — it already supports the new program structure (hence you don’t see the End Time parameter which used to be in the old type of program structure). So you don’t need to set ‘Repeat Every’ at all.
I’m not exactly sure why you are getting the ‘Check input and try again’ error. It sounds like the controller returned an error code when saving the program. Just to be able to recreate the issue, can you tell me what’s the water time you’ve set for each station?
Check the program’s interval time — it should not be zero. If you just want the program to run once during a day, you can use a large interval (such as 23 hours). As long as the end time minus the start time is less than the interval time, the program will run only once (at the start time).
From firmware 2.1.2, the settings for each program has been changed to one start time, and additional start times. This avoids the confusing ‘end time’ in prior firmwares.
No it doesn’t require firmware update — it’s a bug in the preview scripts on the server. We’ve already worked out the fix and it should be released very soon. Samer can probably give you a better idea of exactly when.
Just to summarize this thread and the relevant thread from the support ticket: the issue is caused by the preview scripts not properly handling programs that repeat too frequently. Here ‘too frequently’ means the program is set to repeat at an interval that’s less than the time it takes to finish the program. For example, if a program takes 30 minutes to finish watering all stations, the interval to repeat this program should be more than 30 minutes. If the interval is less than 30 minutes, it’s trying to reschedule the program before it can finish the first pass. In this case the firmware can handle it correctly (i.e. meeting the sequential requirement); but the preview scripts are not completely consistent with the the firmware, and show stations running in parallel.
In any case, the preview issue is fixed and will be updated soon. We will also soon add a checking of the program interval setting to throw out a warning if the interval is set too short.
There are some wireless valves on the market already, such as Orbit’s wireless valve:
https://www.orbitonline.com/products/hose-watering/timers/hose-faucet-timers/1-dial-1-outlet-digital-timer/1-dial-1-outlet-iristm-hose-faucet-timer-with-brass-swivel
which requires an Iris controller hub. Technically due to the requirement of power efficiency, these wireless valves do not have built-in WiFi, but instead have Zigbee or Zwave inside. That’s why they require a hub in order to connect to the Internet.I was thinking of developing something similar, but power efficiency is a challenge and the requirement of a hub is also a hassle. However, if you are OK with the valve being powered from an adapter (instead of a battery), that should be fairly easy to solve.
The R3000 is adopted because we have a lot of these in stock, and also because it’s a diode that has a 3~4 V forward voltage drop (as opposed to 0.7V on standard diode). Other than that, you can use standard diodes such as 1N4007.
The TVS should be at least 43CA or above — it needs to be larger than the highest voltage under normal operating situations. Because a 24V AC source often has a no-load voltage of up to 30V AC, and that has an instantaneous voltage of up to 30 * 1.414 = 42.4V, you need TVS that’s rated at least 43V or above. So 51CA is fine, but 33CA or 36CA is not.
Z0109MN for triac is fine. You can use it to replace BT1308W. Because the way OpenSprinkler works is that it holds the gate on constantly to keep the triac open, the 4Q triggering is not an issue for OpenSprinkler.
There are actually two zener diodes — one power zener connected in series to R3000 and the purpose of it is to further drop the voltage by another 2~3V (because MC34063 has a maximum input voltage of 40V, I try to keep the input voltage safely below that limit). The other is connected to the 5V rail after the PTC fuse. The second zener is 5.6V, and is used to protect the 5V line (in case of shorting).
I will post an image of the smt version when I get time to take a picture.
Wiring multiple transmitters will not help. However, you can extend the transmission range by 1) use an antenna of the appropriate length (17cm or 6.7inch, which is 1/4 of wavelength for 433MHz) and/or 2) use a higher voltage to drive the transmitter. On OpenSprinkler, the VCC pin of the transmitter is wired to 5V. The transmitter actually has an operating voltage of up to 12V. So if you need to maximize the range, you can connect the VCC pin of the transmitter to a 12V source — unfortunately there is no 12V source inside OpenSprinkler, so you would need to use a separate 12V power source if you do that.
I would suggest starting with tip 1) — you can also extend the antenna further to 1/2 wavelength. The transmission range might be sufficient without having to bump up the voltage.
Hi Mike, there is not a sub-forum for the microcontroller-based OpenSprinkler, because the root of the forum is supposed to be for microcontroller-based OpenSprinkler (so there are sub-forums for hardware / firmware questions). There are, on the other hand, sub-forums for OSPi and OSBo.
“Device signature = 0x000000” often occurs when the USBtinyISP programmer fails to communicate with the microcontroller properly. This could be because the fuse bits have been changed for some unknown reason. Given the situation, I think the best solution is for you to mail it back to us so we can check the issue for you. You can send an email to [email protected] to arrange for return.
Another way to update firmware is to do it in command line:
Step 1. Install WinAVR: http://sourceforge.net/projects/winavr/files/WinAVR/20100110/
Step 2. Open a command line window, cd to where your osFWUpdater is, and cd further to Firmwares\OpenSprinkler_v2.0
Step 3. Run command
avrdude -c usbtiny -p m644p -F -B 1 -U flash:w:firmware2.1.2.hexOf course the pre-assumption is that the device has to show up as USBtiny (or USBtinySPI) in Windows — if it shows up as unknown, it won’t work.
It occurred to me that perhaps the issue is because you have both Zadig and Adafruit’s USBintyISP driver installed at the same time? I’ve never tried installed both at the same time, but that might be the source of problem. I suggest uninstall one of them if you have both installed.
You said “Even though it’s a 2.0 controller if I replug it in with the b2 it shows up as libusb-win32-USBtinyISP in device manager” — I really have no idea and cannot explain this at all — if it’s 2.0 you don’t need to press b2; the only version that needs pressing b2 is OpenSprinkler 2.1
I also don’t understand when you said ‘zadig shows USBtinyISP and device manager shows libusb-win32 devices and USBtinyISP .If i plug the controller into the pc device manager shows unknown device’ — did you actually finish installing zadig driver or did you just see it’s listed there and didn’t complete the installation?
If this is 2.0 you should not need to press and button like B2.
log.txt is in the folder where you unpacked osFWUpdater.
If zadig shows USBtinyISP then it means it has detected your device, What does Windows Device Manager say? Does it show as unknown device or does it show as libusb-win32?
Update firmware on OS2.0 takes quite a while (often up to several minutes), so make sure you keep it plugged in until the update completes. I have no idea why after update it shows up as unknown device again — maybe try a different USB port, or perhaps it’s the problem with the USB cable?
The diagonal arrow means the controller is trying to ping the router. If it stays for more than a brief moment, that means it can’t ping the router. Firmware 2.0.9 does the same, so I can’t think of a reason why they produce different results. Also, the diagonal arrow shouldn’t stay on forever — each ping has a time out and the arrow should not display more than the time out (a couple of seconds).
OK, this is likely a bug in the preview script. We will try to fix as soon as possible. Thanks for reporting it.
Well, the NTP address can potentially affect the response, especially if the controller can’t reach the NTP server and will have to periodically re-check the NTP server. I suggest leaving all options at their default values (i.e. use DHCP, don’t change NTP), and see if it’s still unstable.
Regarding MAC address: prior to OS 2.2, there is no MAC chip on the controller so the MAC address is software defined. To distinguish multiple controllers on the same network, the Device ID is used to differentiate the last byte of the MAC. Since OS 2.2, an ID chip is added so that each one has different MAC address.
First, plug in USB cable to OpenSprinkler, and go to your Device Manager to see if there is a USBtinyISP device (assuming you have OpenSprinkler 2.0 as you described), or any unknown device. Next, if Zadig doesn’t work, you can directly install the USBtinyISp driver:
https://learn.adafruit.com/usbtinyisp/driversThis is not an issue I am aware of. I have a testing OS 2.1 and I have just flashed firmware 2.1.2 to it, tested for 5 minutes on different devices (laptops, phone app, pads) and I didn’t find any issue. Just to make sure: after upgrading to firmware 2.1.2, did you change any settings/options, or did import? If so, what settings/options did you change?
Are you still getting the emails from Wunderground? Two days ago we found that our weather script is taking a significant amount of time to obtain sunrise/sunset time from openweathermap.org, so we immediately changed the script to use Python to directly calculate sunrise/sunset times. Although this is not directly related to Wunderground, if the script takes a long time to return, it can cause the controller to resend another request, and thus exceeding the call limit. I hopefully our fix to the weather script has eliminated the exceeding call limit problem.
