[Ray]

I accidentally found a interesting feature of TL-WR702N that will allow you to re-configure it remotely. In other words, in Client Mode you can still access the adapter’s configuration page. The trick is that the adapter enforces its default IP address (192.168.0.254), even through it’s connected to a network that has a different IP base (for example, my home network uses 192.168.1.x). So normally you will not be able to directly access the adapter since your computer’s IP address is in a different subnet. However, you can override it by setting a manual IP address, such as 192.168.0.100, which is compatible with the adapter’s subnet. Then open a browser on your computer and type in 192.168.0.254, and you should see the adapter’s configuration page. Different operating systems have different ways to set manual IP address, please Google to find out.

[Ray]

For OSPi, the typical way to upgrade is to go to the OSPi/ folder in home directory and run the ‘git pull’ command.

The firmware for the microcontroller-based OpenSprinkler unfortunately cannot run on Pi, because the hardware platforms are different.

[Ray]

Because there are several ways to reference the GPIO names, which can be confusing, make sure you are using the correct pin 8 (i.e. the physical connector pin index, not the logical name). Please check the user manual page 10: http://rayshobby.net/docs/ospi14_manual.pdf for the pin labeled ‘Rain Sensor’.

does it deliver 24V AC (as requested by the rain sensor)

Where did you read about this? The rain sensor is typically just a rain-activated switch, it does not deliver 24V AC by itself. Also, because the rain sensor is corrected to a GPIO pin on RPi, NEVER feed 24V AC to it because that will obviously destroy your RPi.

[Ray]

If you don’t have SD card, the log will be empty. Will check the issue about spinning icon, but there won’t be any log data if you don’t provide a SD card.

Which NTP IP did you change it to? I tried a different one and it seems to work fine, I didn’t see the UI hanging. One possibility is that if you changed NTP server to one that’s invalid or inaccessible, the controller may be trying to reach that server and eventually timeout. Meanwhile the UI may freeze until the controller times out.

[Ray]

I just installed it all (the firmware updater crashes in Yosemite MacOSX)

Since Yosemite isn’t officially released yet, I haven’t upgraded and so can’t test yet. But you are right that the QtSerialPort library has a known bug that’s likely the cause of the crash.

(by the way, the crash report is a bit too long so I clipped your message. Sorry about that).

[Ray]

I imagine the external Python script means we no longer have the option of hosting all the files on the SD card?

The weather script is a server-side script (written in Python), so it has to run on a server that can interpret Python. The microcontroller is not powerful enough to do so. Therefore you can’t host the Python script on the SD card. This is different from Javascripts which are client-side.

You can still host the Python script somewhere else, like on your own server, and modify it as you like.

[Ray]

Since the data comes from Wunderground, you can just go to Wunderground.com, put in your location, and the temperature, humidity information you get there is the same as the data that went into the equation.

[Ray]

OK, I figured out the issue with using PWS: apparently the WUnderground geolookup api returns a variable named ‘tz_long’ instead of the normal ‘tz’ (which is what autocomplete usually returns). I changed the scripts accordingly, and it should now work with PWS as well. When using PWS, make sure you also provide a valid API key, otherwise the query will fail.

Despite lots of rebooting I have only just tried a full-reset. I’m guessing setting the timezone using the buttons during startup hard-codes them, resulting in continued failure to correctly set sunrise/sunset even if the correct data was returned.

I don’t think this is true: the timezone variable is never hard-coded: as soon as the script query returns valid result, it will overwrite the existing timezone variable. So setting the timezone upon startup should not matter.

[Ray]

I just tried ‘Adelaide, Australia’ and it works fine: the firmware is able to find out it’s UTC+9:30 time zone, and the device time is shown correctly. Note that after you set the time zone, there will be up to 15 seconds delay before the updates are shown in the UI. Also make sure your OpenSprinkler is connected to a router that can reach the Internet, for the obvious reason that it needs to get data from the Internet.

If it still doesn’t work, you can manually try the url below:
http://rayshobby.net/scripts/weather.py?loc=Adelaide,Australia

This is the script that the firmware uses to calculate timezone, sunrise and sunset time (and also water percentage if a WUnderground API key is provided). My output currently contains the following:
tz=86&sunrise=347&sunset=1101

[Ray]

The program preview takes into account the water percentage scaling. We can probably add a checkbox on the UI to allow quick enabling/disabling of the water percentage. For the meantime, you can always go to Edit Options, and temporarily set the Water Percentage to ‘manual’ 100%. Then after previewing the programs, change the option back to the Zimmerman method.

[Ray]

The common sprinkler valve always has a delay in closing the valve. The way it works is by relying on the water pressure build-up internally to stop the water flow. So even though the solenoid is released, it may take a few seconds for the water to stop flowing. Also, the lower water pressure you have the longer time it takes to fully stop the water flow. So if you are timing it according to when the water stops flowing, it will always be longer than the programmed time.

[Ray]

OK, the rain sensed start time already exists in the firmware, so it’s pretty easy to output it to the UI. Will add it to todo list.

[Ray]

What’s your location string? Have you clicked on ‘Lookup’ to see if it’s recognized by Wunderground? The auto timezone setting hasn’t been tested comprehensively for international cities. If you specify your location string we can help you check what the issue is.

Regarding source code: the main repo is for official release, so 2.1.0 hasn’t been checked in yet because it’s not officially released. The separate repo is for maintaining intermediate changes, for example, the current 2.1.0-beta code is there. To compile 2.1.0-beta in Arduino, just grab the hardware profiles from the main repo, and use the 2.1.0-beta code from the development repo.

[Ray]

Since 1284 is a pin compatible with 644, it should be an easy replacement. The source code should also compile under 1284 profile without problem.

However, keep in mind that if you want to use the bootloader (to be able to upload a firmware from OpenSprinkler’s USB port), you will need to modify the bootloader, and this will be slightly more complicated because 1284 has 128KB memory space which means the memory address will exceed one page. The bootloader code should be able to handle multiple pages. On the other hand, if you don’t mind using an ISP programmer to flash firmware from the ISP pins, then no need to mess with the bootloader.

[Ray]

@emmasam: are you referring to the microcontroller-based OpenSprinkler, or OpenSprinkler Pi / Beagle?

[Ray]

If you go to the OSPi/ folder under home directory, you can do a ‘git pull’ to update your software to the latest version. I think I’ve heard about the bug that editing station name causes the software to crash, but I assume it has been fixed in the latest version.

[Ray]

Can you clarify: flash the OS image to BBB? Which OS image? Also, since this post is under OpenSprinkler Pi (OSPi), please make sure you are NOT trying to flash OSPi image onto BBB because that obviously won’t work. Please use the OSBo image, the link of which is in OSBo user manual.

[Ray]

Cool. Thanks for the update.

[Ray]

I think the firmware can be changed to automatically re-initialize network settings after import. This can be included in the official Firmware 2.1.0 release.

[Ray]

I don’t think MAC address is the problem, because first of all, MAC address is never exported and imported, second, firmware 2.0.9 and 2.1.0 use the same software defined MAC address, so it should remain the same. The only thing that may change is the Device ID, which defines the last byte of the MAC address. If you have ever changed the Device ID (default is 0), that may have affected the IP address.

If you can log on to the router’s configuration page, can you tell if the MAC address has changed before and after installing 2.1.0?

[Ray]

How are fixes to the firmware being released and pushed out?

The firmware files are stored on Github and have been updated. If you click on ‘Update and Detect’ button in the updater program, it will grab the new firmware file.

[Ray]

OpenSprinkler 2.1 is designed to be a drop-in replacement of your existing sprinkler controller. The package includes the sprinkler controller with terminal blocks. What you need additionally are:
– 24V AC transformer (you can reuse your existing hunter transformer)
– Sprinkler valves (which you already have since you have an existing sprinkler setup)
– Option to connect OpenSprinkler to your router (any of the choices below):

• Ethernet cable is the simplest (connect OpenSprinkler directly to your router)[/*:356g50s5]
• Or a pair of powerline network adapter, which creates a local network by making use of your powerline (http://www.amazon.com/TP-LINK-TL-PA2010KIT-Powerline-Adapter-Starter/dp/B00AWRUIY4)[/*:356g50s5]
• Or a WiFi adapter which can link to OpenSprinkler and talk to your router wirelessly (http://www.amazon.com/TP-LINK-TL-WR702N-Wireless-Repeater-150Mpbs/dp/B007PTCFFW).[/*:356g50s5]

Additional information can be found on the product webpage: http://rayshobby.net/cart/os
Thanks.

[Ray]

Are you using the most recent SD card image? Please follow the instructions on the OSPi v1.4 user manual for download links:
http://rayshobby.net/docs/ospi14_manual.pdf
The image is verified to work with RPi B+.

[Ray]

@TechFan: ok, thanks for finding out the cause of the issue.

Tired of using Processing and learning about its quirks, we are now working on re-writing the updater program using Qt. Hopefully it will be done by this weekend.

[Ray]

A quick update: the just released firmware 2.1.0 (beta) now supports automatic time zone and DST detection (based on the location that you set in the options). Please see the announcement here: viewtopic.php?f=2&t=926

[Author]

Posts