UK is no longer fixed to Uxbridge, it is now based on Hubitat's latitude & longitude for that weather service (this did not affect other services). This was an error on my part in my testing so long ago as it was an easy place for me to recognize and ask people about the weather there for confirmation, but I forgot to switch it back before posting it. Thanks to @guy2 for pointing this out.
Changes to ProcessEvent and driver update checking portions. Nothing really significant, just making them more in line with my "current" standards for my drivers since this one had apparently not seen any updates at all last year.
The driver uses the location reported by the Hubitat settings to request weather, so entering a zip code is not necessary.
OW should report Today_MinTemp and Today_MaxTemp for the min and max but for some reason it is not (it IS in the data still, I checked on mine).
The 1h error is because they used to have a "rain" item that had a "1h" sub-element that then returned the amount of rain (in mm). However, they appear to have removed that so it is failing (OR it is not reported when there is no rain currently, not sure which because it still shows in the API reference but does not get returned for my device anymore).
UPDATE:
Making a major rework of the section (Forecasting WAS handled but just differently than I would do it now). Maybe not my best idea, but doing it anyways. Should handle #2 & #3 once I post it.
UPDATE #2:
Major rework cancelled... I started it, but then realized that the 1h is what was causing all the forecasting to break. It was not that it was "bad" just the code stops on an error so everything after that does not get handled. I fixed that piece (it checks if rain exists now and THEN for the 1h piece). Updated version should be published in a few minutes.
A check is now performed to see if there is any data for rain returned from the OpenWeather (OW) API before it checks to see if the 1h field is returned. Apparently a change was made and rain may no longer be provided (maybe if it is not raining, not sure). But in any case, because this was not provided the test for a sub-field to it "rain.1h" of course failed with an error, which prevented all further data processing from occurring. This made it so all the further expected data was not provided for OW calls nor any of the forecasting children being populated. Thanks to @Busthead for pointing out that an error was reported so this could be resolved.
Good to hear. I rarely touch most of my drivers once they are basically working unless someone lets me know of a problem, feature request, etc... so if you run into anything or think there might be a good addition, let me know.
That is correct. The NWS forecast used does not provide a value that was "meant" for that so I do not have an output for it. It only provides one temperature per time period in it's forecast.
Okay, looks like the driver is exposing properties that aren’t actually set. This results in null values being assigned to variables by rules and errors when attempting to work with those variables.
Yes, it exposes attributes that may not get populated because Hubitat does not have dynamic attributes or capabilities. So if you do not add them in to begin with you cannot use them for Events at all. If you add them but do not use them (maybe you have a driver that supports multiple things...) they just have null values.
Yes, if you leave the device page open you will get listings for every refresh. In fact, it can repeat for ANY event that has a space or some other special characters in it's name (such as the displayed "Data as of"). This is only a visual "glitch" of the page. If you refresh the page, they disappear. If you are using something for the event values it only has the real (most recent one). This is a bug/"working as expected" by Hubitat as a result of the groovy code. They would need to do a lot of workarounds to handle it. So in a sense, it is also my fault because I use more user-friendly event/attribute names. I am correcting this on newer drivers, but if I replaced them wholesale on my existing drivers it would cause people issues.
I will look at what is coming back and see about adding illuminance. I already have a new version to publish anyways so maybe I can add this in tonight. UPDATE: I do not see any illuminance or other related value displayed in the data returned from OpenWeather. Their API documentation does not mention anything with lux, lumens, or anything that I could convert from what I can see.
"@bangali for his the Sunrise-Sunset.org code used to calculate illuminance/lux and the more
recent adaptations of that code from @csteele in his continuation driver 'wx-ApiXU'."
I did look at that driver in case I was missing something. But I am not sure how accurate that illuminance would be since it appears to be calculating it based on the sunrise/sunset and cloud cover. If it was just coming back from OW I would happily add it... but that seems like a bit of stretch. It is not as straightforward as a "feels like" or windchill calculation.
It's a strange calculation, for sure. The assumption is that the sun is a constant value luminance and things subtract from that. Sun angle plays a big role obviously, (day/night/noon) but cloud cover is very subjective. Just how much light is being subtracted by that specific cloud? I 'improved the code' -- your turn
Have you found it to be reasonably close? My area is in the top 10 cloudiest cities in the US... so it is always a mess.
I do not rely on any of the weather stations I have for exterior illumination values (I use my main Homeseer FLS100+ when I need an exterior light level) despite having 2 weather stations AND more than 5 weather API devices (the problem with having written the drivers for so many).
Amusingly enough, I really do not care much about the weather. The only Rule that uses a weather station is if the wind gets too high for our Christmas inflatables. Since those are now off, that Rule has gone away.
Good afternoon and happy new year everyone. @Snell, thank you for the excellent driver. I'm trying to use the Met Office API for Ballynahinch in Northern Ireland (UK), but the Met Office has updated the DataHub and DataPoint services and I cannot find a way to conifgure my API for a site-specific location, i.e. where I live. I have obtained an API Key and Client Secret and logged it on the WSM4 Device. It is polling data, but I'm not certain if it is for my location or not.
Has anyone else experienced this or have any advice?
I 'improved the code' -- your turn 
I use weather for EVERYTHING:
