I've always thought of this driver as the one for people with a PWS that reports to WU. It's fantastic for that. It seems there are other services and, I suspect, drivers for those that just want "generic weather" without having a PWS. But that's just my two cents. If the functionality isn't harmed for PWS users I guess it's no big deal either way. I just appreciate all your effort on this.
1 Like
That was certainly the intent.
It wouldn’t be, but the feature set for those without a PWS would be much more limited.
I've released v6.8.1 which works without a PWS ID entered and limits ppl to the basic HTML Forecast Tiles. It also substitutes the Station Location for "Home":
Thanks for the update, Derek @dJOS . I'm noticing odd behavior for certain tiles/values and wonder if perhaps the app is not picking up the right data (or not picking up certain values at all, now). Specifically, my rainyesterday shows 0.01") and raindaybeforeyesterday (shows 0.04") tiles are showing inaccurate data, while the htmlraintile data (no rain for any of the past 7 days) is correct.
When I look at the tile history for rainyesterday or raindaybeforeyesterday, I don't see that the app is picking up those values now. Thoughts?
Thanks, and hope all is well.
1 Like
Hmm that is odd, are you on 6.8.1?
It looks normal for me, however I run metric units. I might have to defer to @swade to confirm imperial units are working. The math is likely a lot harder.
Ps 6.8.1 doesn’t change anything other than add logic to detect a station ID and skip big chunks of code if it doesn’t find one.
Yes, on 6.8.1 and 2.3.140 for hub. No idea what's going on, but my rainyesterday and raindaybeforeyesterday tiles are just stuck at 0.01" and 0.04" respectively, which is wrong (fantastic weather here through tomorrow - we all think we got transported to Palm springs or something. No rain and temps like early summer) . Data from the station seems fine (except that my anemometer is broken - replacement ready to be installed - but that shouldn't matter). Rain tile data is fine. I wonder if WU just stopped reporting those two, or if getting the data for the other precip values could be messing with it? Anyway, I'll try deleting and re-adding those tiles. If that doesn't work I'll just delete them as the rain tile is all I really need. It's just odd...
Thanks!
@Madcodger rainyesterday and raindaybeforeyesterday are no longer being updated. Those values were using code that could report not accurate data. I found that WU keeps the PWS rain history and I was able to extract the last 7 days
Please use precip_Yesterday and then precip_Last3Days (should be the last 2 days and anything so far today). Hope this works for you.
If you need the day before yesterday's percipertaion we could report it as a single attribute.
Have you looked at the new Rain History tile.
2 Likes
UPDATE:
- v6.8.2 - Removed PWS Optional functions - it was causing some odd issues that I couldn't track down. Sorry for anyone using it, it's just too troublesome to maintain due to so many subroutines relying on the PWS ID.
I also added Driver Version reporting so folks can more easily tell which version they are using.
1 Like
Thanks, @swade . That's good to know. I just deleted those two tiles and am now using precipyesterday and the rain tile. Works perfectly and does all I need.
1 Like
I have the same issue here in Ohio but only since last night. WU is only returning 6 days of history and the current code did not expect this condition. I just saw the errors and was not sure if it was the PWS I am using or a WU issue. If you look at the debug line 7DayRain: [null, null, null, null, null, null][0] you will see only 6 values were returned from WU.
I have seen this on my system before but only once or twice right after midnight when the new day starts that is most likely delays in syncing with the PWS. I have been testing some code that now handles it and replace the missing value with a zero.
I will keep an eye on the WU issue of not reporting all values and hope just like last week they resolve the problem and get it fixed.
I will get an update to @dJOS today that will at least prevent the error and report it as a warning so rest of the code continues to work.
1 Like
Copy, I have commented out all the Day 7 code. I don't need it. EDIT: I set day 7 to 0 and commented out everything else day 7.
OK. From what I recall the 7 day value is the current day rain, which I like to know as the day continues to rain.
I send @dJOS my new changes and hopefully he can get them out today.
1 Like
v6.8.3 has been released with the fixes by @swade
Btw, the driver version has been moved to a Tile in the preferences section:
Updated to v.6.8.3 and its gone from throwing one error to another.
Above the green line in the image is what it is doing now.
This DH is moving along nicely. I have made a modification I want to share. I have a remote cabin with a PWS, but the forecasts are using my local hubs GPS coordinates. So I made a mod to input custom GPS coordinates so it doesn't use hub location. Maybe you can add it.
1 Like
Hehe, it used to be manual but I decided it was redundant due to the hub already having that info.
I’ll make it optional to use the hub location or manual location.
I already have most of the code so not hard to implement.
1 Like
Hmm, that looks more like a WU issue than a driver issue. I’m not seeing that ATM but I’ll retest.
Several have reported this where WU is not returning all rain history values. A WU issue for some of us and I don't know why.
The new code makes this now a warning and allows rest of the app to work by defaulting a zero as the day 7 value.
I have seen this on my system before but only once or twice right after midnight when the new day starts that is most likely delays in syncing with the PWS. I have been testing some code that now handles it and replace the missing value with a zero.
I will keep an eye on the WU issue of not reporting all values and hope just like last week they resolve the problem and get it fixed.
I suspect it's the way some systems upload data (or dont) when there isnt anything to report.
EDIT: eg here are 2 PWS's - both report "0" when there is no rain - but both show "null" for UV because they dont upload this data.
I suspect that if @an39511 used the below query with his credentials (Firefox formats it in human-readable form), he would see "null" instead of "0" for the precipTotal.
https://api.weather.com/v2/pws/observations/current?stationId=<PWS_ID>&format=json&units=m&apiKey=<API_KEY>
I would be very interested to see if my theory is correct.
