Forum Replies Created
-
Posts
-
OK, both match my output. I then changed the location to “Darwin,Australia” and after a minute or two, the “wl” changed to 122. You can try it and if you still see 19, I suspect there is a caching issue somewhere — in other words, the controller sends out a query with the new location, but instead of reaching the server, that query may be immediately returned by your router or some intermediate server with cached results. This is really very rare but it’s the only thing I can think of.
To make sure this is not your browser cache the result, can you try the following url:
http://x.x.x.x/jo?pw=your_os_password
where x.x.x.x is your OpenSprinkler’s IP address, and your_os_password is your OpenSprinkler’s password. Look for the variable named “wl”, and also the variable named “uwt”, what are their values?That’s the correct return.
So I repeated your experiment: setting time zone manually on the controller to +14:00, upon NTP syncing, it got the time of UTC+14:00, then after about 30 seconds it reset the time zone to UTC-5:00 and obtained the current time of UTC-5:00 (because the location is Boston,MA). I can’t reproduce the issue you reported, and I honestly don’t have a clue.
As I said in the post above, the only thin I can think of is maybe the access to weather.opensprinkler.com is blocked by your network. Can you open a browser and try this url:
http://weather.opensprinkler.com/weather0.py?loc=95050
what do you see as the return?Can I ask you why you are testing setting time zone manually? Are you doing this on the controller using buttons?
Here is quick question: after changing to ‘Darwin, Australia’, can you reboot the controller and see if the water percentage changes to something other than 19%?
I went into the menu at the controller and the time zone read -4:00. The menu had NTP “on” . The controller could not access the internet or even the local network so this time zone must be part of the code.
Of course the time zone has to have an initial value at factory default setting. It’s like when you re-install your computer, it has to have a default time zone, isn’t right? In this case, it’s set as -4:00 (which matches Boston,MA’s time zone in the summer). But it qucan be anything, and that doesn’t matter, because the time zone will be updated after you put in your location.
I really don’t understand why you are seeing the issue you are seeing. I can’t reproduce this issue, and I don’t see any other report of the same issue. The firmware queries a python script at http://weather.opensprinkler.com/weather0.py?loc=YOUR_LOCATION_STRING to obtain the time zone. So the only thing I can think of is maybe the connection between your OpenSprinkler and the Internet is blocked, that it can’t query the script. That’s the only thing I can think of.
Every time you change the location the controller needs 10 to 15 seconds (sometimes up to a minute) to obtain weather data and update the water percentage. So you won’t see the updated value immediately, but usually after a minute or two it should update.
I don’t believe it is getting the NTP sync but instead reading the correct time from the time zone. I suspect the time zone of -5:00 is coded into the firmware and since we are not in DST it reads the correct time for Boston regardless of it getting NTP. If I change the time zone to -8:00 it doesn’t read Boston time anymore, instead it reads Boston time -3 hours.
I am confused what you are saying here. From what I see, NTP syncing is now working on your OpenSprinkler, isn’t it?
The time zone is never hard-coded in the firmware — it’s stored as an option which you can change (although normally you shouldn’t need to because it’s automatically changed based on the time zone query).
It’s likely your OpenSprinkler’s IP address has changed. Just check its current IP address and update port forwarding accordingly.
There are two more related notes:
1. if there is any station currently running, NTP will pause until all stations have stopped. This is for the simple reason that time change while stations are running can mess up the run time, so the NTP sync will wait until no program is currently running.
2. if you want to manually set time zone, then leave the location string empty, as Samer said. if the location is valid, and a valid time zone based on your location is returned, your manually set time zone will be overwritten. Therefore if you want to keep the manually set time zone, just leave the location string empty.I still can’t get the source of the issue you are seeing, because I can’t reproduce the issue. My suggestion is to perform a system reset and check the time before you change any setting or import configuration. The default location is Boston, MA, so upon system reset, it should get the current time of Boston, MA. If it does, that means NTP sync is working correctly.
@sprinklesprinklelittlestar: the screw hole track issue is only on DIY 2.2 — in fact I just checked the PCB design, and the mistake was that the top/bottom keepouts (which prevents traces from running nearby) were slightly shifted from the screw hole, that’s why some PCB traces went too close to the screw hole. But assuming user ‘automate’ has the fully assembled OS 2.1, this is not an issue. In addition, all fully assembled OS have been tested and the initial time on OS is obtained from NTP.
@automate: if you change the time zone manually, that means either you didn’t turn on NTP flag, or you are changing this manually on the controller using buttons. Can you confirm?You said your location is ‘San Bernardino, 92410’, is this the exact string you put in to your location input box? I don’t think this is a location recognizable by the firmware, it should be either:
San Bernardino, CA
or
92410
I tried 92410 and it works on my OpenSprinkler.The firmware has never supported master valve operation on a per-program basis — it has always been on a per-valve basis. What you quoted is from an early post and that has never been implemented.
In any case, you can set master operation flag for each station/valve individually. Check the firmware tutorial video, or the user manual for details.
You are right that the master cannot be set to open before other valves. Usually turning on valve is not a problem, and the valve doesn’t require pressure to turn on. In fact, having the master valve on before other valves turn on can produce water throttling issues. Turning off valve, on the other hand, does require certain water pressure. This is how typical sprinkler valves work. If you do want to turn on master before other valves, here is a workaround:
1. create a dummy station, and make sure this is the first non-master station
2. set the dummy station to activate master
3. in your program, set the dummy station to run for whatever time you need
Since the dummy station doesn’t actually turn on any valve, this basically achieves turning on master before any (real) valve turns on.As I just replied in another thread: Auto-DST detection is a feature only recently introduced in Firmware 2.1.0. If your OpenSprinkler is running earlier firmware versions, you will need to manually change the time zone to accommodate DST changes. So if your OpenSprinkler is not running firmware 2.1.0, I recommend upgrading to 2.1.0 now.
To make sure I understand the issue: are you using Firmware 2.1.0? Auto-DST detection is only made available in Firmware 2.1.0. If you have earlier firmware versions, you will need to manually change the time zone to adjust the time. To check firmware version, in the web UI, click on the icon at the upper-left corner to bring out the sidebar, then click on About. It will show you the firmware version.
The pre-configured image has built-in driver for several common WiFi dongles, including the Edimax one. I suggest using the unmodified image first, if everything works fine, then try updating. That way you know which step is likely to have caused the issue. Also, I would leave the dongle in RPi’s USB port directly, unless if this leads to brown-out issue.
What’s your location? I tried several cities that I can think of in California and they all returned the correct time.
OK, I will investigate the problem right away. I suspect it has to do with either SD card write speed, or the fact that firmware 2.1.0 writes log files in to a subfolder (/LOGS) whereas previous firmwares write into the root directory.
I assume you are using the pre-configued SD card image linked from the OSPi 1.4 user manual:
http://rayshobby.net/docs/ospi14_manual.pdfIf not, please try the pre-configured image first. Also. have you tried plugging the dongle directly to RPi’s USB port?
The only product we sell that can work with DC latching solenoids is the OpenSprinkler Bee Arduino Shield:
http://rayshobby.net/cart/osbeeshieldHowever, it’s a shield for Arduino and not a standalone controller.
If it’s not too difficult for you to change the sprinkler solenoids, I would suggest changing them to 24V AC type. A 24V AC sprinkler solenoid costs less than $10.
I would highly recommend setting static IP use your router’s DHCP reservation (also known as binding IP to MAC) feature. We are now discouraging users from setting static IP directly on OpenSprinkler, because it’s prone to conflicts (i.e. if you accidentally set two devices to use the same IP).
A while back I was able to get this type of flow meter to work with OpenSprinkler:
http://www.amazon.com/Liquid-Flow-Meter–Plastic-Threaded/dp/B00K0TFZN8/The meter has a hall effect sensor inside that generates clicks which can be detected by a hardware counter pin (using a counter pin is more efficient than polling or interrupt). However, my understanding is that this type of flow meter is not inline, and it’s better to use a proper flow meter like this one:
http://www.amazon.com/Dwyer%C2%AE-Multi-Jet-Pulsed-WMT2-A-C-04-1-Economical/dp/B00D2ME6FII think they work the same way, but I haven’t had time to verify it yet.
