Approach for Geo RSS sensor extensions/refactoring about architecture

[exxamalte]

I implemented a first version of the new component, and generating entities and displaying them on the map was fairly easy.

The zone trigger however requires an entity id to be configured; in my case though I don't know the entity id since the entities are generated and removed dynamically. I'll probably have to look at some kind of entity id with wildcard, so that any geo-location entity entering or exiting the zone can trigger an automation.

[balloob]

The binary sensor could be implemented with a zone trigger The push data from external source is also already possible. External sources can just fire an event.

Right now any entity with a latitude and longitude will show up on the map.

When suggesting a new domain, we should think about what it will group. Is this the place for "things happening at a location" or would it be to group just "things happening" ?

Nevertheless, I think that pulling it out of the sensor component is a good idea. The entities of this component can be short lived, and will be removed when they no longer appear.

[exxamalte]

Thanks for the advice, @balloob.

The binary sensor could be implemented with a zone trigger

I had a look at zones, and these may be useful in some cases. However, the zone size may need to be different depending on the use-case. For example, if the external event is a bushfire, the home zone's radius could be 10km, but if the external event is an earthquake, the radius may need to be 100km.
Currently, I guess, zones are typically used for device tracking and have a fairly narrow radius in the range of maybe 10-100 metres only.

Right now any entity with a latitude and longitude will show up on the map.

That is quite handy. However, to benefit from this existing functionality, I would need to generate one entity per external event. This would make the entities very transient, and would definitely require a new component to allow for proper (automated?) grouping of entities or at least a new way to present entities in the UI.

Is this the place for "things happening at a location" or would it be to group just "things happening"?

My use-cases typically have a location associated with an external event, but the exact location is only known when the event occurs (like a bushfire).

I'll give it a go, and see where this new component may lead me.

[balloob]

We support passive zones (docs). So you can setup a passive zone for bushfire and another one for earthquake. They will not show on the map.

I think that the map is a perfect view for creating and removing transient entities.

[balloob]

Please keep PRs as small as possible. Fixing the zone automation triggers should be done in a standalone PR. It might just be as easy as adding a new georss_zone trigger to automation that triggers whenever a georss entity is in a zone.

[exxamalte]

Now that the component is finished, I'm working on platforms. I just realised that it may make sense to briefly discuss the preferred general direction we want to take for platforms now.

Originally I started this journey with a very specific GeoJSON based feed from the rural fire service from the state I live in. Then people contacted me asking if I could also support other feeds, so I thought it may be better to just support the underlying geo feed standards like GeoRSS and GeoJSON.

Platforms for generic feed formats (e.g. GeoJSON, GeoRSS)

• Pros
  • Users can integrate any feed (of a supported generic format) they find immediately.
  • Similar to other platforms like rest sensor or scrape sensor.
• Cons
  • Because the platforms are generic, data extractions would become much more complicated or impossible. An integration with Home Assistant may become less valuable.
  • Feed formats such as GeoJSON and GeoRSS basically only care about coordinates, and not so much about meta-data. This makes it harder to find a common denominator.

Platforms for specific feeds (e.g. NSW Rural Fire Service, Qld Fire and Emergency Services, Italian Institute for Geophysics and Vulcanology, U.S. Geological Survey Earthquakes)

• Pros
  • Very convenient for the user, especially if users are less familiar with XML/JSON/etc.
  • Most comprehensive data extraction possible, hence most valuable integration with Home Assistant achievable.
• Cons
  • Every change in the URL, format, structure, etc. would require a change of the platform code (or related library).

[balloob]

We should go for the second one, which is in line with how we integrate other services.

[exxamalte]

Alright, no worries.
The library I implemented over the weekend currently supports one specific GeoJSON feed, and also includes very minimal generic support for any other GeoJSON feeds. We could keep this in the back-pockets for more experienced users to try other GeoJSON feeds, and if the feed information turns out to be valuable for HA, implement a specific platform.

[exxamalte]

Now that the component and some platforms are on their way, I wanted to look at the zone trigger:

I have a simple prototype running locally. This is based on a new trigger that allows wildcards in the entity id definition, and a small extension to async_track_state_change to deal with the wildcard.
The use of entity_namespace would be required with each geo location platform to distinguish entity ids from different sources.

Config example:

automation:
  trigger:
    platform: zone_wildcard
    entity_id: 'geo_location.nsw_fire_service_*'
    zone: zone.bushfire_alert_zone

I can see a couple of different options how to integrate that permanently:

1. Create a new trigger zone_wildcard which is almost a duplicate of the zone trigger. This would tell async_track_state_change to expect entity ids with wildcards. This is what my prototype does but is not very elegant.
2. Add a new config option to the existing zone trigger wildcard: True/False. If set to False (default) the behaviour is as of now. If set to True tell async_track_state_change to expect entity ids with wildcards.
3. Either create a new trigger or a config option for zone and duplicate async_track_state_change to deal with entity ids with wildcards. However, then there would be two slightly different methods listening for state changes.
4. Allow the zone trigger to have entity ids with wildcards, and duplicate async_track_state_change to deal with entity ids with wildcards.
5. Allow the zone trigger to have entity ids with wildcards, and in async_track_state_change always assume that any entity id provided may contain a wildcard.
   No sure though if executing a regular expression match in every single callback within async_track_state_change would be too much of an impact on the performance.

[awarecan]

Are you still planning refactoring current GeoRSS Sensor to GeoLocation?

[exxamalte]

Are you still planning refactoring current GeoRSS Sensor to GeoLocation?

Yes. I just feel that there are a few more fundamental improvements required first to make the new geo_location component fully useful. In particular: use of zones / zone trigger, and some kind of grouping.

The replacement of the geo_rss_events sensor could be as simple as grouping all current entities matching a certain entity id pattern and then counting the number of entities in that group. And then use each entity's name and distance to form the state attributes.

Similar to the new geojson-client library, I have a georss-client library almost finished, just some more unit tests required. Once this is published, I think refactoring the geo_rss_events sensor should be pretty straightforward.

[exxamalte]

Alright, I refactored the existing geo_rss_events sensor to make use of the new georss-client library.
I don't see how this sensor would fit into the geo_location component other than using the same code/library. The geo_rss_events sensor counts the number of external events found, while the platforms in the geo_location component generate entities for each external event found and use the distance to home as the state value.

[exxamalte]

As rightly brought up by @frenck, "geolocation" is actually one word. In the meantime though, the component, platforms and automation trigger that have been added all use the form "geo location" or some form of "geo_location_..." config parameters, etc.

I see a couple of options:

1. Change all occurrences of "geo location" or "geo_location" to "geolocation". Documentation, source code, etc. This would unfortunately lead to a couple of breaking changes for users.
2. Only correct to "geolocation" in the documentation and occurrences in the source code that are not exposed to users, but leave "geo_location" in config parameters and the likes to avoid any breaking changes.

Any thoughts?

[balloob]

Url of documentation should match the name of the component/platform, so if you do 2, only change the titles of the pages, not their filenames. This can be done already. Not sure about breaking change.

[exxamalte]

Ok, I'll prepare a couple of small digestible PRs for option 2 for now, and keep filenames as-is.

[awarecan]

Is this done?

[exxamalte]

Yes, I think the bulk of the work is done. If there are any further architectural question, I'll open a new ticket.