Add support for World Wide Lightning Location Network

[bachya]

Description:

This PR adds support for the World Wide Lightning Location Network (WWLLN) as a geolocation platform.

Related issue (if applicable): N/A

Pull request with documentation for home-assistant.io (if applicable): home-assistant/home-assistant.io#9802

Example entry for configuration.yaml (if applicable):

wwlln:

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist

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

• Documentation added/updated in home-assistant.io

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

• The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[MartinHjelmare]

Sounds like this could better be a geo_location platform?

For each lightning strike within the configured radius a new geo_location entity is created. Optionally let the time frame be configured to set the clean up window when entities should be removed.

If the user wants to count strikes a template sensor can be used.

[bachya]

@MartinHjelmare Interesting! Let me ponder that. One issue I currently see: the geo_rss_events component seems to expect everything in metric, but I want to give users the ability to use whatever unit system they've defined in their configuration.yaml. I suppose I could convert imperial units to metric units (when necessary) before instantiating a GeoRSS client..

EDIT: Another issue is that the geo_rss_events component expects an HTTP-hosted XML stream as input data; that won't exist in this case. Rather, I would need to give aiowwlln a method that can produce valid GeoRSS XML and then modify python-georss-generic-client to accept that raw input. Seems like a lot of work, no?

[MartinHjelmare]

The geo_location component is a general base component and doesn't rely on any specific library or metric system.

https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/geo_location/__init__.py

[bachya]

Ahh, okay; I misread and assumed you meant GeoRSS. Let me dig into this a bit.

[bachya]

@MartinHjelmare I've refocused this PR from sensors to geolocation; will appreciate your thoughts at your leisure.

FYI, this is now waiting on #25046 (which allows geolocation platforms to use config entries).

[MartinHjelmare]

Looks good!

[bachya]

@MartinHjelmare In addition to addressing your latest feedback, I realized aiowwlln wasn't providing a good "window" option, meaning strike data could feasibly hang on for way too long. The latest commits add this; sorry for additional chunks to review.

[MartinHjelmare]

Looks great!

Unfortunately python 3.7 tests are flaky at the moment so I can't merge. We have to wait for an admin or until we fix the tests and can rebase.