Forum Replies Created
-
Posts
-
You are right — with hardware 2.2 it’s now easier to upgrade 644 to 1284, because Optiboot for 1284 already exists. At the moment we are not planning to upgrade to 1284 yet, partly because we still have existing stock of 644, and partly because the current firmware, which is 54KB in size, is not approaching the limit of the program memory size yet.
Cool, very excited to see the new development. The plugins, especially the pressure plugin, are very interesting and I will be checking out them soon. Thanks for the great work!
@Phil: are you sure you are measuring AC voltage? If you are using a multimeter, make sure you are using the AC level, and not DC, otherwise your measurement will come close to 0 as you observed.
Dan is right that the master zone is electrically the same as any other zone: it outputs 24V AC (or whatever voltage your transformer outputs) when it’s turned on. Normally if you want to use it to turn on a pump you can get a pump start relay, which takes 24V AC as input, and can switch a pump at powerline voltage.
You mentioned ‘AC/DC Converter to convert what I thought would be AC25V to DC12V which is the input for the next component in the sequence a solid state relay’. Could it be that the AC/DC converter is doing something strange that makes the voltage show up as only 1.5V?
I’d like to add to Samer’s reply that if you use the OpenSprinkler mobile app (the native apps), you do NOT need Internet connection. Those apps have the Javascripts built-in. You only need Internet connection if you are trying to directly access OpenSprinkler in a web browser (i.e. not using apps).
Keep in mind that if you don’t have Internet connection, features like weather-based control and automatic time zone / DST detection will not work. You also can’t access the controller remotely if you are traveling away. For most users, these are the most valuable features of OpenSprinkler.
Similarly, I would argue that to control the device through an USB cable defeats the purpose of having a web-based sprinkler controller.
What’s included or not included in the package is CLEARLY indicated on the product webpage:
http://rayshobby.net/cart/os
I am sorry if you missed those when you made the purchase. One reason that transformers are not included (as specified on the product page), is that you likely already have a sprinkler controller and you can reuse the transformer because all sprinkler systems have the same electric spec. Also, it’s difficult for us to stock transformers for different countries that have different mains voltage.I don’t think it’s surprising that ‘router is not included’ — how would you expect the controller to get connected to the web, if you don’t have a router? You might even argue that we should include sprinkler valves, but I think it’s common sense that these are provided by you. OpenSprinkler is just a controller (like a thermostat is just a controller for HVAC system), it doesn’t include the whole system.
v1.0 and v1.1 are basically the same, the main differences are:
– v1.1 uses the OpenSprinkler (injection-molded) enclosure, while v1.0 uses an off-the-shelf enclosure with custom cutouts.
– v1.1 uses a slightly bigger relay while v1.0 uses a smaller relay (the relay is not used for sprinkler control, it’s there for extra, like switching garage doors and so on).Other than these, the circuit design is the same. Because the OpenSprinkler enclosure was not design particularly for OSBo, to fit everything, on version 1.1 you can see from the pictures that BBB has to be plugged in at an angle. A few users didn’t like this and actually preferred v1.0. In any case, we don’t have v1.0 any more, only OpenLab still has a few left in stock.
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.
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.
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.
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.
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).
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.
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.
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.
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,AustraliaThis 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=1101The 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.
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.
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.
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.
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.
@emmasam: are you referring to the microcontroller-based OpenSprinkler, or OpenSprinkler Pi / Beagle?
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.
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.
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.
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?
