Do not LG thinq retry entry setup, when a single coordinator failed

[LG-ThinQ-Integration]

Breaking change

Proposed change

When a single coordinator failed, we don't need to retry entry setup.
Use async_refresh() instead of async_config_entry_first_refresh()

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Stale

[joostlek]

When can a single coordinator fail?

[LG-ThinQ-Integration]

When can a single coordinator fail?

A single coordinator fails, when a device is not connected to the cloud,
For example, if a device is plugged off after a device is connected to the cloud, it happens.

[joostlek]

But that means that device is returned in the device list but not when you specifically ask for an update for that device?

[LG-ThinQ-Integration]

But that means that device is returned in the device list but not when you specifically ask for an update for that device?

Because the device is registered by the user through the mobile application and etc, the Cloud always send it into the list.
This is why our structure is based on the mqtt.
When the device becomes available again, the coordinator will work properly after mqtt message is received.
But now because we don't have mqtt, we want to do keep going based on the developer guide page.

• https://developers.home-assistant.io/docs/integration_fetching_data?_highlight=configentrynotready#coordinated-single-api-poll-for-data-for-all-entities

[joostlek]

Can you elaborate on what MQTT exactly communicates when?

[LG-ThinQ-Integration]

Can you elaborate on what MQTT exactly communicates when?

When the device is connected to the Wi-Fi again, it will try to connect to the cloud.
If the device is connected, the cloud will send 'DEVICE_STATUS' message to the integration.
Then the integration will update the coordinator available.

[joostlek]

When the device is not connected to the cloud and we indeed use async refresh instead of the config entry refresh, does it create the entities and device but show them as unavailable?

[LG-ThinQ-Integration]

When the device is not connected to the cloud and we indeed use async refresh instead of the config entry refresh, does it create the entities and device but show them as unavailable?

Yes, you are correct.

[joostlek]

Does the coordinator already log when this is happening?

[joostlek]

I think this would be an awesome testcase to have to make sure it keeps doing what we expect

[LG-ThinQ-Integration]

Does the coordinator already log when this is happening?

Are you asking if we are logging in that case?
Then, yes!! We are loggin in coordinator._async_update_data().

[joostlek]

In that case I think I agree with merging this

[LG-ThinQ-Integration]

In that case I think I agree with merging this

What do you mean 'in that case'?

[joostlek]

Oh, that I now have all the answers and that i agree that this is the way. If the answers were different i would advice more changes or a different approach, but this is the best way forward

[LG-ThinQ-Integration]

Oh, that I now have all the answers and that i agree that this is the way. If the answers were different i would advice more changes or a different approach, but this is the best way forward

Thank you. Then can I open this PR?

[joostlek]

Yes