Add service integration.reload

cant seem to get this working…

rest_command:
  reload_tplink:
    url: http://homeassistantssd.local:8123/api/config/config_entries/entry/xxxx/reload
    method: POST
    headers:
      authorization: 'Bearer xxxxx'
      content-type: application/json

2021-02-11 18:41:31 ERROR (MainThread) [homeassistant.components.rest_command] Client error http://homeassistantssd.local:8123/api/config/config_entries/entry/xxxxx/reload

some development here: https://github.com/home-assistant/core/issues/46515

The reload REST API doesn’t seem to be working all the time. It’s not executing a fully reload. Whenever I saw a TP-LINK switch that’s not responding, executing REST call to reload the integration won’t help. But if I go to the integration web page to click reload TP-LINK integration manually, it will fix the problem.

1 Like

Unfortunately, nobody replied to you on that github issue :frowning:

Add me to the wish list for integration.reload

3 Likes

this is now partially solved, with the new service homeassistant.reload_config_entry
Thanks Ludeeus!
allowing us to do

  reload_integration:
    alias: Reload integration
    mode: restart
    sequence:
      service: homeassistant.reload_config_entry #rest_command.reload_integration
      data:
        entry_id: >
          {% set mapper =
            {'AirVisual':'37redacted105b',
             'Gdacs':'05redacted2d2b18a',
             'Ikea':'377028redacted11b1951',
             'Ipp':'999b75bdredacted1716',
             'Life360':'2a76ecredacted59e7c',
             'Luftdaten Rotterdam P':'c6redacted5f1281',
             'Luftdaten Rotterdam T':'016redacted625012e',
             'Luftdaten Tilburg P':'9565redacted09c',
             'Luftdaten Tilburg T':'8redactedbf8',
             'OpenWeather':'1dd0redacted93f',
             'Owntracks':'6b204redacted2a',
             'Philips Hue 1':'7afredactedbc5',
             'Philips Hue 2':'a4redacted731e',
             'Plugwise':'474redacted12',
             'Plex':'dd13eredactede05',
             'Spotify':'12edredacted08',
             'Synology Dsm':'fd8redacted81367',
             'Weatherbit':'79ae7redacted2b5c',
             'Xbox':'e8cd7bredactede6'} %}
          {% set state = states('input_select.select_integration') %}
          {% set id = mapper[state] if state in mapper %}
          {{id}}

and

input_select:

  select_integration:
    name: 'Select Integration:'
    options:
      - AirVisual
      - Gdacs
      - Ikea
      - Life360
      - Luftdaten Roosendaal T
      - Luftdaten Rotterdam P
      - Luftdaten Rotterdam T
      - Luftdaten Tilburg P
      - Luftdaten Tilburg T
      - OpenWeather
      - Owntracks
      - Philips Hue 1
      - Philips Hue 2
      - Plugwise
      - Plex
      - Spotify
      - Synology Dsm
      - Weatherbit
      - Xbox
    initial: Weatherbit

unfortunately we still have to find the entry_id’s manually in the .storage, but we’re half way there :wink:
hope we will see an automatic config entry map in HA core interface at anytime, or at least an easy way of finding that, without having to scroll the .storage for the numbers. Could be nice eg on the /config/integrations page per integrations under some sort of info button?

5 Likes

Should one use config_entry_id from core.entity_registry or entity_id? I just did a quick test and it seems entity_id works. Looking at your post it looks like you used config_entry_id. Would be keen to know if entity_id works for you too.

See Add service integration.reload - #52 by Mariusthvdb

Thank you, but it’s not yet clear to me.

Regarding this comment from that post:

the [Config Entry] should be the data in the top line, ‘entry_id’ field in the config/.storage/core.config_entries and not the Identity field.

And given an example config entry from core.entity_registry:

            {
                "entity_id": "light.redacted_light",
                "config_entry_id": "redacted",
                "device_id": "redacted",
                "area_id": "foyer",
                "unique_id": "redacted",
                "platform": "some_platform",
                "name": "Redacted Light",
                "icon": null,
                "disabled_by": null,
                "capabilities": {
                    "min_mireds": 111,
                    "max_mireds": 400,
                    "supported_color_modes": [
                        "color_temp",
                        "hs"
                    ]
                },
                "supported_features": 19,
                "device_class": null,
                "unit_of_measurement": null,
                "original_name": "Some Smart Bulb",
                "original_icon": null
            },

Is entry_id referred to above then entity_id, config_entry_id or unique_id. I’m assuming config_entry_id but want to be certain, especially since this seemed to work when I used entity_id instead.

not sure if you understand what this does, since you refer to a single entity in the core.entity_registry:

the service I requested in the FR, integration.reload, and now implemented as reload_config_entry, reloads just that, a config entry. Meaning, the integration (or a subsidiary entry) displayed on your integrations page.

As such, it needs the ‘entry_id’ field in the config/.storage/core.config_entries

your line is from the core.entity_registry, as pertains not the config_entries, which this is all about, but entities in the Ha system.

this is about: homeassistant.reload_config_entry
maybe you talk about: homeassistant.update_entity ?

1 Like

I do, and to hopefully convince you: I want to be able to reload my TP-Link integration (with a script/automation/whatever).

I was trying to understand which file to look at and which ID to use since that part wasn’t clear. That’s why I gave all the details of what I’ve done – I’ve been very specific. I couldn’t find an ID identified by entry_id and that’s why I asked. Just pointing out that I’ve looked at the wrong file would’ve been sufficient.

so did you check the config/.storage/core.config_entries for the TP-link integration?

well, tbh, that was clear before the new service was implemented, Ill quote it once more:

Thank you for berating me when I honestly missed something and made the big mistake to ask for help. By giving the details of my steps I was hoping it was a clear indication that I’ve made an effort and wasn’t trying to annoy you or anybody else. I’ve seen many of your posts and you’ve missed things many times too. You could just have pointed out I was looking at the wrong file.

1 Like

not my intention at all, sorry if you feel that way.

And, you quoted me yourself on the exact same thing here Add service integration.reload - #66 by parautenbach

dear o dear…

Found my buddy! Please let me know if anyone found a way around this. Either fixing the IKEA integration or automating the reload.

Thanks!

Hey @Mariusthvdb. Thanks for explaining this. Where do I add this? in configuration.yaml or scripts.yaml?

Well, the top is a script, so you put that in scripts, or wherever you store scripts (I have it all in a package), the bottom is an input_select, so you put that, well, again, wherever you want, as long as its under the correct hierarchy…

1 Like

Sorry, am I missing something?
What is the point of the script and then an input_select?
I can simply go to the integrations page and click ‘reload’.
I’d like to be able to automate the ‘reload’ on a very regular basis (Ikea crappy integration needs reloading a lot)…
Thanks

To do it from the frontend and prevent exactly what you describe. As I wrote in the opening Fr :wink:

That is entirely possible, and has been all along.

Using node red?
Would be great to just ‘call’ a service? is this possible?