Add GDACS feed integration

[exxamalte]

Breaking change

Proposed change

This is a new geo_location integration which retrieves data from the Global Disaster Alert and Coordination System (GDACS) GeoRSS feed. Relevant data about major droughts, earthquakes, floods, tropical cyclones, tsunamis and volcanoes worldwide is converted into geo_location entities with loads of useful information made available as state attributes.

In addition, a sensor is created and its state shows the number of geo_location entities currently managed by this integration, and in addition shows some details about the last update from the feed (successful or error), time of last update, time of last successful update, number of entities created/updated/removed.

This integration comes with an async library and config flow.

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)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml
gdacs:

Additional information

• This PR fixes or closes issue: n/a
• This PR is related to issue: n/a
• Link to documentation pull request: Add GDACS feed integration home-assistant.io#11956

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
• The code has been formatted using Black (black --fast 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.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

[MartinHjelmare]

Nice!

[MartinHjelmare]

Great!

[MartinHjelmare]

Please link a docs PR in the PR description. Then we can merge.

[exxamalte]

Doco is in the making, and I will create a PR tomorrow.

[exxamalte]

Are you happy with the Silver rating I was aiming for with this integration, or is there a separate process/assessment?

[MartinHjelmare]

Please copy the bullet list with criteria of the silver level and make a comment here for each point. Some criteria may not apply etc.

https://developers.home-assistant.io/docs/en/integration_quality_scale_index.html

[exxamalte]

Silver

• Connection/configuration is handled via a component.

Yes, it is handled within this new component using a third-party library.

• Set an appropriate SCAN_INTERVAL (if a polling integration)

Scan interval is set to 5 minutes by default. This value can be overridden through configuration.

• Raise PlatformNotReady if unable to connect during platform setup (if appropriate)

n/a. The integration does not attempt to connect during the setup.

• Handles expiration of auth credentials. Refresh if possible or print correct error and fail setup. If based on a config entry, should trigger a new config entry flow to re-authorize.

n/a. This integration uses a public feed that does not require authentication.

• Handles internet unavailable. Log a warning once when unavailable, log once when reconnected.

The integration does not log a message if the feed becomes unavailable. Instead, the integration automatically creates geo_location entities when the feed becomes available, and removes entities when the feed becomes unavailable.

• Handles device/service unavailable. Log a warning once when unavailable, log once when reconnected.

As above.

• Set available property to False if appropriate (docs)

n/a. Instead, the integration will remove geo_location entities from HA when the feed becomes unavailable.

• Entities have unique ID (if available)

The ID is auto-generated from the entity's title which itself is made up of information from each feed entry which is made unambiguous within the feed.

[MartinHjelmare]

Looks good. I think this integration actually qualifies for platinum level.

[exxamalte]

Thanks, let's see how the integration scores against the remaining criteria:

Gold

• Configurable via config entries.

Yes.

• Don't allow configuring already configured device/service (example: no 2 entries for same hub)

Yes, in this case, no duplicate entries allowed for the exact same location.

• Tests for the config flow

Unit tests available.

• Discoverable (if available)

n/a. This is probably not desirable for a web-based feed.

• Entities have device info (if available)

n/a. No devices involved.

• States are translated in the frontend (text-based sensors only)

n/a. The state is a numeric value. Attributes however are ingested as-is from the original source without translation (and a frontend translation would be impossible because the text-based attributes are mostly editorial).

• Tests for reading data from/controlling the integration

Unit tests available in HA, as well as in the third-party library.

• Has a code owner

Yes, it does.

Platinum

• Set appropriate PARALLEL_UPDATES constant

Currently missing. I will look into this now.
Set to 100 0 (=unlimited) because an update of an entity does not actually make a web request, but only uses internal data previously retrieved from the integration.

• Support config entry unloading (called when config entry is removed)

Yes, supported.

• Integration + dependency are async

Yes, all async.

• Uses aiohttp and allows passing in websession (if making HTTP requests)

Yes, the third-party library expects a websession input parameter.

[exxamalte]

Alright, I added the remaining criteria. The only thing missing was the PARALLEL_UPDATES constant. I couldn't find documentation about this constant, but understand that it determines how many concurrent updates of entities of the same type are allowed. Since the entities of this integration are all updating based in internal data previously retrieved in a single web request, I set this to 100 0 (=unlimited).

[MartinHjelmare]

Nice! Just set the quality_scale key in the manifest.json to platinum and we're done.