OpenUV integration working correctly for anyone?

I’m using the OpenUV for a few days now and the API calls seem to go through but the values remain exactly the same.
Is anyone using OpenUV successfully?

I’m basically looking for an UV index forecast to show on my dashboard. Any alternatives for that?

edit: I forgot to mention that I#ve sent an email to the OpenUV support but haven’t received an answer yet.

1 Like

I still haven’t heard back from the OpenUV support.

Since the integration doesn’t seem to work, is there a place where I could report a broken integration?

1 Like

Mine is working, although it does seem sporadic at times. OpenUV website doesn’t have any updates / posts in over 4 years :frowning:

Integration author here. :wave: I’m using the integration successfully, but as @jspanitz says, it can sometimes be sporadic. It appears that the OpenUV API struggles under load; you’ll see out-of-the-blue HTTP 401 and HTTP 500 errors. They don’t last forever.

Hi @bachya, just wanted to say thank you very much for this integration. It’s one of my absolute favorites.

Quick question for you. If I have two different license keys (I want to monitor the UV at my location and at my children’s homes in another state) can your integration handle that? I’ve added the various locations and I’ve used their key for their location but I’m not sure it’s working properly.

I have a hunch that when I add a new location, the new key that is specified replaces all previous keys for any previously defined locations.

Ah, you know what… you’re right: if you add a new instance, all instances start using that key. :man_facepalming: I’ll work on fixing that.

1 Like
1 Like

Is there a way to update the existing integrations to change the API keys?

RANT
This is one of the things I very much dislike with HA - once you set up an integration, modifying it seems to be impossible, you have to remove and add again, breaking all kinds of stuff.
END RANT

Do you have an expired API key you’re wanting to replace, or some other reason?

Let me know if it’s “some other reason,” but if it’s an expired API key you’re trying to replace, I have several thoughts.

In general, we try to h. If expired API keys for you – if one expires, you should see an authentication message which, when interacted with, will guide you through refreshing it (without deleting the underlying config entry). I never did this for OpenUV because of an oddity in their service: now and then, the API chokes and starts returning 401/403 responses (indicative of an expired API key). However, the key isn’t expired– it’s just the API acting up, and it tends to resolve itself after a few hours. So, I can’t reliably know when we actually need to refresh things.

That said, I spoke with some of my core teammates this morning and came up with an idea:

  1. If we get X (3? 4? more?) 401/403 responses in a row, we assume that API key is bad and we start a re-authentication flow (wherein you get to update the API key).
  2. If the integration recovers at any point, we halt that re-authentication flow (and allow the original integration to keep working).

The potential downside is that if the service acts up for quite awhile, you could be “tricked” into thinking you need a new key when you really don’t… but that’s not the end of the world.

I’m out of town at the moment, but I’ve made a note to dig into this more when I return next week.

For my use case, I had have to locations using the same key (as previously explained above) and want to replace the one with the proper key.

In that case, it’d be quicker to just delete/re-add (and rename).

New issue and I can gladly raise it elsewhere but since I know you have a better chance in this thread:

Two repairs for OpenUV are showing up:

The openuv.update_protection_data service is being removed
image

And

The openuv.update_uv_index_data service is being removed
image

That’s correct – those are telling you to update service calls that you’re currently using.

Right - my understanding is the integration needs to be updated to not use those calls. Are you saying that’s not the case? Or are you saying it is the case but each user needs to perform their own update? Sorry for the confusion but I assumed it was the integration and the maintainers would need to make changes.

No, that’s not the case. Those repair items are created by the integration when someone uses an OpenUV service call that is now deprecated (in an automation or a script): https://github.com/home-assistant/core/blob/5d09fe8dc184488e399348877c21cfc9a39ca955/homeassistant/components/openuv/__init__.py#L185-L228

So, you need to update any automations/scripts that use the old services and replace them with the service/targets specified in the repair item.

I have two automations fetching data every hour UV_Index_Data and once a day UV_Protection_Data. Any suggestion how the new service calls should look like?

#A2 Update OpenUV every hour while the sun is above 0 degrees of horizon
#   Publishes data to other devices via MQTT
- id: Update_Open_UV_Index
  alias: 'Update OpenUV Every Hour'
  initial_state: 'on'
  trigger:
    platform: time_pattern
    hours: '/01'   
  condition:
    condition: numeric_state
    entity_id: sun.sun
    value_template: '{{ states.sun.sun.attributes.elevation }}'
    above: 0
  action:
  - service: openuv.update_uv_index_data
#A3 Update OpenUV Protection Data once a day
#   Publishes data to other devices via MQTT
- id: Update_OpenUV_Protection_Window_Daily
  alias: 'Update OpenUV Protection Window Daily'
  initial_state: 'on'
  trigger:
    platform: time
    at: '04:00:00'
  action:
    service: openuv.update_protection_data

All you need to do is change the service call lines. The screenshots in the post above detail what you need to do: call homeassistant.update_entity with the appropriate entity ID. The docs are helpful, too: OpenUV - Home Assistant

Hmm, I changed both of mine, thank you @bachya, but I’m not seeing updates now. Both automations are running and the logs show they are running as expected but values are not being updated. If someone can put a second set of eyes on the yaml below?

alias: OpenUV Update Protection Window
description: ""
trigger:
  - at: "06:00:00"
    platform: time
condition: []
action:
  - service: homeassistant.update_entity
    data: {}
    target:
      entity_id: binary_sensor.protection_window
mode: single
alias: OpenUV Update UV Index During Daytime
description: ""
trigger:
  - minutes: /30
    platform: time_pattern
condition:
  - above: "10"
    condition: numeric_state
    entity_id: sun.sun
    value_template: "{{ state.attributes.elevation }}"
action:
  - service: homeassistant.update_entity
    data: {}
    target:
      entity_id: sensor.current_uv_index
mode: single

Not seeing any obvious issue with your automations – do your logs show anything?

FWIW, this is what I use and it’s updating successfully:

alias: "Health: Update OpenUV every 1 hour during the daytime"
trigger:
  - platform: time_pattern
    minutes: /15
condition:
  - condition: sun
    after: sunrise
    before: sunset
    before_offset: "+00:45:00"
  - condition: template
    value_template: |-
      {{
        state_attr(
          "automation.health_update_openuv_every_1_hour_during_the_daytime",
          "last_triggered"
        ) == None
        or (
          now() - state_attr(
            "automation.health_update_openuv_every_1_hour_during_the_daytime",
            "last_triggered"
          )
        ) >= timedelta(hours = 0, minutes = 40)
      }}
action:
  - service: homeassistant.update_entity
    data: {}
    target:
      entity_id: sensor.current_uv_index
initial_state: true