Update MPH conversion for Typo #15
Conversation
Conversion rate had a typo
Allows for more accurate value to be passed where this value is readily available from weather provider
Added mean_daily_temperature to the function - Need to update the call - Mean daily temperature is not available on forecast so "None" is provided Actual Daily Average is available on Observations/Summary
Given it takes 2 API calls for current observations (observations and observations/summary), we need to relax the number of daily calls to be under 1000 These amounts bring you to 960 calls per day.
For use in calculating Actual ET0 based on actual weather of the past day Note. UVI was duplicated and already works properly at node "UV"
Changed layout to be in a logistical order so that ETo input values are available in display for users to "reproduce" if they want to understand how the ETo values are affected by the inputs. Grouped similar variables so people could identify daily avg vs current observations. Due to the number of variables in the observations, some of them are cut-off at the bottom of the screen. Moved non-critical amounts to the bottom. A discussion has been started at UDI forums to see if a Vertical Scroll bar could be added to the Admin Console. Also added Min/Max Humidity to Forecast [already had min/max temp]
All variables were previously not getting data or used elsewhere in interface
Changed Precision for current observation as it is simply an avg of the Max/Min values Having the Max/Min values available allows for better understanding of changes to ETo
Correct Syntax error on a Filter vs a Parameter for filter "prercise" Remove selection of fields filtered when pulling observations/summary - need most of the fields now for ETo calculation
Note: Observations/Summary has some field names that differ than Observations; created new tags with _summ appended for those who could be confused with other fields
For use in ETo Actual calculation
Improvements - Actual Average Wind Speed (instead of average of Max/Min observed/predicted) - Uses Actual Average Solar Radiation if that value is provided by AERIS - Otherwise reverts to prior logic to calculate an estimated SoRad - Uses new parameter for Actual Temperature Average as observed throughout the day from AERIS instead of a simple Average of Max and Min - All used Variables are recorded to Debug Log to help in troubleshooting -
Display all items which appear in AC in the order they appear Also closes Ticket 14
|
This is part 1 of many parts I have done to establish ETo based on on actual values from Aeris. This has been tested over the last week, and has been working well. It is utilizing more accurate observations, including ACTUAL Average WindSpeed and Average Observed Temperatures. I've also added Solar Radiation into the mix. You'll hopefully be able to see what I'm up to by the changes. Do you happen to have AERIS API access so you can also test this and see how it looks on your end?? |
Note: No lines were deleted - This shows all values being created are previously not used
|
ETo based on actual daily observed values
|
|
I hope I reproduced all the changes I have in my repository over the last week. My master Branch is my current running and tested model on my Polyglot. After accepting my pull requests, I don't know if it is possible to "compare files" to the master branch of my repository to see if anything was missed (of significance other than formatting) https://github.com/CompKingCanada/udi-aeris-poly I hope this saved you a ton of time, and will be helpful to anyone who runs a PWS and wants accurate ETo |
Add new Drivers for Current Observations Nodes
Upgrade ETo calculation to accept Mean Daily Temp
Update call to ET0 for new Paramater declared
Change default poll interval/not exceed free tier
Clarify Descriptions of Node Values
Re-purpose unused variable
Update Layout logistically for new variables
Update UOM for new variables for Eto Actual
Update Summary Obs For new Humidity Variables
Prepare for new ETO calculations
Add mapping for new AERIS data being utilized
Create/Log creation AERIS daily summary data
Utilize ETo function to be based on daily actual obs
Update Documentation for new ETo drivers
|
Ugh. When I merged my local branches after I sent in the individual pull requests, it appears that I also merged all the pull requests into this pull request . I meant to keep them separate. If needed, I can cancel this pull request and create a separate one to replace it. This pull was supposed to be only a change to the conversion of MPH to m/s.. The remaining code changes are already handled in other requests. File: ET3.py from: return mph * 0.477 |
|
First, thanks for adding that feature! I took the liberty of creating a new branch and doing a little bit of re-organizing the commits. See the current-eto branch, the end result should be pretty close to your tree. I'm not real sure what the addition of the various merge requests that got added to the pull request do so I thought it best just to apply your commits one-by-one to a branch. I do want to discussion the design a bit before merging this into the master branch. The one thing that bugs me a bit is that the ETo value isn't really right/useful until the end of the day. Same goes for the min/max values. You're leaving it up to the user to realize this and not rely on those values at random times during the day. I know it seems like common sense, but.... My initial thought for doing the actual ETo for the day, was to collect the required values during the day, but do the calculation only once, at the end of the day, maybe even reporting it as "yesterday's actual ETo". That wouldn't involve creating all the new node values. I think it's at least worth a bit of discussion. |
|
Thanks Bob. I'll do a review tomorrow morning, and compare the results with your code vs mine. I would have liked to put the Max/Min/ETo calc's into a separate Node perhaps labelled something which distinguishes it from "Current" observations, but I don't have the skills to create a whole new node without breaking the code. Perhaps a node labelled "Daily Extremes"? This would at least isolate the values from the current observations so they aren't grouped together and misunderstood. Would also get rid of the display issues because too many drivers are in the same node. Max/Min values are still "accurate" as they represent the extremes observed at that point in the day. Thought they will change, I still consider these of value. I do agree though that calculating ETo using partial day data is "not accurate" and could be misleading [Side note: Just purchased a new PWS which includes Solar and with this it now charts an ETo value throughout the day. I don't really know why, and I only installed it today, so I haven't figured out what it's up to yet.. But someone apparently thought a mid-day ETo calc was of value to chart it. This is what WD has for a feature, apparently] ETo value shown for the current day could be based simply based on the prior day observations/summary (Label: ETo yesterday?). I believe this data is available with the license available to PWS stations (no more than 24 hours of history, but day -1 should be available throughout the entirety of day 0. Basing ETo calculation on Actual Observed results is the desired state. I don't think being one day "behind" is an issue. All one wants is for the cumulative summation of the daily ETo values to be based on actual station observations, not forecasted ones. Just some brainstorming. I'll sleep on your comments and see if there is something I can come up with that "makes sense" |
|
Once concern between having some summary data was having ETo based on "yesterday" values for a complete day, and then some current day max/min values being available for current observations may require 2 API calls.. After review of the documentation, and some testing, it appears the API allows us to poll yesterday summary and today summary in the same API call, so we won't be increasing the API calls with his. Append the following to the API call results in this: &from=yesterday&plimit=2 |
|
I wasn't concerned with the number of API calls, it's more about publishing data to the ISY that isn't really useful. The ISY has limited network connection resources and every value that is pushed to the ISY uses a network connection (this is how Polyglot is currently designed, not the node server). These weather service node servers are already sending a lot of data each time, so I'd like justification that the data that's being pushed is useful. Maybe there's some value in incremental ETo for incremental irrigation. And I say maybe because it's not clear to me that the intermediate (non-full day) values are actually valid. I.E. if I calculate ETo every hour and add them up will I have the same value as what I calculate at the end of the day. I've been thinking about it, and I haven't been able to come up with any way to make use of intermediate high/low values for temp, wind, humidity. They might be interesting to chart, but the ISY isn't used for charting data. What control decisions would make sense for a high temp at noon when it's likely to continue to getting higher for a few more hours? It's not hard to come up with cases that use predicted high/low values but what can make use of historical high/low values? Collecting the data internally in the node server and doing the calculation at midnight is what makes the most sense to me. I'm willing to add additional node values (or create a new node, it's not hard) if you can justify the data with a use case or two. So here's my thoughts on the options we have available:
|
|
I haven't forgot about this. Just preparing to head out for a little visit to my parents out of town. Be gone for Memorial Day weekend. I'll get back to you in a week or so. |
|
A couple thoughts. (Hasn't been a priority lately as I have it running locally with the code changes, and it works well for me) AERIS users are the "Elite" as they are the ones who have paid or run their own weather stations. I believe that these are the types of people who would like more data instead of less data. Also they wouldn't be as easily confused as they would have better knowledge of the technology. Since this Poly isn't the "publicly available" set of data, and AERIS has the data so readily available for query, it seems silly to query these values to come up with an accurate ETo calculation, and then discard them. Use Case:
Still trying to wrap my head around the mid-day calculation of ETo in Weather Display and how it can be used/compared to your calculations. Haven't been using it much as we haven't had any rain here for a while, and for that matter winter is coming up quickly. I'm not really motivated at this point to publish the changes, as it is working fine locally for me. Perhaps put this out for public discussion. Personally, to better understand ETo in general, it is nice to see the mid-day ETo. Gives me (if the rest of the day was just like now, what would ETo be end up being - So I can see that Extremes are being properly reflected in the ETo as they occur]. Or this could just be a bias as I spent time getting us this far... I guess the key question would be IF we had an Actual ETo valued based on Yesterdays Actual observations available would I care about the rest of the data?
Best Case Scenario? Perhaps a new node "Yesterday's Actual Values" which includes an ETo calculation and all the Max/Min/Avg values. This data would be available for use easily with a small change to the current API call I already developed/tested for current day observations. Yesterday's Data can be pulled once or multiple times since it should remain static. Having a "just before midnight" trigger wouldn't be useful if the values are lost on a reboot of the server. So then the question is going through the effort to declare and use drivers for these new values to pull into a new node for "Yesterday", you may as well use the same drivers for a "current day summary" observations node. This gives your advanced users the most flexibility, and better utilize the data that AERIS is charging some people $80/month to get their hands on. |
Conversion rate had a typo