Forum Replies Created
-
AuthorPosts
-
RayKeymasterOK, that means the controller is now getting the return data from the weather query. It’s still unclear to me what caused the problem initially. Anyways, let’s see if you will get further notifications from Wunderground.
RayKeymasterKeep in mind that any pins that have to do with power, I2C, SPI (other than the CS pin) can be shared so there is no need to rewire those pins. Ideally if your capes only use I2C or SPI, then there is minimal or no rewiring necessary. But I can see that the touch screen cape probably needs a few GPIO pins and if those conflict with OSBo they have to be rewired.
RayKeymasterSure you can. I can imagine that desoldering headers with that many pins may be difficult. So if it’s too hard, send an email to [email protected] and we can sell you a board without the hearder.
If there are GPIO conflicts, you are right that you can cut the PCB trace, reconnect it to the new pin, and edit the gpio_pins.py.
Just out of curiosity, what capes are you planning to use?
RayKeymasterUsing the rain delay feature, there is always an upper limit on the number of days you can set. If you want to keep the controller off for an extended period of time, you can either use the ‘Disable Operation’ option (this is on the sidebar); or you can physically turn the controller off by using the power switch.
RayKeymasterOK, the sunrise and sunset times are clearly not being set (6:00 and 18:00 are the initial values). So this confirms my suspicion that something is blocking the result of the query. As an initial diagnose, you can open a browser and try the following url:
http://weather.opensprinkler.com/weather0.py?loc=Inver%20Grove%20Heights,%20MN
see what you get.Another thing you can try is to use your zip code instead of your city name. See if that makes any difference.
RayKeymasterI tried your location and cannot reproduce the issue. I am getting one call per 15 minutes, which is the correct call rate. Can you go to the homepage, click on ‘Current Status’, and check the Sunrise Time and Sunset Time to see if they are correct? If they aren’t, it’s likely that something, either your ISP or your router is blocking the query result, causing the controller to not be able to receive the result, and hence keep sending more queries.
RayKeymaster500 calls/day should definitely be sufficient. The firmware is set to query Wunderground every 15 minutes so it’s 96 calls per day, well below the limit.
The only issue I can think of is when a query fails the firmware will keep sending a new query every few minutes, which can exceed the call limit. Can you tell me the location you set in OpenSprinkler, so I can check whether the issue is reproducible.
RayKeymasterI don’t have a Yun myself so I can’t test. If Yun’s pins are compatible with Arduino then it should work too. You can check OSBee’s user manual for its pin uses:
https://github.com/rayshobby/OSBee/raw/master/OSBee_shield/docs/osbee_shield_10_manual.pdf
RayKeymasterCool, thanks for sharing the project and the picture!
RayKeymasterHi Paul, I still didn’t get a clear sense of what the power supply issue was. Is it that when you plug in 24VAC, the OpenSprinkler fails to power up? Or is it that it powers up but can’t drive solenoids?
Regarding the two systems, it seems to me that the two systems are not electrically connected (other than perhaps sharing the same transformer?) If so, I am pretty sure there is no issue running both at the same time.
RayKeymasterOK, thanks for the tip. Another work-around, if for any reason you can’t upgrade the firmware right away, is to disable the 3rd (or 4th, since it’s duplicate) program. That way there are 4 programs, but one of them will not run (disabled).
RayKeymasterYes, going above 100% is possible. Zimmerman’s algorithm outputs a number that’s between 0% to 200%. To check the source data, you can go to the web interface -> side bar -> weather diagnostics, and see if any data (like temperature, humidity) might look wrong.
Also, please note that firmware 2.1.0 had a bug where if you’ve changed your OpenSprinkler’s HTTP port (to anything other than the default 80) it will fail to query the weather script. So if you are using firmware 2.1.0, and have changed the port number, the 114% you are seeing may be an old number that has not been updated.
RayKeymasterThe arrow is shown when the controller pings the router to see if it’s still connected. It does so every 30 to 60 seconds (forgot the exact interval). If the screen gets stuck with the arrow, it means the controller is not able to reach the router, so typically indicating a connection problem.
Are you using DHCP or static IP? If you are using static IP on OpenSprinkler, you have to make sure to set the correct gateway (i.e. router) IP. Otherwise the controller will not be able to reach the router.
RayKeymaster@Paul: you asked ‘I need to find out if its the supply or the board I’ve plugged in the power supply onto the PI for now to check that it works.’
If you bought the power supply from us, it’s a 24VAC 750mA transformer. Can you explain what specific issue you have encountered? Is the power supply not sufficient to drive your solenoid?
Your second question is: ‘I need to run 2 systems from the OS the first is a normal retic system the second is to a float in a tank’.
DO you mean run two software systems running on the Pi, or you mean have two hardware systems (one OS, one something else)? If it’s two software systems, you should be able to run them at the same time as the operating system can multitask; if it’s two hardware systems, I will need to know what the second one.
RayKeymasterThanks. We try to be as quick as we can to fix major bugs. I appreciate you reporting the bug — your detailed description helped me find the cause of the bug.
RayKeymasterOK, thanks for upgrading and testing.
RayKeymasterHi Adriaan,
It has come to our attention that firmware 2.1.0 and 2.1.1 have a bug that causes the program data output to be incomplete when the number of programs is a multiple of 3. This will lead to the web interface not responding. Because you have 3 programs, I am pretty sure this is what’s causing the issue you have encountered. A fix has been released in firmware 2.1.2. You can check the related thread here:
https://opensprinkler.com/forums/topic/creating-a-third-program-stops-ui-access/#post-35016Thanks.
RayKeymaster@Fr33: it has come to our attention that firmware 2.1.0 has a bug that causes the program data output to be incomplete when the number of programs is a multiple of 3. This will lead to the web interface not responding. If your number of programs is 3, 6, 9 etc. it’s very likely that the issue you encountered is due to this bug. A fix has been released in firmware 2.1.2. You can check the related thread here:
https://opensprinkler.com/forums/topic/creating-a-third-program-stops-ui-access/#post-35016Thanks.
RayKeymasterFirmware 2.1.2 has been released, which fixes the above two issues: 1) /jp returns incomplete data when the number of programs is a multiple of 3; 2) incorrect handling of the SPACE character in program name. 1) is likely due to a compiler bug, and I am surprised that it wasn’t brought up earlier.
Anyways, thanks for reporting the issue. If you have never upgraded firmware before you can check the instructions here:
https://opensprinkler.freshdesk.com/solution/categories/5000022938/folders/5000099521/articles/5000381694-update-opensprinkler-firmware-with-downloads-
RayKeymasterA quick update: I found a fix to the issue. The source of the issue is not clear but is definitely odd — it seems to me like a compiler bug. The line of code that outputs the ]} ending characters is being ignored when the number of programs is a multiple of 3. This might be due to a glitch in the compiler optimization. A strong evidence is that when I turned on serial debugging code, the issue is immediately gone. Another evidence is that the issue happens on OpenSprinkler hardware 2.1 and 2.2, but not on 2.0 — all three use the same code, but have different microcontroller frequencies, so the generated code is different.
In any case, the fix is to add some dummy lines (e.g. delay(1)) after the line of code that outputs ]}, and my guess is that it causes the compiler to optimize the code in different way thus avoiding the issue.
Another issue with firmware 2.1.1 as you probably have noticed is that it’s not correctly handling the SPACE character in the program name (I noticed that you used underscore in place of SPACE). So we will be releasing firmware 2.1.2 shortly to address these two bugs. Thanks.
RayKeymasterI can confirm the issue. This seems to be happening on firmware 2.1.0 as well, which is quite surprising because so far I can only think of one user who raised a question that’s related.
To summarize the issue: when the number of programs is a multiple of 3, the /jp command returns a string that’s incomplete (missing the ending ]} characters). I am pretty sure this has to do with the firmware sending out one packet per 3 programs. I am digging into it right away and will report soon. Thanks for reporting it and sorry about the trouble.
December 12, 2014 at 12:18 am in reply to: Best to go with the Rpi or the Open Sprinkler assembled version ? #34991
RayKeymasterThe next steps on the todo list are better weather algorithms integrating ET, cloud support to allow easy remote control, support for a large number of stations, integrating flow sensor and soil moisture sensor.
RayKeymasterCool, let me know how it turns out.
December 10, 2014 at 9:44 pm in reply to: Best to go with the Rpi or the Open Sprinkler assembled version ? #34981
RayKeymasterWhen you say ‘giving me freedom to do everything’ do you mean hardware or software or both? If you are referring to hardware, I would say the standard assembled OpenSprinkler is a better choice because microncontroller pins are easier to work with when it comes to reading analog sensors, counting pulses (e.g. reading a flow sensor). The hardware includes some features that OSPi does not have, such as LCD, buttons, headers for radio frequency transmitter. Also, the assembled OpenSprinkler is an out-of-box working solution for a typical user, whereas OSPi is mainly targeted to RPi enthusiasts who have experience with RPi. Because RPi is not included in the kit, it requires some assembly steps and software setup (mainly burning an SD card).
If you are referring to software, the assembled OpenSprinkler is written in C++ (more specifically, Arduino programming language). I work closely with Samer to develop the firmware and app. We have a roadmap with planned new features and the primary goal is to make the controller as efficient and easy to use as possible. Modifying the code requires some experience with C++. For OSPi, the software is written in Python, and is user maintained. Currently the OSPi software is primarily written and managed by Dan. You will need some experience with RPi and Linux in general. The features are easier to expand if you are familiar with Python. For example, Dan’s software framework has a wealth of plugins and also has several forks where users experiment with new features.
So I would say if you want the most straightforward setup, or prefer to have LCD and buttons, you should go with the assembled OpenSprinkler. If you prefer modifying the code in Python, you should go with OSPi. Hope this helps you to select.
RayKeymasterI just occurred to me that you can also use solid state relays:
http://www.zoro.com/g/Solid-State%20Relay%20AC%20input%20AC%20output%20Crydom/00069396/
look for those that have ‘input voltage’ 18 to 36VAC. These are very easy to wire. -
AuthorPosts