Anyone using the PWS parser with Weather Display?
Wondering if anyone with a PWS is using the PWS parser along with the clientraw.txt file that WeatherDisplay generates.. I've been using WD for about 5 years now, and have a website where that file is updated regularly. I also have a station on WeatherUnderground and upload data there. I did not want to use NOAA and WeatherUnderground because the WU parser pulls forecast data from WU in addition to station data, and WU tends to forecast rain a lot more often than NOAA. So instead, I switched to using NOAA and the PWS parser -- pointing the PWS parser to the clientraw,txt file on my web server. Its pulling station data from there, so all appears well.
However -- when I switched -- my program changed my next program run is set to really high percentages -- 174% -- but Sunday dropping back down to 51%. Switching off the PWS parser and WU back on brings that down to 74%.
Wondering if anyone else using this parser has seen something similar when first using it.
Thanks,
Rick
-
Ive attached two graphs between using PWS and Wunderground. Also, after looking at the PWS parser, here is the current data the parser is extracting.. One thing I was unsure of was in the PWS parser, there is a solar conversion that is supposed to convert w/m2*h to Mega-Joules/m2*h...Im not sure if the conversion is correct there or not -- at the top of the parser where the script does the conversion, there is a comment that "needs to be converted from watt/sqm*h to Joule/sqm". However, at the BOTTOM of the parser, there is this note: "SOLARRADIATION = "SOLARRADIATION" #[megaJoules / square meter per hour]". The clientraw.txt file has the value reported in w/m2. Here are the current values extracted:
004 Temp C: 28.0
047 Min Day Temp C: 20.9
046 Max Day Temp C: 28.4
005 Outside Humidity %: 70
164 Daily Low Humidity %: 68
163 Daily Hi Humidity %: 98
001 Avg Speed kts: 3.5
127 VP Solarwm w/m2: 735.0
007 Daily Rain mm: 0.0
072 DewPoint Temp C: 22.4
050 Baro Trend hPA: 0.2
048 Icon Type: 18 (Overcast)And here are the two graphs I get -- first with WU, second with PWS:
And here is with PWS:
-
Yes, solar radiation can greatly affect ET, it might be better to disable solar radiation for a while to check how it behaves without.
For this you will need to either directly edit parser code by using ssh to login to device and edit it in /rainmachine-app/RMParserFramework/parsers/ or upload a new one
by starting from original sources here: https://github.com/sprinkler/rainmachine-developer-resources/blob/master/sdk-parsers/RMParserFramework/parsers/pws-parser.py
Make sure you:
1. Rename the file before uploading from pws-parser.py to something like pws-parser-nosr.py
2. Rename the class name: class PWS(RMParser): should be class PWSNOSR(RMParser):
3. With the above change this function:
def isEnabledForLocation(self, timezone, lat, long):
return PWS.parserEnabledbecomes:
def isEnabledForLocation(self, timezone, lat, long):
return PWSNOSR.parserEnabled -
Thanks. But, there are two issues here. First — the solar data from the WU parser is the same solar data from the PWS. I’m using my specific WU site (KNYFARMI10) — and with that, the ET doesn’t spike up in the beginning. The PWS parser is pulling the same station data, so why the discrepancy?
Second — I can’t seem to upload modified parsers after changing class names, file names, etc. when I do, I just get “Error uploading xxxx.py”. I’ve tried turning debug logging on to see if the log sheds more light, but it doesn’t. If I could modify the WU parser so that it doesn’t pull forecasts at all, or if I can limit those forecasts to maybe 3 days, I could probably use that as well. I’m on Long Island in NY — forecasts for QPF beyond 2-3 days are generally not reliable. Using the WU parser now, the RM sees a rain event on the 7th with 0.7” QPF, and knocks my programs down too much.
If I could resolve the upload issue, I’d be in a better place.
-
For upload make sure you are connecting directly to your device IP address for the web interface instead through https://my.rainmachine.com. There is an upload limit through remote service.
-
So the error that is being logged is:
2017-08-03 08:09:29,482 - ERROR - rmHTTPResourceApi4Dev:68 - API:ParserUpload: Missing required headers
You can view what I'm trying to upload here: http://www.indigopc.com/misc/wunderground3-parser.txt (Note -- its saved as a .py file when I'm trying to upload. Just renamed it for my web server)
-
Hmmm.. Mine is throwing a 400 Bad Request. Additionally, I notice the version of the web server running is different than yours.. My request headers are somewhat different as well.. My firmware is 4.0.900.. Im running an HD-12 Gen 2.
Does my unit have some sort of half-baked firmware on it? Its brand new -- just got it on Tuesday direct from Green. It is not registered for the beta channel, and it shows no updates available. I thought I remember seeing at some point in the past, one of the updates had a fix for relaxing the MIME type rules because some users had issues uploading..
-
OK... Just tested from a debian VM on the same network with Firefox. THAT works. I've tried several flavors of Windows (10, 7, Server 2008R2) on other networks, as well as my own. It seems any attempt to upload it from Windows fails.
The only way I can get it to work in Windows is if I modify the content-type header to text/x-python and resend (just tried using the inspect tool in Firefox)
Not sure why all the Windows machines are not sending a content-type.
Rick
-
OK, well thats obnoxious.. I found two workarounds.. I was able to fix it by adding a new MIME type in the Windows registry to figure out what a .py file should be.. Chrome & Firefox on Windows use a pretermined list of MIME types, and if its not in that list - it defers to the Windows registry. It would seem if it then finds nothing in the Windows registry, they will not send a content-type.
Alternatively, you can also change the extension in Windows to a .txt file instead of a .py. The browser will set the content-type to "plain/text", and the RM will accept that.
Nicholas -- thank you for all your help in trying to narrow down what was causing this to fail.
Please sign in to leave a comment.
Comments
15 comments