Need assistance creating a PR on Usgs (earthquakes) config options adding templates

Configuration
1

Building on How to: geolocation trigger distance to device_tracker

I’d like to create a PR on the geo_location integration Earthquakes feed https://www.home-assistant.io/components/usgs_earthquakes_feed/ but don’t really know how to do so (have PR’ed only some documentation pages till now…)

I do know what I think it should be configured like when possible. Right now we can do:

  - platform: usgs_earthquakes_feed
    feed_type: 'past_day_all_earthquakes'
    radius: 2000
    minimum_magnitude: 2.0
    latitude: -7.12
    longitude: 110.34
    entity_namespace: 'quake'

which means all is fixed, and one has to be very crafty creating cards and automations based on the feed.

It would be really very helpful if templating where to be allowed here, and a dynamic dashboard in HA frontend could be established using that.
Config then could be:

  - platform: usgs_earthquakes_feed
    feed_type: 'past_day_all_earthquakes'
    radius_template: >
      {{states('input_number.quakes_radius')|float}}
    minimum_magnitude_template: >
      {{states('input_number.quakes_magnitude')|float}}
    device: device_tracker.person_to_care_for
    #latitude: -7.12
    #longitude: 110.34
    entity_namespace: 'quake'

Would be nice if we could use Zone too, but lon/lat is effectively the same. Using a device would make it really easy to follow our traveling family members without having to constantly change the core setup of ones HA instance.

Hope someone of you is willing to assist me to create this PR.
Thought of filing a feature request, but fear the followup on that is rather low. Pr stand a better chance :wink:

thanks!

2

As the original author of this integration, I would highly appreciate any help in evolving this further. It would be good to hear some more feedback from other users.

You may be aware that there are two more earthquake related integrations now - IGN Sismología and GeoNet NZ Quakes - focusing on other regions in the world. And it may make sense to apply changes to these integrations, too, at some point.

Coming back to your suggestions above: Allowing templates for some of the config parameters appears to make sense, but also means a bit of work in how the integration works. For example, instead of a static setup you need to reconfigure the integration each time you change those input_numbers. Likewise for switching from static coordinates to a moving device tracker.
And in addition to the HA integration, you may need to look at making some changes to the underlying library that communicates with the feed - again PRs welcome.

3

Just one note of caution: The original intent of the geolocation integrations was never to be a realtime early warning systems for disasters.
Because - at the moment at least - all those integrations depend on GeoRSS/GeoJSON feeds, we are dependent on the supplier of the information to publish any updates, and then the HA integration polls the feed every 5 or 10 minutes to retrieve updates. So, in the worst case, updates can take 10/20/30 minutes or so until they actually reach your HA system.
The first such integration I built was for bushfire warnings, and the intent was to get a notification whenever the rural fire service publishes information about a nearby bushfire so that I can go and for example close my windows, or go outside and remove leaves.

4

Sure, appreciate that. Wouldnt depend my life on it. Its just that with the current available options, and a bit of templating, we could make the frontend respond to our manipulations that much easier, and have it be just that bit more flexible.

yes, feared as much …:wink: not a pr to the usgs integration perse, but to the underlying system. Maybe even more specific: the fixed lat/lon or device_tracker would be geojson specific, the radius seems to be an even system wider option? There are more integration using that? Wwlln: comes to mind, for which I also use a template like this to have it be of more importance in the frontend, templating window and radius:

      list_lightning_strikes_near:
        entity_id: sensor.time, input_number.lightning_strikes_near
        friendly_name: List lightning strikes near
        value_template: >
          {% set km = states('input_number.lightning_strikes_near')|int %}
          {% set strikes = states.geo_location|selectattr('attributes.source','eq','wwlln')%}
          {% for s in strikes if s.state|int < km %}
            {%- if not loop.first %},{% endif -%}
            {{- s.name.split(':')[1] -}}
            {% else %} No strikes near
          {% endfor %}

      count_lightning_strikes_period:
        entity_id: sensor.time, input_number.lightning_strikes_period
        friendly_name: List strikes per period
        value_template: >
          {% set hour = states('input_number.strikes_period') %}
          {%- set t = as_timestamp(now()) - hour|int*(60 * 60) %}
          {% set ns = namespace(count=0) %}
          {%- for s in states.geo_location|selectattr('attributes.source','eq','wwlln') %}
            {%- if s.last_updated != None and as_timestamp(s.last_updated) > t %}
            {% set ns.count = ns.count + 1 %}
            {%- endif %}
          {%- endfor %}
          {{ ns.count }}

      list_lightning_strikes_period:
        entity_id: sensor.time, input_number.lightning_strikes_near
        friendly_name: List lightning strikes period
        value_template: >
          {% set hour = states('input_number.lightning_strikes_period') %}
            {%- set t = as_timestamp(now()) - hour|int*(60 * 60) %}
            {%- for s in states.geo_location|selectattr('attributes.source','eq','wwlln') %}
              {%- if s.last_updated != None and as_timestamp(s.last_updated) > t %}
              {{- s.name.split(':')[1] -}}{{ ',' if not loop.last else ''}}
              {%- endif %}
            {%- endfor %}

all complex templates that could be done with if we had templating in the config…

what exactly do you mean by:

My intent is exactly the opposite: that the integration takes care of the changes internally, and that sliding the input_number triggers the integration to adapt its feedback.
Just like I do with the templates above?

so, instead of:

      count_earthquakes:
        entity_id: sensor.time
        friendly_name: Earthquakes
        value_template: >
          {{ states.geo_location|selectattr('attributes.source','eq','usgs_earthquakes_feed')|list|count }}

the templated integration would allow for:

      count_earthquakes_near:
        entity_id: sensor.time, input_number.quakes_near
        friendly_name: Count quakes near 
        value_template: >
          {% set km = states('input_number.quakes_near')|float %}
          {% set ns = namespace(count=0) %}
          {% for s in states.geo_location | selectattr('attributes.source','eq','usgs_earthquakes_feed') %}
            {% if distance(s.entity_id, 'device_tracker.life360_name') < km %}{% set ns.count = ns.count + 1 %}{% endif %}
          {% endfor %}
          {{ ns.count }}

hope I am making myself clear…

5

Yep, sorry, what I meant is that at the moment the setup of the integration is static and this simple - the configuration parameters never change. Your proposal means that the integration would need to react to any changes to the templated configuration. So, as a user you don’t need to reconfigure, but as a developer you would need to change the integration and probably the underlying library to deal with changing config parameters.

6

Hi Exxamalte,

sorry for bumping this, but since I’ve recently seen several quakes (not too near fortunately) it reminded me of this discussion we had over a year a ago.

Given the fact templates have been implemented ion so many new places in core HA, I was wondering if it would be possible to do this already:

  - platform: usgs_earthquakes_feed
    feed_type: past_day_all_earthquakes
    radius: >
      {{states('input_number.quakes_near')|float}}
    minimum_magnitude: 3.0
    entity_namespace: 'quake_near'

Of course I tried and an error is thrown on the config needing a float (which I presume is because it doest recognize the template…)

Do you see the platform advance with this option at all? And on the magnitude, making it a more controllable indicator from the frontend.

7

Good point. Let me take a look at what’s actually required to enable the use of templates.

1 Like
8

thanks!

btw, is the name_space still the only option to name these sensors? I had some with fixed numbers, and see no other way than to name them like that, but maybe that could be done better too?