Forum Replies Created
-
Posts
-
What firmware version are you using? If you are on 2.1.3 or lower, I recommend you upgrade to 2.1.4 which fixes an issue with the weather level not updating after the controller has been running for a few weeks.
Otherwise, try to reboot the controller and see if the water level will update.
Yes it does support 48 stations. The Options page had a slight rewording of the expansion board option. This way, it works for both expansion boards (the old 8 station ones and new 16 station ones). If the option is shown to you, its supported.
Hi Ed,
The relevant code for how California restriction is calculated can be viewed here: https://github.com/OpenSprinkler/Weather-Adjustment/blob/master/application.py#L336-355
Specifically though, it’s adds the amount of rain over the past 2 days and the current day. If this is greater than 0.01″ of rain, then a restriction is applied. This effectively changes the watering level to 0%. Once the flag is cleared, the watering resumes.
Glad to hear the issues are resolving.
If you do get your own weather station, I recommended one with solar radiation which allows ET based calculations. This is something we are working on for future releases.
Update: There are three factors that effect the percentage, by the way: rain, temperature, and humidity. So the other factors are likely the reason you are at 4%.
Which firmware are you using? Firmware 2.1.3 and below have an issue where network updates might stop after a few weeks of OpenSprinkler being on. A reboot usually fixes this issue. Also, check your location is a valid one with proper data. Not all weather stations are always up and have accurate data. So you may have to use the map feature to find a nearby station with accurate data.
Also, in regard to the sunrise/sunset times, the first day is the value on the controller (and the values used for the programs). The remaining days are calculated in the app and might vary just slightly from the controller times. With that said, it shouldn’t vary as drastically as you are pointing out. Therefore, I would suggest rebooting the controller and again checking the sunrise/sunset times.
I don’t understand why anyone would use the preconfigured SD card to be honest. It will always be outdated.
It is a lot better to grab the latest copy of Rasbian and just clone the repo and run the build script.
I am able to replicate this issue using the configuration you have pasted. This has nothing to do with DHCP as the app will not import DHCP setting (this would change the IP and cause all subsequent import requests to fail).
The issue seems to be with the /jn reply. After I imported your configuration, this is the reply the controller gives when requesting /jn:
{"masop":[125,255,255,255],"ignore_rain":[64,0,1,4],"masop2":[0,0,0,0],"stn_dis":[128,160,136,208],"rfstn":[0,0,0,0],"stn_seq":[247,254,191,219],"snames":["old goat h20","goat rotors","circle house","west pepper drip","house spray","west goat canal","dog north","Future Master","drip trees","west rotor","mideast rotor","east rotor","bananas","goat h20 pen","refill pond","banana drip","dog east","jr","outside circle","e.gto removed","impact goat","w.house spray","house drip","back chicken","se gto h20","front chicken","gto water","deice spray","dragon fruit","jugua papaya","blk greenhouse","bwn greenhouse"This is a partial reply and I know Ray added some logic to split the payload into smaller packets in 2.1.4 and right now I suspect it is the culprit. Once he is available, I will reference this post so we can hopefully find a fix. Unfortunately, for now it seems reverting back to 2.1.3 in your case will be the best solution, while we get this fixed.
Thank you
It is resolved and will be a part of 2.1.4. This should be officially out soon however the Github repo has been updated.
Sprinklers-PHP is no longer developed. It has been almost two years since anything meaningful has occurred on that repository. With that said, now the app is truly an app (not something you install on the server and access through a web browser). It is available in almost all app stores, just search OpenSprinkler.
Glad you got it working though and thanks for the detail!
Ah, if you notice the very top of the blog post, it says its outdated and has a link to a more recent post.
It is available here: http://rayshobby.net/announcing-opensprinkler-mobile-app-native-version-all-platforms/
Yes, 2.0A or higher is fine. The increased amperage allows you to open more stations simultaneously.
OpenSprinkler does not use port 3040. If you have traffic successfully hitting port 3040 of the device (which it doesn’t listen on), then your firewall rules must be allowing 3040 (can you see the packet information?).
I noticed something interesting when reviewing your PCAP: the reply from weather.opensprinkler.com is split into two packets (ID 18 and 19 of latest pcap). I did a capture on my home network and noticed the reply is contained to one packet. I am wondering if your firewall is somehow splitting the packets. This would likely cause an issue with the firmware reading the HTTP reply. Do you know why the packet might be getting split?
Update: I can confirm after reviewing my own packet capture, the VLAN tagging doesn’t matter. Mine also adds the 802.1Q header, so you can ignore this aspect of it.
No problem and thanks for the compliments.
By the way, the home.js file is somewhat of a hack. The way the UI used to load used this home.js file and I built that file to basically load my UI instead of the previous one. You don’t need this at all. In fact, if you save the files on your computer and open index.htm, it behaves just like the app (with some small differences).
@seockwig could you also provide some packet capture data? I’m interested to see if I can find a pattern.
The UI is written using JQuery Mobile (http://jquerymobile.com). The documentation is well written and easy to follow and a demo is available here: http://demos.jquerymobile.com/1.4.5/. This has actual code needed to implement each item being demo’d so should be a good start to get up and running.
The localStorage is what’s used to save the configuration for the app (and saved sites).
You can find the formula here: https://opensprinkler.freshdesk.com/support/solutions/articles/5000017312-using-weather-adjustments (at the very bottom).
Since changing the network configuration, try clearing the config by doing a reset options (just to rule out any other issues) and try again by setting your API key, weather adjustment method (Zimmerman) and location.
The changes in 2.1.4 are network related (closing sockets instead of leaving them open, properly send multiple packets for large packets exceeding MTU, etc). Overall this a huge stability improvement and I’m curious if it has any effect on your situation. Regardless, try the above and let us know. Otherwise, 2.1.4 should be released, maybe today.
You did a hard reset of the device? You mean you reset all options and let it reboot? Did you also set back the weather adjustment and API key? Also, check the timezone and sunrise/set times again.
Your latest PCAP does in fact look like a normal IP packet being sent to the controller and therefore should no longer be having the issue. Are you still seeing incorrect data, sometimes it can take a few minutes for the controller to query the service and update accordingly.
Let me know once you double check everything after turning off the tagging. If the issue is persisting I am no longer sure why since the PCAP looks correct now.
You can go ahead and pull the changes and recompile to see if everything is resolved. We have been running the updated version for a few days now without a hiccup.
In the future, we will not merge changes into the master branch before release and instead make a separate branch for upcoming versions (this was an oversight this time around which caused some confusion).
Thanks!
The project is constantly receiving changes as the OSPi support is very new. In fact, it is considered beta for firmware 2.1.3. With that said, If you would like to try the updated code, you are welcome to do a git pull and try again.
The updated version, 2.1.4, will be released soon which resolves a lot of the issues with OSPi.
If you use the build.sh to build and install OpenSprinkler, it will ask if you want to install the launch script. If you say yes, then it will modify the path to match your current OpenSprinkler directory.
I noticed in the packet dump you sent me the packets are being tagged with a VLAN which changes the ethernet header, specifically the type. If I am not mistaken, the Arduino library is very limited and not able to handle the VLAN packets and is simply ignoring them.
I understand you have the default VLAN select however I think the mere existence of that tag and the change of the packet from type IP to type 802.1Q (0x8100) causing the packet to be ignored.
If you can, please remove the VLAN tagging from the port the OpenSprinkler is using and see if that resolves the issue.
