Any idea of how this is usefull? Try to think but can’t find a way to use it:(
you can affect your irrigation controller.
e.g. if it rained yesterday, don’t need to water today.
It was developed to suspend the automatic schedule of an irrigation system, but I am sure there could be many more applications.
To use it add a trigger for a scene when the “Tripped” device variable is a value of “1” meaning it has or will rain or a value of “0” when there is no rain.
You could also use it just like a basic rain gauge by reading the “PrecipitationTotal” device variable. For instance if you set the accumulated precipitation period to today only and the forecast to none. You can get the total amount of precipitation that has fallen for today.
[quote=“blakem, post:8, topic:180668”]@Bulldoglowell, I designed it so if there are 5 consecutive communication failures it will set the device into failure. The idea was to notify the user that it is not updating. In the latest version 2.1 I write errors to the task status bar on the UI so that feature is not really that important now. If it becomes a nuisance it could be removed easily. In any case if the communication issue resolves itself then the plugin will continue to function again even though it shows a device failure. A reload will clear the failure flag.
Also worth noting there were some quirks with version 1.0 that are now resolved with version 2.1 that could have caused the device failure to report needlessly. It should be a nonissue now but please let me know of any problems you might have with the latest.[/quote]
The 5 inches of rain today reminded me to let you know all is working very well…
Again, great little plugin, I feel bad having to tear out all that Lua and PLEG I cobbled together to do what your plugin does so elegantly. 
Apologies for the delayed reply - adventures elsewhere have kept me busy.
From the read of your latest update to original post, sounds like v2.4 may be cure for my ills - kudos for the rapid updates!
That said, looks like I’m awaiting this to be propagated via Via App update?
I’m presently still stuck on V2.2 and reinstalling showed Install Apps list still advertising v2.2 as well. 
Say I don’t suppose that you’d be prepared to attach most recent version’s files to this thread to enable eager beavers such as I to do a manual, interim update prior to App being automatically updated?
Thanks again for all the valuable, ongoing work.
p.s. FYI my continuing testing concurs with your stated findings on my and other cases.
[quote=“Bulldoglowell, post:24, topic:180668”]The 5 inches of rain today reminded me to let you know all is working very well…
Again, great little plugin, I feel bad having to tear out all that Lua and PLEG I cobbled together to do what your plugin does so elegantly. :)[/quote]
Wow 5 inches, that is substantial.
Thank you, I am glad someone else could use it. Actually I thought what you had seemed to work good, but for me I would have always wondered if it would have set when it really never rained or rained very little.
[quote=“faberoptime, post:25, topic:180668”]Apologies for the delayed reply - adventures elsewhere have kept me busy.
From the read of your latest update to original post, sounds like v2.4 may be cure for my ills - kudos for the rapid updates!
That said, looks like I’m awaiting this to be propagated via Via App update?
I’m presently still stuck on V2.2 and reinstalling showed Install Apps list still advertising v2.2 as well.
Say I don’t suppose that you’d be prepared to attach most recent version’s files to this thread to enable eager beavers such as I to do a manual, interim update prior to App being automatically updated?
Thanks again for all the valuable, ongoing work.
p.s. FYI my continuing testing concurs with your stated findings on my and other cases.[/quote]
Thank you for identifying the problem with personal weather stations. It turns out that when I called the history before it would always get the data from the nearest airport but now with v2.4 it uses the history from the station that the weather underground api returned for the current conditions. This way the api determines the source of the history data. I currently enter the lat long of my house and it should now get the data from the nearest weather station that is online.
One thing that I found during testing is sometimes personal weather stations go offline for a day. In that case you will see a “N/A” for not available.
I used your location for one of my test cases and it worked with no problems. I also did not have to adjust any clocks for the time zone difference. The date is now completely driven by the weather location.
EDIT: Version 2.4 available in app store so attachment removed.
[quote=“blakem, post:26, topic:180668”][quote=“Bulldoglowell, post:24, topic:180668”]The 5 inches of rain today reminded me to let you know all is working very well…
Again, great little plugin, I feel bad having to tear out all that Lua and PLEG I cobbled together to do what your plugin does so elegantly. :)[/quote]
Wow 5 inches, that is substantial.
Thank you, I am glad someone else could use it. Actually I thought what you had seemed to work good, but for me I would have always wondered if it would have set when it really never rained or rained very little.
[quote=“faberoptime, post:25, topic:180668”]Apologies for the delayed reply - adventures elsewhere have kept me busy.
From the read of your latest update to original post, sounds like v2.4 may be cure for my ills - kudos for the rapid updates!
That said, looks like I’m awaiting this to be propagated via Via App update?
I’m presently still stuck on V2.2 and reinstalling showed Install Apps list still advertising v2.2 as well.
Say I don’t suppose that you’d be prepared to attach most recent version’s files to this thread to enable eager beavers such as I to do a manual, interim update prior to App being automatically updated?
Thanks again for all the valuable, ongoing work.
p.s. FYI my continuing testing concurs with your stated findings on my and other cases.[/quote]
Thank you for identifying the problem with personal weather stations. It turns out that when I called the history before it would always get the data from the nearest airport but now with v2.4 it uses the history from the station that the weather underground api returned for the current conditions. This way the api determines the source of the history data. I currently enter the lat long of my house and it should now get the data from the nearest weather station that is online.
One thing that I found during testing is sometimes personal weather stations go offline for a day. In that case you will see a “N/A” for not available.
I used your location for one of my test cases and it worked with no problems. I also did not have to adjust any clocks for the time zone difference. The date is now completely driven by the weather location.
I attached the files that changed in V2.4 so install the V2.2 plugin in the app store then manually upload these 3 files. This way it can be automatically updated in the future. I will remove these files once the new version is approved in the app store. Let me know how it works. There may be more issues.[/quote]
Installed fresh v2.2 sensor via app store then uploaded the three files to Vera - no worries.
WUnderground plugin details correctly pulled over (although not units?), anyhow with no error, plugin had apparently behaved as expected, with valid data shown on data tab and pws noted as source. Sweet! ;D
So looking good and now awaiting rain.
Thanks again for all the work good sir!
Just wanted to report back that v2.4 has been working flawlessly for me just as advertised for days now. Although have only checked it irregularly, have seen both triggered when raining, untriggered latterly and triggered again on a different occasion.
Changing config and update has been working without problem and haven’t seen a lua error reported since (v2.4) installation through multiple reboots.
Now a great, functional complement to the WUnderground plugin.
Top banana blakem ;D
Would it make sense to add the past/current/forecast tempterature to the formula to indicate if watering is needed?
Awesome plugin and thanks for forecast fast fix with v.2.5!
Few suggestions on future development:
- display values in Dashboard plugin interface: total, past & forecast, last pull time
- pull and display all available days, not just threshold days
- separate parameter for each day (…, d-2,d-1,d0,d1,…)
- probability for each forecast day
- multiple stations/plug-ins for averaging/failover between two/several stations
Thanks again!
it took me a while,but finally got what you meant, In SoFla where (HOT therefore RAIN) is the norm, I was in the wrong paradigm. Extended hot weather without rain… may need to add a watering cycle that otherwise you may not do.
you could use PLEG to do that for you; eg. if it records a sensor’s temperature over 90F for the past three days, and today is Wednesday, water today instead of thursday.
Yes, PLEG would work for that. I see a scenario where it hasn’t rained for 3 days but max temp has only been 10C. Probably watering is not needed.
Yes it would, but it is unfortunately not that simple. Equations for calculating evaporation are functions of not only temperature, but wind, humidity and solar radiation. The agriculture sciences have come up with some nice guides on all of these calculations and I started off studying them before making this plugin. In the end I figured I would just keep it simple by only limiting the number of days that I would look at and the moving window would sort of solve the evaporation problem. While it is not perfect I feel it does do an “ok” job at creating a method in the majority of cases to limit irrigation during periods of rain.
In the end you need to know not only how much precipitation falls, but also how much runs off before it is absorbed in the ground. Also some water pools up on the ground and evaporates at a higher rate than what gets absorbed below the surface. Another loss is transpiration of the grass itself, but most group evaporation and transpiration together and call it evapotranspiration.
In the end I might look at adding an option to calculate evapotranspiration so it will essentially reduce the total precipitation over time, which might possibly drop below the threshold. That way you can set a longer period of time and it will better model natural evaporation like a real physical rain sensor. It also could work the opposite way and evaporate more quickly in hot weather which would also be desirable.
This plugin is amazing. Thanks BlakeM!
[quote=“theal, post:30, topic:180668”]Awesome plugin and thanks for forecast fast fix with v.2.5!
Few suggestions on future development:
- display values in Dashboard plugin interface: total, past & forecast, last pull time[/quote]
I had thought about that before, but has not been a priority yet. I went ahead and added the total precipitation to the dashboard and will put it in the next release, but I am not sure there is room to put really any more info without crowding it up.
Not sure exactly what you mean, but I assume you mean display the data for 7 days past and future but only compare to the number set on the settings tab. It could be done, but it would be a big change. Also there is a separate request for each day in the past. With the option to select the number it does give the option of how many requests to generate. Not sure everyone will want it to create that many.
I tried to keep the number of device state variables used to a minimum, but if there is a need to export the data in that form then it could be possible. Right now with a little lua/luup code you can get each individual day from the CSV string.
I don’t think this would be very helpful. I used the QPF since it gives the magnitude of the precipitation, but the PoP has no magnitude. It just states the probability that greater than 0.01" of rain will fall within the predicted period. So it basically tells the certainty, but lacks the amount which is what in this application I think you would want to know. I had thought about multiplying the QPF and the PoP together to give the forecast a weighted value of certainty but I don’t know if that would even make any sense to do that. It was just a thought on how to have a more optimistic approach.
This can already sort of be done now by entering your location by lat long or zip code. It will choose the nearest station online. It is an interesting idea on the possibility of extrapolation by triangulation of multiple stations nearby. It would definitely increase the complexity but should be possible.
Hi, blakem
Thank you for the great plugin. It’s a must for automation of sprinkler systems.
I have a data problem- the first day on which I installed the plugin is showing for Accumulated Precipitation Tue, 5/13 -999.00, Mon, 5/12 T Sun, 5/11 T, for Forecasted Precipitation - Tue, 5/13 0.27 Wed, 5/14 0, for Total Precipitation -998.73.
It will take a big flood to get me over the limit of 0.1 I have set
Is there way to fix the -999.00 precipitation I have showing for Tue, 5/13?
BlakeM,
Thank you!
How about display ALL future days since it’s one call?
I found it extremely useful to have a quick view of week-ahead for my activity schedule.
I see a lot of uses for your plugin beyond just irrigation controller.
My major goal (along with water conservation) is to avoid run-offs by drying soil prior and after large rainfall, so I would need to look at future and past days separately. Also it would be nice to have ability for a single day threshold alarm.
I have not master lua/luup code yet. Do you have an example how to get each individual day from the CSV string? Is it 'ForecastedPrecip[d#]?
Perhaps you can share your irrigation control logic.
Btw, how does Today’s forecast reported? Is it for total 24 hours or for remaining of the day?
Thanks for clarification. I thought of multiplying the QPF and the PoP too. I still think probability would be helpful, for example, if POP under some threshold, I can ignore QPF for that day. If not for irrigation, it would be helpful for activity planing.
Some stations may be missing past rainfall or may not report forecast. Does station selection account for this?
I do see big discrepancy between my three station in 5 mile radius so averaging would be good.
Thanks again for great work!
[quote=“thebgrian, post:36, topic:180668”]Hi, blakem
Thank you for the great plugin. It’s a must for automation of sprinkler systems.
I have a data problem- the first day on which I installed the plugin is showing for Accumulated Precipitation Tue, 5/13 -999.00, Mon, 5/12 T Sun, 5/11 T, for Forecasted Precipitation - Tue, 5/13 0.27 Wed, 5/14 0, for Total Precipitation -998.73.
It will take a big flood to get me over the limit of 0.1 I have set
Is there way to fix the -999.00 precipitation I have showing for Tue, 5/13?[/quote]
Thank you for reporting the problem. I have just fixed it so today’s precipitation value will show “T” for trace amount when the value is negative. It should be in the next release. It was working on past days but not the current day. Unfortunately that only fixes part of the problem so that you won’t see a negative total precipitation.
The other problem is I think that weather station might need service unless there really has been trace amounts of rain for the last several days. Go to the “Data” tab on the plugin and click on the station name in the bottom right corner to look at what values it is showing on Weather Underground. On that webpage you can also click the “change station” link at the top of the webpage to display other nearby station names. You can manually enter the 4 letter airport code or a personal weather station name starting with “pws:” for the location to force the plugin to use a different station.
BTW which station name is displayed on the data tab so I can investigate it just incase there is something else going on.
Thank you, Blakem
You are right, the station that I got based on the zip code ( KTXTHECO9 ) is not reporting precipitation data. After changing the station I’m getting more acceptable readings.
Here is an example that will create a table in lua containing the daily precipitation values. This is just one example and I am sure there are many ways to accomplish the same thing.
[code]function csvToTable(csvString)
local t={}
local i=1
for str in string.gmatch(csvString, “([^, ]+)”) do
t[i] = str
i = i + 1
end
return t
end
–Assume device id of Virtual Rain Sensor is 99
local deviceId = 99
–Get past precipitation as CSV string
local pastPrecipCSV = luup.variable_get(“urn:upnp-org:serviceId:VRainSensor”,“PastPrecip”,deviceId)
–Convert CSV string to a lua table
local pastPrecipTable = csvToTable(pastPrecipCSV)
–Number of elements in table
local tableSize = #pastPrecipTable
for day = 1, tableSize do
–Get past precip for each day
–pastPrecipTable[day]
end[/code]
Well before the API changed, it would forecast QPF for a full 24 hour period. That made it very simple so I could just take the max value of the accumulated precipitation and forecast precipitation for the current day since the time periods overlapped exactly. Now the forecasted precipitation is only for the time remaining in the day so it is just added to the total. I don’t think this is quite as good but it is what I got. I actually found I could opt not to use this new best forecast and use the old method, but I am sure the new model is more accurate so it will probably be better in the way of accuracy.
I have thought quite a bit about how to improve the rain detected decision for forecasted precipitation, but after you posted this I looked some more and found something that does make a little sense. As stated before I don’t think the PoP alone is what you are interested in and the QPF alone only gives the total potential without any certainty. With a little math you can determine the PQPF(Probabilistic Quantitative Precipitation Forecasting) from both the PoP and QPF. This combined approach will give the probability that a rain total of a given amount will occur. This way you could make the decision it will rain when the probability that 0.25in or greater of rain will fall is over a 50% chance. You would still need these two values of the precipitation amount to exceed and percentage threshold to trigger rain condition, but this is the only other way that makes sense to me. For right now though I think I will leave it the way it is since it is quite simple how it works now. If I add this logic in the future I will make it an option to use the probabilistic approach or simply add the QPF to the total just like it does right now.
An article describing this type of analysis.
[url=http://www.srh.noaa.gov/tsa/?n=pqpf_explaination]http://www.srh.noaa.gov/tsa/?n=pqpf_explaination[/url]
[quote=“theal, post:37, topic:180668”]Some stations may be missing past rainfall or may not report forecast. Does station selection account for this?
I do see big discrepancy between my three station in 5 mile radius so averaging would be good.[/quote]
No it does not. The API actually decides the closest station. It may be possible to add logic to check for this in the future, but I would have to know what to be checking. All I can say is pick the best one you think is the most reliable. In my location I have several weather stations within a few miles and I do see differences, but it from the type of isolated storms that move through here. I have seen nearly an inch on one station and just a few hundredths on another only 2 miles away. I verified with radar data that the other site was right on the edge of the line of storms as it moved through so that is one reason this plugin will not always be 100% accurate unless the weather station is in your backyard. I personally have not seen any trend that one station is more biased, at least not for the amount of precipitation, but I am sure it is possible. I have seen that some stations do become unavailable from time to time.
In the case that a station was offline in the past then it will display “N/A” for that day. If there was rain that day it will just not be included in the total. So it may show no rain when there really was rain. From a water conservation point of view it might be a little wasteful, but not critical in my view. My worry is a case where it detects rain and when there is not sufficient rain causing it to suspend irrigation when it shouldn’t.