Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add template extension coordinates #30019

Closed
wants to merge 4 commits into from

Conversation

eifinger
Copy link
Contributor

@eifinger eifinger commented Dec 17, 2019

Description:

This template extension will allow for a clean and reusable way to enable dynamic travel_time sensors. The issue was discussed several times in the forum here and here as well as in the PRs #27237 #28716.

Using this template the following config is possible:

input_select:
  here_destination_preset:
    options:
      - zone.home
      - zone.office
      - zone.somewheredefault

sensor:
  - platform: here_travel_time
    api_key: my_api_key
    name: Reistijd
    origin_template: {{ coordinates('device_tracker.myphone') }}
    destination_template: {{ coordinates('input_select.here_destination_preset') }}

automation:    
  - alias: 'set'
    trigger:
      - platform: homeassistant
        event: start
      - platform: time
        at: 00:00
    action:
       service: input_select.select_option
       data_template:
        entity_id: input_select.here_destination_preset
        option: "{% if is_state('device_tracker.myphone','home') %}zone.office{% elif is_state('device_tracker.myphone','office') %}zone.home{% else %}zone.somewheredefault{% endif %}"

The simple case {{ coordinates('device_tracker.myphone') }} can already be accomplished with existing methods but now the user does not have to know that a device_tracker stores latitude and longitude as attributes.

The nested case {{ coordinates('input_select.here_destination_preset') }} is currently only possible by creating a complex structure of dependent template_sensors using complex templates.

Related issue (if applicable): fixes #TBD

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

Example entry for configuration.yaml (if applicable):

See above.

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:

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.

@Mariusthvdb
Copy link
Contributor

Mariusthvdb commented Dec 17, 2019

this is very nice indeed! thanks for working on this, highly anticipated functionality!.

might I suggest 2 further improvements ?

  • why prescribe the suffix _template. Would be much user friendlier if the component were to autodetect the fact a template was entered in the fields for destination and origin.

  • further more, if we are on the subject of auto-detection, why not make it even better, and have the component auto sense the gps coordinates, if a config would be using a device_tracker? It expects/excepts lat/lon only, so have it look for that when a device_tracker was entered as origin/destination?

  • same would go for the input_select. Why not simply accept {{states('input_select.here_destination_preset'}} and auto find the coordinates of that zone?

cheers, thanks for considering.

@eifinger
Copy link
Contributor Author

@Mariusthvdb to your suggestions:

  1. Without the _template suffix it would be indeed much less verbose to implement in a travel_time integration. But I could not find any instance in the documentation where a user was allowed to supply a template to a field and it was not named with the suffix _template. Did I overlook it?

  2. I am not sure I understand you correctly. You want to get rid of the template I implement here and move the functionality directly to the integration.

This was not done for several reasons:

  • The integration (e.g. here_travel_time) should not be responsible for homeassistant internal stuff, which this functionality is
  • While working on the PR for the new travel_time integration I initially put in in there but realized this is some functionality I would want in other integrations as well.
  • I could have put it into some helper method but then it would be up to each developer of each integration to implement this functionality. By releasing this functionality as a template all a developer has to do is enable the usage of templates. He doesn't have to look through all the functions in the homeassistant source and think of ways the user would want to interact with his integration. If the template compiles all is good.

@Mariusthvdb
Copy link
Contributor

yes on both accounts.
also yes on understanding your considerations ;-) I was merely trying to make it easier for the user, not having to think about all demands the various integrations put forward.

about needing _template or not: not really sure tbh if there are other integrations. I do know several custom Lovelace cards simply accept templates or fixed values regardless. I know that is not the same, but one easily gets used to that friendly configuration..

about the other question, you might be right on track! Suppose it would be best if HA system wide would simply accept templates on all config fields... as long as that is not the case, your solution might be wisest.
thanks for taking the time to explain, appreciated

@eifinger eifinger mentioned this pull request Jan 20, 2020
9 tasks
@stale
Copy link

stale bot commented Mar 21, 2020

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale label Mar 21, 2020
@eifinger
Copy link
Contributor Author

Keep open

@stale stale bot removed the stale label Mar 21, 2020
@MartinHjelmare MartinHjelmare added the second-opinion-wanted Add this label when a reviewer needs a second opinion from another member. label Apr 15, 2020
@stale
Copy link

stale bot commented May 15, 2020

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@stale stale bot added the stale label May 15, 2020
@eifinger
Copy link
Contributor Author

Still open

@stale stale bot removed the stale label May 15, 2020
Copy link
Contributor

@dgomes dgomes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, please fix the conflict

@eifinger eifinger force-pushed the add_template_get_coords branch from fafb720 to 4c015b7 Compare May 26, 2020 07:51
return None


def _entity_state_is_valid_coordinate_set(state: str) -> bool:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is only used once, you can also use:

try:
   cv.gps(state.split(","))
except vol.Invalid:
   _LOGGER.error(...)
else:
  return entity.state

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the function

@eifinger
Copy link
Contributor Author

Done

return _get_location_from_attributes(entity)

# Check if device is in a zone
zone_entity = _resolve_state(hass, f"zone.{entity.state}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
zone_entity = _resolve_state(hass, f"zone.{entity.state}")
zone_entity = hass.states.get(entity.state)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting your state to the entity ID of a zone is not an official supported "thing", we shouldn't encode it in our template helper unless we want to adopt this.

Let's remove this support.

Copy link
Member

@balloob balloob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The goal of this PR is to put logic in the template helper to make passing a parameter to a sensor easier. That doesn't make sense.

If this is something that the sensor wants to support, they should just implement it.

@eifinger
Copy link
Contributor Author

As I explained in the description this functionality was discussed several times already.
I first wanted it to introduce directly to the here_travel_time sensor with this pr: #27237 but was told it wasn't the right place.
We then discussed on discord and on #28716 that it should also not be put into the helpers or a travel_time integration.
Then I opened this PR.

My preference would still be to implement it directly into here_travel_time.

@balloob
Copy link
Member

balloob commented Jun 23, 2020

I think it's fine to add a helper to helpers/location.py that can be used by travel time integrations.

It's not fine to hijack templates for a one-off function.

@eifinger eifinger mentioned this pull request Jun 29, 2020
20 tasks
@eifinger
Copy link
Contributor Author

I opened a new PR #37234 to add the function under helpers/location.py

@eifinger eifinger closed this Jun 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed core second-opinion-wanted Add this label when a reviewer needs a second opinion from another member.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants