Forum Replies Created
-
Posts
-
The actual water needed is delivered by the script provided in the first post, the ET value. As far as runoff (saturation point) values there is quite a few different calculations and after researching for quite a while I found that 15mm per hour is a good starting point for most soils. If you have sandy soil this will go up, and hard clay soils or steep grades it will go down.
Historical data, watering logs, and a running ET balance are crucial to maintaining a watering plan.
scottsh-Drip systems have been giving me headaches for months, all my personal watering equipment can be accessed above ground and I can run my dripline into a cup and get the rate at which it “precipitates” and doing a bit of rough math came up with a “mm/sec” that works for me. My ultimate desire is to have this calculated scientifically and properly.
As far as solar radiation is concerned most water sense approved devices use a calculation to adjust readings taken from a semi-local weather station. I simply used the external radiation and cloud cover percentages (calculated based on charge rate from the solar panel, not a true solar radiation measurement) from my PWS. After purchasing a solar radiation sensor and running the numbers side by side for just under 2 months, I was within 10% of measured. Seeing as the solar radiation plays the smallest part in the calculation for ET I accepted the error rate as fair.I am currently working out how to write all of the nvm data to the SD card on the avr based OS, so that I could have programs that do not require encoding of the times as this skews watering times quite heavily. It appears as though StdioStream in the SDFat library gives me the few basic functions required to mimic the OSPi and BBB versions using the “nvm.dat” file. I have to write/copy the nvm read and write functions for the avrOS make a few changes to the weather.cpp file and I should be able to get everything working.
Takes a while because I need my controller to work while I experiment on it…I should probably shell out the extra cash for a bench/test unit but it’ll probably be winter by the time I don’t have something else for my money to go to, cars and computers are expensive hobbies.
scottsh-where in the world do they use Jules for weather related solar radiation calculations? I have always used Watts/M^2, going between the US and Germany quite a bit I thought I had the metric and imperial systems down, but it looks as though I’ve missed a measurement.
Are you trying to retrieve a specific set of logs? The ‘start’ ‘end’ and ‘type’ keywords may be seen as arbitrary code execution attempts by your VPN. They are common keywords in a few higher level scripting languages. Do you have access to the logs from your VPN? If so you can try to view the logs again, and then check to see what exactly your VPN is blocking. You may be able to disable a security rule for the OS IP address. Though doing so could allow undesired access to your network.
The ability for local access leads me to believe a security rule is causing the issue.
Thanks for the information about the driver, I’m running Vista and needed the driver, my computer running Starter Edition did not. Good old Windows, just when you think you have it figured out, they mess with something that isn’t broken.
Finally got to this, sorry for the incredibly long delay, I have attached the customized version, you will need to add a folder called wuData.
The script can be run from the command line as:: python weatherCustom.py logsdir ETdir wuDataDir
Hope this gets most of what you wanted done. The icon URL in wuData does some funny things in the output so I omitted it from the file output, you can add it back in if you’d like just be aware it may break something.http://agsys.cra-cin.it/tools/evapotranspiration/help/Hargreaves.html There is a link, to the original works there, and a derivative work from Allen. Both are used to estimate ET with missing information. You would need an ASCE login for access to the papers there, if you don’t want to pay for that, http://www.iwhr.com/download/li080827-yoder.pdf is a nice abstract comparing and defining the evolution of a standard ET calculation. If you work out the base equations with a bit of dummy data, you will see a trend that is close to what the zimmerman method provides with the same data and his base weighting of inputs.
Zimmerman uses 3 pieces of data: Mean humidity ( defined as (min+max)/2 ), mean temp, and precipitation.
They are weighted in the following manner:
30 – mean humidity
(mean temp – 70)*4
Precipitation * 200
Those are all divided by 100 and added together, then 100 is added for a scale, which is then bound to 0 to 200.
Scientifically it appears to have no direct supporting work, however, it works out close to a couple ET calculations for inland areas free of high humidity influence. It is quite close to Hargreaves formula using only temperature, the formula is in the first link provided.So my daughter decided to assist me with watering my main computer, needless to say the computer hasn’t grown any…I have a new computer now, and the old hard drive is still working so I’ll get back to working on the script in the morning. My apologies for the delay.
Though I don’t know if he based his calculation method on any one scientific source, if you take a look at the Hargreaves papers, a lot of the methods are similar. So whether or not, he used the information as a source he ended up on the same path.
I have no problem doing that if you don’t mind waiting another day, I have a friends wedding to attend, then I’ll have plenty of time.
The average temp is simply [‘history’][‘dailysummary’][0][‘meantempi’] from the JSON reply provided by WU. This is the temp used to generate the scale. If you are running an older version of the weather python script locally you should update. Otherwise you are simply seeing a display error, that should not change the weather scaling from lining up with the WU data.
The Zimmerman calculation works like this:
hf = 30 – (Today’s average humidity)
tf = ((Today’s Average Temp)-70)*4
rf = -((Precip Today)*200)Scale = 100+(hf+tf+rf)
The scale is then bound to 0 to 200
If you notice the results are skewed too much in one direction or another they will often remain skewed within the same season ie summer as overall weather patterns are fairly consistent. To correct for this without manually running your program all the time I would suggest finding how much water you believe you are needing or not needing and adjusting your programs watering time by that percentage. For example you have a watering time of 10min programmed but it keeps knocking it down to 5min and you really need 8min. Adjust your pre-scaled time by +30% (100*(8-5)/10) and you will now have something the weather calculation will work with, just know that you may need to watch it for a few cycles, and if you have watering time restrictions you could run over your allotted time, though this could happen with the base calculation.
Also, his calculation works well in most areas away from large water sources ie ocean/lake, so prior to messing with the times make sure it actually needs more water. It’s easy to check by stepping on your grass, if it springs up within a couple seconds it does not need more water. Grass is ideally kept right on the edge of its drought conservation behavior, the plant will hold water near the roots and use surprisingly little water while remaining green. I used to work for a commercial irrigation company and was surprised by how much water people would put on their grass with little to no benefit, or worse causing fungus growth and killing large patches of grass. Remember, grass will yellow if it is over watered as well, so color is not the best indicator. For shrubs and other plants check with a knowledgeable person at a nursery for best watering practices, or ask how to tell if it is drought stressed.It appears as though ET is in the works, the script used for weather adjustments has the calculations present, it just isn’t implemented at this time, so given a bit of time Ray and Samer may have the solution soon. (ET is evapotranspiration, a complex calculation for actual plant water loss based on several environmental factors, including wind, temp, humidity, and solar radiation to name a few.)
I used a pickle jar lid and a 5 minute run time to get my measurements. After doing the calculation you’ll find you need a small adjustment one way or the other but it comes out pretty close.
A run/soak cycle is a bit more on the water conservation side of things. I don’t ever allow for more than about 1/2inch of water per cycle. For my yard much more than that I get runoff and I’m just paying to see if gutters grow when you water them. That’s where that minmax file becomes important. The max should be single cycle saturation point for your yard. The script will also lean toward watering in the morning to prevent fungus growth from grass being wet at night.I run the script every 15 min, nothing changes aside from the current weather conditions. It could reasonably be run just prior to sunrise and just prior to sunset, with no discernible difference in daily watering. If you use your WU data for something else and make a few calls I would suggest running the script 4 times a day just to make sure you get at least 1 reliable reading per day.
I’ve made a few adjustments to the script based on your response, I’ll post it in another post after I check to make sure I haven’t created any problems.
As far as logs are concerned these would be the run logs stored on the OS, the data that requires editing is just dummy data for a starting point, and so that the script works. I really need to have the script default to 0 run time for a program if no log exists, as I do believe the OS only creates a log for a program if it runs.
ET should be started at zero. It will be pretty well balanced after about a week of average weather for your area. If it rains a ton in the first few days it can look pretty scary in the negative, but usually remains pretty accurate for watering needs. When I started using it we got 14inches of rain the second day running, after about a week everything was leveled out, and the grass was a touch on the dry side but not dead.
the 1mm file should contain the number of seconds for each station to distribute 1mm of water over the coverage area. You may have to calculate the values if you don’t have a water meter that can display how much water is going to the zones.
There is a minimum and maximum water amount per start time. I used 5mm and 15mm respectively. If there is less than 5mm required the program will not run, in the next available start time. For example if your ET came out to 25mm you would see the first 2 start times enabled, the first would water for 15mm then the second would start and finish off the remaining 10mm.
If any precipitation is detected in the most recent call to the script all start times will be disabled. There is a flaw in that part of the script as it may disable watering for the remainder of the day, however, I figured if it was raining we could probably wait till the next day to catch up. Most places disallow watering during or immediately after measurable rainfall anyway.
The Zimmerman method adjustments to watering times run in weather.cpp on the OS, all the weather information it requires is retrieved from the weather#.py (# is a number) script which are then sent back to the OS for consumption and use by weather.cpp and the rest of the firmware. So while no, the scheduling calculations are not run in the cloud, they are inherently tied to the requirement for weather and scale data from WU or Yahoo and weather#.py respectively, and thus require an internet connection.
Hopefully that’s clear as mud or at the very least helps,
ShawnEdit: ***Changed a bit for clarity, weather.cpp adjusts watering times based on scale, weather#.py calculates scale from weather data on WU or Yahoo***
I honestly never even thought about backward compatibility issues, as I picked up my OS right when data logging was made available, and essentially installed an SD card on day one, before I set anything else up. I could see how this would be a problem for you guys, and is of little consequence to me as a single user. I’ll just go forward with the updates for myself. I suppose I could get it figured out and fork the project so others could mess with it as well, if they want to take on the additional task of installing an SD and updating the firmware, without affecting the general user.
The time compression thing just seemed odd to me, but again I’m a single user, so I’ve already modified my own to meet my needs. I was just wondering why the granularity wasn’t linear, and I didn’t really see an answer in the forum thread about it. If it was there and I missed it, I apologize, but I like understanding why decisions are made the way they are, perhaps to the dismay of the designers and programmers.Thanks for the reply and insight, your product and continued support is quite incredible. I used to run a major commercial irrigation system, and I am far more impressed with the capabilities of your device and staff.
Anyway, back to playing with my sprinklers 😀 Thanks again,
ShawnI have honestly never been so relieved to find out the city can charge me anything they want without me knowing. I never even thought to use the city water meter to measure water flow, mine has no display whatsoever, just a radio transmitter to the little locked box on the side of the house, with another radio presumably used to transmit the collected data to the truck that drives by to ‘read’ the meters.
That could have been quite embarrassing for me, but it is quite useful to those that have a display on their meter. I would bet at least a few people would overlook it as a reliable water flow meter, provided, free of charge to most residences in or near a city. I’ll also be calling my utility to ask about potentially having one I could monitor installed.
So anyway thanks for, perhaps unknowingly, enlightening me to another source of data for my sprinklers 😀We are both attacking the problem from different angles and arriving at the same result.
Your solution is quite accurate, works with all setups(overall better, I agree), but requires a flow meter…something that is impractical in my setup (I personally would have to place a meter on every secondary line as there is no accessible space on the primary line feeding them).
My method involves calculating volume or really precipitation rate(volume over time), this is quite the pain for subsurface if not impossible, and less accurate for drip systems, but works well for my setup, sprayers and surface drip. I suppose one could cover the sprayer and funnel the water into a container and measure direct volume of water output, versus the tuna can in the middle, I just used the manufacturers stated precipitation rate and made sure I had enough water pressure to keep it spraying at full capacity.
End of the day it sounds like we have 2 simple solutions with their own pros and cons, that provide the information needed to adjust the watering time.
I use an ET calculation to determine how much water is needed and multiply that by my calculated time to get 1mm in the total zone area, you would be doing the same with a measured time to get 1mm in the total zone area. Any rain can be subtracted from the ET calculation, so the weight of the rainfall is figured out already. If we want to water more or less we can just lie about the time it takes to get 1mm and it applies the adjustment percentage more or less.Anyway we’ve spent plenty of time saying the same thing different ways, your example above math wise is exactly the same as mine (Volume per Time) / (Coverage Area) = Depth per Time. Which gives us a way to calculate either, depth or time needed, quickly using a computer. So my friendly (I must admit quite patient), neighbor to the North thanks for the discussion, it’s interesting to see how different people work out problems. BTW no bother on the Imperial and Metric mixing, I’m German and live in the US so either system is fine.
The indoor outdoor issue would require a per zone indication, which is not done now as far as I can tell, so on that we agree.
What I was getting at is the ability to flatten the math out to 1 common dimension, depth. Rainfall is most commonly measured by filling a cup of a known size(volume) and dumping it out when it fills, then counting the tips. This volume is then extrapolated as a depth covering an undefined area, though for their calculation they will know the area the rain is hitting. If we assume the area for the sprinkler and the area for the rain are the same, depth is our only concern for both and now we can compare them. I make this assumption knowing that rain will not hit every plant with exactly the same amount of water, and that a sprinkler will vary if the pressure goes up or down, but at the same time knowing I’m not building the next lunar lander and some error is acceptable.
Sprinkler manufacturers will typically provide you with how many gallons per minute or liters per minute a single nozzle or head will distribute. They will also give a coverage area in square feet or meters. Using those 2 things and assuming the head is provided sufficient water volume to operate at design specification, you can calculate coverage depth. This would only have to be done once. Now that you have calculated coverage depth, you can use the rain depth over the same coverage area as an apple to apple comparison. This is simply Volume divided by Area, leaving you with depth. Converting known volume and known area to inches per hour can be done using: Precipitation Rate = (96.26 x Total GPM)/Total Area. 96.26 = (60/7.48)*12. 60 = minutes per hour, 7.48 = gallons per cubic foot, and 12 is inches per foot. So my sprinkler head and rain measurement are now the same, a precipitation rate. We will know the time for our sprinkler and can get depth. We will know depth for our rain and can then subtract it directly as time from the irrigation time when they both hit the same area.
Next up is time to some unknown depth, we’ll pick 1mm over the coverage area. I can run and measure the water, or calculate it if I know or can measure the volume of water provided to that single head in a certain amount of time. So let’s pick 5minutes, I run the sprinkler for 5min or calculate the output for 5 min, and now I have mm/5min. Divide the mm by 5 and I have mm per min. Let’s say I got 0.5mm per min. Watering for 12 mins means I applied 6mm of water to my coverage area. It rains for 3mm, these 2 measurements are now simply depth over my coverage area (yes there will be error if the measurement for the rain comes from a different area, but typically these errors are low enough to negate or work with), I can simply subtract or add them to get differences or totals. So to answer your question using my sprinkler it would be 12min*(6mmPR/3mmPR) = 6min Needed with 3mm rain accounted for…
If you don’t want to make a few assumptions, measuring actual rain and actual irrigation rates to each plant becomes a cumbersome process that typically won’t vary data enough to make a difference in the long run, but for some math is fun so hey, to each their own I suppose.
So to wrap up that mess I think we are actually on the same page most of the way down:
1) We need comparable measurements for rain and irrigation, which is easy enough to do without adding special equipment or measuring every single time we water. Once we have a good and acceptable measurement we can use that, this will allow for some error that we will have to accept or calculate out.2) Using Depth over time, or Volume over time for both measurements is a must. The time will be assumed the same for both measurements when they need to be directly compared. This will have to be accounted for regarding saturation…min/max boundaries for rainfall should handle this well enough for sprinklers.
3) Linear adjustments will have error…When using a single dimension linear adjustment and some form of averaging will reduce error to an acceptable level for sprinklers. While yes I am a physicist, no I do not have the desire for, nor do I need a perfect calculation, just a really close approximation of perfect.
I might be skipping over some of the important parts here, so if you are still having trouble seeing how irrigation time and rain depth relate linearly or if none of this makes sense let me know.
EDIT: That last statement isn’t meant to be rude, just throwing out the idea that discussion brings better results…and re-reading your previous post I think we are saying the same thing, just I’m calculating volume (more time, less equipment), and you are measuring (with greater overall accuracy, faster startup, added equipment).
Rainfall and irrigation are both volume measurements, so the calculation can be flattened to depth as the area would be the same for both. If you get 1mm of rain it is 1mm deep regardless of the area measurement since your irrigation measurement will be effecting the same area presumably. If you have an indoor watering setup, simply multiplying the rainfall by zero would negate its effect and your irrigation system would be happy. So some sort of Boolean variable for indoor(0)/ outdoor(1) would suffice. Using the weighted averages equation seems the best suited as new data is much more important than old data, or current is more important than forecast. You would end up with something like the following as your final equation:
todayIrrigation – ((yesterdayRain*inOrOut)+yesterdayIrrigation+(todayFallenRain*inOrOut))*.9 + (todayForecastRain*inOrOut)*.1
Using this type of setup uses historical watering cycles to adjust the overall weight of the rainfall. If you have an outdoor zone that needs 1 inch of water based on yesterdays information, and it was watered .5 (50% yesterday) inches yesterday with no rain today, and .25 inches yesterday. The irrigation time would be adjusted by approximately 75%. Another zone using the same data but requiring 2 inches having been watered 1 (50% yesterday) inch, will adjust by about 37.5%. Meaning the same rainfall had half the effect which is correct as the zone is set to water twice as much. At this point all you have to figure out is how much water is needed so you would have the todayIrrigation value to start with.
Weighting and adjusting the data is pretty simple with little to no user input once you have a solid way to figure out your starting point.
Math in a single dimension is sufficient for most of the calculations, since all we are concerned with in the sprinkler world is water depth at a location.
When a sprinkler says it waters 1 inch per hour you can measure this with a pickle jar or a kid pool. Assuming fairly even distribution of the spray pattern, and total coverage of the areas in question, you would have 1 inch of water in both containers after 1 hour.
Using manufacturer and design information or simply measuring output in each zone means you can set all zone to apply the same amount of water then use a weighting method to adjust how much each zone actually gets.
If you know it takes 1 hour to get 1 inch of water, and a zone needs 2 inches, you set the time to 2 hours, or vice versa you know if it is set to 1 hour it will apply 1 inch. I guess what I’m getting at here is by including datalogs in your calculation you can easily adjust for rainfall, or oddball watering times (scheduled 3min ran for 30). As these would negate themselves in the next calculation.
I did see that ET calculation added, I might have to talk to you about a couple of things needed to make it a useful weather adjustment, as i don’t think converting to scale is going to work in the long run. It really needs to be a multiplier, otherwise it will be capped in effectiveness. Minimums and maximums that are hard set will cause issue somewhere as well so this would need some user input given a good average baseline. I’m off topic a bit here so I created a topic in suggestions with what I think could help it become an effective method.
Evapotranspiration(ET) is just about the only method of universally calculating watering needs. Penman-Monteith and Hargreaves are the 2 most widely accepted methods of calculating ET. There is a lot of math to calculate water lost by a plant, and it requires localized data, for the vast majority of the equation. In my experience using a site 30miles from me and my local (on my house) station yielded less than a 20% difference for the entire watering season last year. I live in CO along the front range of the Rockies (east side), and the weather here is crazy it can literally snow on one end of town and the other is 65F and sunny, so 20% seems as though it would be a good reference and a solid “universal method.” I have written the python part for the adjustment, now I need to work on how to increase the resolution of watering times on the sprinkler system, because you would essentially store a program with the number of seconds required to achieve 1mm of water coverage on your plant. Then you have to store a data set keeping the plant type (ie grass, shrubs/trees). These would then be multiplied by the calculated value, resulting in decent watering without much over/under-watering.
Forecast and actual precipitation was the hardest part to figure out, the way I did it was to assume the further out a prediction was the more incorrect it was by a factor of 2 (it is right or wrong, and each day has a greater chance to be wrong than right). It looks like this: predictedRainTotal * (1/day^2) * probabilityOfPrecipitation. Any rain forecast for the rest of the day is simply multiplied by it’s chance of rain. The Daily ET is then calculated and the 2 totals from above are subtracted. The program spit out will not water if it is currently raining, too windy, or too cold. It favors watering in the morning, to avoid mold and fungus growth in inherently damp localities, simply put it avoids putting the grass to sleep wet. The moisture in the morning cools the ground and reduces watering needs throughout the day. It will water in the afternoon on hot dry days if needed. For areas with watering restrictions you can set the time it starts the program and it will follow that.
All watering is calculated using yesterdays weather data, to allow for the greatest accuracy, and then adjusted using forecast data with less weight.
All watering methods are affected by wind, because high winds will pull moisture from the plant, watering during this time will cause the plant to literally “learn” not to conserve water. It will not close up and tighten cells near the surface of the leaf thereby releasing more water into the air. A tree that is overwatered during dry times will have a shallow root system under the same behavior. What subsurface watering does for you is conserve water through reduction of evaporation before it can be absorbed by the desired plant. While yes you don’t have to worry about the wind carrying the water away from the plant, you don’t want the plant to learn to sweat in the wind.
If you want to come up with an equation of your own the important factors to pay attention to are: Temperature(now and average daily), wind(now and average), Humidity(average), Sun Radiation reaching the ground at the site(this can be estimated pretty well), atmospheric pressure, actual and saturated vapor pressure(can be calculated well), and soil heat flux(pretty much needs to be calculated as measurement equipment is prohibitive). This will mean you can see how much water the plant has lost, then determine how much it needs.
Here is a link to the python script if you are better at working out how to get it to work with OS you are more than welcome to use it and call it your own. You will need python running locally to use it right out of the box. All the libraries used are included in the zip file, the file structure directly used by the script is setup though you may need to create a dummy file for the ET data and logs using todays epoch date(unix time/86400). You will need to edit the file to provide your own WU api key. Of course all these would exist on the OS and be transmitted to the remotely stored script during the getweather function, which would then return the info to the OS for use.
I have been fine tuning for almost 2 years in vastly different locations (AK, FL, CO, and South Korea), so hopefully it’s a good jump start to something useful. Currently I just run the script and use a cron job to edit the associated program on the OS.
If you would like to use a PWS on wunderground and discover that it occasionally goes down without notice you can try this trick:
Open the wunderground site and do a search for the pws.
Look for the latitude and longitude coordinates. (38.936 -104.726 or ##.## N ##.## W)Â All South(S) and West(W) locations need a -(negative) in front of the numbers
Copy that number down and log into your opensprinkler. In the bottom right corner select edit options.
Where it says location put the numbers you copied in separated by a comma with no spaces: 38.936,-104.726
DO NOT hit the little location map pin on the right side of that input box.
Then hit Submit in the upper right corner.
Now make sure the weather shows up on your main controller status screen. If you have done this correctly WU will now get the weather for that original station or the next closest one if it’s down. I was told a while back that this may cause an issue with something somewhere, but after a full year of running I have had absolutely no problems, so take my advice with the knowledge there is a slight risk in something going wrong.
ET is bascally how much water a plant loses in a given time period, kinda like measuring how much a person sweats in a day. The calculation can be used to figure out exactly how much water a plant would therefore need to replenish the water lost. Since most plants that are watered have an above ground component, solar radiation plays a factor in the ET calculation. So even if you use a subterranean irrigation system you would need the solar radiation calculation to get an accurate ET amount. Solar radiation can be estimated using your location and cloud cover information from WU, so while not essential actual solar radiation will improve your calculations and help reduce over or under watering.
If you would like to research ET and it’s application to irrigation look up: Penman-Monteith ETo or Hargreaves ETo, as these are the 2 most widely accepted methods.
I’m decent with python, however, a lot of the methods for writing logs and incorporating changes into the core files for opensprinkler is a bit beyond my scope and time available. You are more than free to use any or all of the code with or without credit. I have been using this in a very rudimentary manner by adjusting my runtimes based on the outputs. I run the script about every hour and have an autoit script log into my OS and edit the program for me. Total hackjob but it does a fantastic job of watering only when needed, and avoids watering in less than desirable conditions. It would be awesome to see it incorporated in a truly functional manner.
I assume I would submit the pull request to the weather script section of the repo? My biggest hangup came when the run times were reduced to save space, until then it worked well, now it balances between slight over and under watering. I was using the 1mm times multiplied by the ET up until that change was implemented, as the ET output is mm of water required, and that made it a perfect candidate for that method. I suppose the 1mm time could be multiplied by the desired single run max and then converted to a percentage of the max, and use the current format of the Zimmerman method.
I sincerely thank everyone that has put effort into making this one of the most end user friendly sprinkler systems I have come across. I also have a basic winterization system i have been working on using a few electrically activated valves, to shut off and drain the water lines whenever a freeze is detected, which could easily incorporate dates for areas like where I live in Colorado which restrict water before and after certain dates. Right now it uses a single zone to turn off the main water valve, and open the drain lines to stop pipes from bursting, but I’m sure I could look into the wireless device add-on capabilities that appear to be incorporated into the OS system.
When you say you can’t access the sprinkler from the web do you simply mean the web-ui, as in you are still on your local network and trying to access it? Or, do you mean trying to access the sprinkler from another network? The answer to either of these questions will vary what is needed to get everything working again.
If you are on the local network, make sure you can access the router, and that the sprinkler and computer used for access are on the same subnet. For example, you set the sprinkler to 192.168.1.35, and you are trying to access it from 192.168.0.36. Note the 1 and 0 in the third position, this can make the sprinkler inaccessible locally if you do not have port forwarding set correctly, while still allowing the sprinkler to function outside the local network. Essentially, it is acting like two separate local networks. If that is not the case, the bridge may be blocking external IP addresses, make sure there is nothing acting like a firewall for your specific IP then try again. If you can’t access the bridge on the network to reconfigure it, that is most likely your problem.
If accessing it from an external network is your problem, go through all your setting again, ensure you don’t have some simple problem blocking you from access. For example, port forwarding is to port 8080 while the sprinkler is trying to be accessed from port 80. This would cause no problems locally but externally there is a good chance it will drop the connection. As a quick test for simple configuration errors, you could TEMPORARILY set the IP address for the sprinkler to the DMZ on the router. If it works like that, first, remove it from DMZ, then meticulously verify all settings.
Another external access problem may be your leased IP address from your ISP has changed. If you are trying to access 123.x.123.123:80, and your actual WAN IP address is 123.x.123.234:80, well then you will have problems. These two issues are the most common problems with external access.
Depending on how knowledgeable you are with networks, and their settings there are other things to try, but without knowing I don’t want to talk over your head and just cause more frustration. So let’s see if the above helps, or we can get a bit more information.
When asking for help troubleshooting anything, remember the person helping can not see what is happening or what it is you are doing, so always make sure you include enough information for a monkey of any sort to duplicate your problem, and if that’s not possible tell me what you are doing with your fingers, what you expect to happen, and what is actually happening. Remember, as frustrating as it is for you, it can be even more frustrating for the person who wants to help, and can’t.
I see what is happening now, except: is a catch all, if you would like to only extend the sleep when certain errors happen, use the applicable exception for example:
try: //some code you hope works except (TypeError, ValueError): //increased sleep time except: //something else happened leave sleep time alone and do whatever you do for errorsA list of all exceptions can be found in the python documentation, if you simply want to ignore errors use except: pass
I think simply handling certain errors appropriately would do wonders for you and would be quite simple to implement. Python has a ton of code built in for handling problems, seems to be designed for writing code assuming everything will work, then just quickly deal with whatever goes wrong. Easier to ask forgiveness than permission, type programming.I’ve found that checking data on weather underground more often than once every 15mins does little to add useful information for calculating watering schedule modifications. Even a single check just prior to a scheduled watering event is often enough, given returned data is valid and useful.
If weather data is used as a rain sensor of sorts, then simply factoring in forecast, and current co editions to that single check, will reduce accidental watering during rain events to a negligible level.
My suggestion would then be the definition of acceptable defaults for the correction of odd data loss and on demand requests for data used to adjust schedules, or display current/ forecast information. I highly doubt a computer of any sort cares what the weather was like 15mins ago if you yourself have no interest in using the information.
Outside of the meteorological fields high resolution historical weather information is geewiz at best in most cases. It’s good practice to constantly refine programs toward the average, and then handle the outliers.
