Thanks.
Only ask as i got an email from OWM stating i was far exceeding my free account api calls..
Just trying to work out how!
Whats your polling time set to.
I have used a daytime polling intervals of two (2) minutes and a nighttime polling interval of 15 minutes. Conservatively, that should be approximately 18 daytime hours x 30 polls per hour = 540 polls plus 6 nighttime hours x 4 polls per hour = 24 polls, or a grand total of 564 polls per day. A little more than half (56%) of the of the '1,000 calls per day free' limit. I chose to do this so the Lux is quickly updated during daylight hours, and the frequency is reduced when Lux is not as important (nighttime).
Thanks for the good reference from the OWM site. I agree that polling more often than the site has updated data is not meaningful. Different locations do appear to have different update internals (how often OWM refreshes their data). The location I poll does appear to update more frequently than 10 minutes (however, it has been several years since I have validated that). Since I am staying well below the 1,000 polls per day I have not checked it recently.
I wonder if your issue is the night schedule is not kicking in as there are issues with sunset time. Check the logs. That would explain you exceeding the 1000 per day.
No one has reported any issue on this. There were issues with the Sunrise-Sunset.org poll in general failing, but that has been removed from the driver. No issues reported since that happened.
I have mine set for 2mins daytime and 2 minutes night time.
So really, it should be 30 polls per hour x 24 hours = 720 polls per day/24hr period. Still below the 1000 call Limit
Not.if it is failing and retrying.
Good point!
I've been using the OpenWeatherMap driver since switching to Humitat from SmartThings. I have my latitude/longitude set correctly, and for the most part, the weather is generally reliable and matches other sources of weather that I can retrieve for my location. However, I have several variables that randomly seem to report incorrect during some data refreshes. For example, my Ecobee thermostat was announcing to open all the windows at home since it thought the weather was favorable, but it was not. This was followed soon after by a message to close all the windows. In looking at the weather device event log, I can see that the dewpoint was hovering in the upper sixties all day, but for two isolated moments this morning, it got reported in the low fifties which triggered some of my automations. Any knowledge about what causes this or how to fix it?
Same thing happened yesterday too where several data refreshes pulled inconsistent data, and then it returned to normal again.
The driver just reports what it is provided by OWM. If OWM provides inconsistent data, then this driver will reflect that. Like most weather data providers, OWM pulls data from many different sources, some of those are personal weather stations that may not be be that reliable. If the area you are polling for has limited sources to gather information from, and those sources are not consistent in either frequency of reporting or data consistency, then OWM results may reflect that inconsistency.
Thanks, Matthew. Definitely not a driver problem, I know. That driver is awesome! Didn't know what options I had with OWM to refine their data or pick which reporting stations correspond to my longitude and latitude or other strategies to prevent a discrepant value coming through to trigger non-sensical automations. I also considered perhaps taking a median or average value over time and then connecting my trigger to that calculated value might be a way to skirt the problem, but I'm not sure how to accomplish that level of fanciness in webcore either. Truthfully, I would love to solve the problem at the source instead. I'm in a smaller suburb outside of Chicago, so I'm typically used to some pretty consistent weather values, so I haven't experienced this problem in the past.
1 Like
Is there a possibility of adding AQI to the OWM pull? I see someone has a separate driver for it, but it would make sense to integrate as long as you are already pulling the data.
IIRC the AQI is only in the secondary set.
Yeah, on looking at the API, I noticed that it was a separate call and would be better served in a separate driver as not everyone needs that kind of information.
I will modify and update the driver I found at that link. (It only pulled a single level, I wanted the PM2.5 I will add and post.)
1 Like
Hi Matthew,
I am little puzzled, I am in the West Coast. Sunrise here is around 6:40am. Usually, it's shine and bright after 7:45am here. But Openweather device won't show "illuminance" Lux value until after 11pm or sometimes noon. Is there anyway I can make it to show the Lux value earlier? (My polling schedule is every 10 minutes)
Thanks in advance.
The driver calculates a LUX value and reports it as 'illuminance'. That attribute value is reported in the Current States.
The driver does not have the ability to report, or not report, attributes only during certain times. Standard attributes are reported/updated (in Current States) at your selected polling intervals. Any optional attributes will only report/update at your selected polling intervals if you have turned them on.
Suggesting that the driver is somehow only reporting illuminance after 11:00 AM makes no sense to me? It does not work that way. Perhaps your hub location is not set correctly, or you are using the optional 'Override Hub Location Coordinates' feature and those are not correctly set for your location? The driver does determine your sunrise/sunset times based on your Hub location. 'illuminance' is a calculation based on sunrise/sunset times (among other factors). If your coordinates are off, then your illuminance calculation will be off too. The fact that you do not see illuminance until later in the day suggests that the coordinates are set to something west of where your hub is located. If that were correct then I would expect to see elevated illuminance numbers immediately after twilight ends too.
Just want to report here that the driver is indeed working and it does show the lux value but not showing in earlier log. Matthew helped explain that limiting the retention of the events on the weather driver because they report so frequently.
Thanks Matthew for your help.
2 Likes
I would like to second someone earlier who said that this driver was their favorite. I completely agree!! I've customized the 3-day tile for my Dashboards and the driver has worked perfectly.
I would like to use TTS during a Goodnight routine to speak tomorrow's weather using forecast_text1, forecast_low1 and forecast_high1. I see that forecast_text1 is exposed a Device Attribute however the other states are not. Is it possible to expose more/all states as Device Attributes for use in other areas of Hubitat?
