OpenUV API Errors

[jhemak]

The problem

Is it possible this error is caused by something other than the API limit actually being exceeded? I have been receiving it occasionally and do not believe I am exceeding 50 queries per day.

2024-04-05 13:20:06.566 ERROR (MainThread) [homeassistant.components.openuv] Error fetching uv data: Error while querying uv: Daily API quota exceeded. Add billing details to get 15000 reqs/day or contact [email protected] to upgrade to Unlimited Plan.

What version of Home Assistant Core has the issue?

core-2024.4.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

OpenUV

Link to integration documentation on our website

https://www.home-assistant.io/integrations/openuv/https://www.home-assistant.io/integrations/openuv/

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @bachya, mind taking a look at this issue as it has been labeled with an integration (openuv) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of openuv can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign openuv Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

openuv documentation openuv source _{^{(message by IssueLinks)}}

[jhemak]

If this is still true, then maybe I am consuming twice the requests that I think I am? I am not using binary_sensor.openuv_protection_window and would happily disable it if that would eliminate 50% of the requests being made.

alias: "Update OpenUV"
description: ""
trigger:
  - platform: sun
    event: sunrise
    offset: 0
  - platform: sun
    event: sunset
    offset: 0
  - platform: time_pattern
    minutes: /20
condition:
  - condition: sun
    after: sunrise
    before: sunset
    before_offset: "0:20:00"
  - condition: template
    value_template: "{{ states('sensor.openuv_current_uv_index') != 'unavailable' }}"
action:
  - service: homeassistant.update_entity
    data: {}
    target:
      entity_id: sensor.openuv_current_uv_index
mode: single

[bachya]

Likely related to https://github.com/home-assistant/core/issues/101732.

[jhemak]

It appears the issue is due to the initialization of the integration. Each time the integration is reloaded, it makes 2 API calls. The days where I have hit the limit are also days where I have been doing a lot of restarts. It would be nice if either (1) the integration could avoid doing an API call at reload and wait with "unavailable" attributes until the first manual call of homeassistant.update_entity and/or (2) binary_sensor.openuv_protection_window could be completely disabled to avoid ever making an API call for it if not being used.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[jhemak]

Please keep open

[clucluclu]

Following.. I also:

• encounter this on days I do a lot of restarts
• don’t care about protection window
• would be happy if there was a way to stop it doing API calls on restart (can just let my automation do them, or manually trigger one of my broken dashboard is bugging me in the interim)

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[jhemak]

Still interested in this being addressed in the way suggested by @clucluclu above.

Any thoughts @bachya?

[clucluclu]

Still interested in this being addressed in the way suggested by @clucluclu above.

Any thoughts @bachya?

Yes would also still like to see this (even if only as an opt in option).

side note: love the integration, please take it only as a suggestion and not negative feedback :)

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[clucluclu]

To anyone else who lands here - I ended up solving it by eliminating OpenUV and the associated integration from my setup.

Instead I set up a simple scrape sensor to grab the UV data from ARPANSA's feed directly.

Was super easy to do, free, more flexible refresh intervals and unlike the OpenUV Integration (for me at least) - it's been 100% reliable.