Wunderground sensor with alerts exceeds API limits

[arsaboo]

Home Assistant release (hass --version): 0.31.1

Python release (python3 --version): 3.4.2

Component/platform: Wunderground

Description of problem: The PR #3505 by @tchellomello to add alerts to Wunderground sensor, essentially doubles the API requests. It seems that the alerts are requested through a separate call, hence doubling the number of queries made to Wunderground.

I added alerts to my configuration yesterday and immediately received an email about exceeding the allotted usage.

Expected: The sensor should limit the calls to 500 per day.

[tchellomello]

Hello @arsaboo, What is the interval you have for this sensor? How many entries to you have on your wunderground sensor? Could you share you conf?

On my I have this:

- platform: wunderground
  api_key: !secret sensor_wunderground_api_key
  pws_id: !secret sensor_wunderground_pws_id
  monitored_conditions:
    - weather
    - temp_c
    - heat_index_c
    - dewpoint_c
    - wind_kph
    - UV
    - precip_today_metric
    - relative_humidity
    - alerts

Here is the report of binding that I've doing by day.

[arsaboo]

Here's my config:

  - platform: wunderground
    api_key: !secret wunderground_key
    pws_id: !secret wunderground_pws
    monitored_conditions:
      - weather
      - temp_f
      - pressure_in
      - wind_string
      - relative_humidity
      - alerts

Here's my report from Wunderground:

There are two separate requests - one for alerts and the other for the everything else. Given that MIN_TIME_BETWEEN_UPDATES = timedelta(seconds=300), this should translate to roughly 576 calls per day (which exceed the limits of the free plan).

[tchellomello]

@arsaboo yes that makes sense, however I'm not sure why I have less requests since I keep it running all day long.

To address the issue we might need to change the MIN_TIME_BETWEEN_UPDATES from 300 seconds to 360 seconds. This will bring each request from instead 576 to 480.

300 seconds -> 5 minutes --> 12 reqs per hour --> 288 reqs per day --> combined 576 reqs

360 seconds -> 6 minutes --> 10 reqs per hour --> 240 reqs per day --> combined 480 reqs

We can make it dynamic and address it on the documentation. We can do a test to verify if alerts is enabled. If so we can set MIN_TIME_BETWEEN_UPDATES to 360. If not, keep it as 300.

What do you think?

[arsaboo]

I like the dynamic approach - increase the update interval if alerts is enabled otherwise keep it at 300.

Although, I am thinking if we need to request alerts every 5-6 minutes? Unlike other weather conditions, alerts should change less frequently. May be we can reduce the update frequency of alerts.

[tchellomello]

@arsaboo that is a good point was well. We can do it every 10 or 15 minutes. Doing each 10 minutes we will have 144 reqs for alerts and 288 for conditions which combined will be: 432 reqs.

That will open some room for eventual restarts during the day. Let's do with 10?

[arsaboo]

10 minutes is fine. If we want to be little conservative, we can even do 15.

[tchellomello]

@arsaboo Let's do 15 then. I'll get a PR for that. Thanks for bringing this up.

[arsaboo]

:+1:

[RyanLehms]

I would caution against a 15 or even 10 minute polling period with the alerts, given the average lead time for a tornado warning is only 13 minutes. Obviously, we shouldn't be relying on WUnderground and HASS for this information, but this effectively renders the warnings piece useless. It would still be fine for Watches issued by the NWS.

[arsaboo]

15 minutes is the worst case scenario. Further, as you rightly point, HASS (or for that matter, anything less than a real-time weather watch) is unlikely to help much with a 13 minute lead time.