17track wrong entity IDs?

[naps62]

The problem

From checking the documentation and source code, it seems entities generated by 17track should be prefixed with seventeentrack_. however, in my case they ended up as 17track_ which causes a syntax error when attempting to access those values in yaml, such as:

I manually renamed all default sensors to the text prefix, but new ones (for incoming packages) are still being created with the number-based name:

What version of Home Assistant Core has the issue?

core-2024.6.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

17Track

Link to integration documentation on our website

https://www.home-assistant.io/integrations/seventeentrack/

Diagnostics information

No response

Example YAML snippet

{{ states.sensor.17track_in_transit }}

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @shaiu, mind taking a look at this issue as it has been labeled with an integration (seventeentrack) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `seventeentrack` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign seventeentrack` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

seventeentrack documentation seventeentrack source _{^{(message by IssueLinks)}}

[joostlek]

We are trying to move away from these dynamic entities and move towards using service calls to gather data from packages, so rather try looking into that direction

[naps62]

Ah, got it. wasn't aware of this, and was apparently following examples of the old format

for anyone that ends up here, this is what I changed to work with service calls:

- {% for package in states.sensor.17track_ready_to_be_picked_up.attributes.packages %}
+ {% for package in state_attr('sensor.17track_ready_to_be_picked_up', 'packages') %}

[joostlek]

But those will be removed soon as well, you should use a service call to populate entities with the data you need

[naps62]

Then I guess I'm confused. I know it's already offtopic, but could you give a few pointers?

What I want to do is show a markdown card in my dashboard listing some details about both "ready to be picked up" and "in transit" packages (and do not show anything at all if both of these are empty)

What's the future-proof way of doing this?

[joostlek]

There are a lot of examples with how it works with todo list, calendar items and mostly weather integrations. We don't have any example for seventeen track yet, so if you can share your findings that'd be great as well

[shaiu]

@naps62 I've built a small automation that calls the service once a minute and populates an input text:

alias: 17Track packages
description: ""
trigger:
  - platform: time_pattern
    seconds: "30"
condition: []
action:
  - service: seventeentrack.get_packages
    metadata: {}
    data:
      package_state:
        - ready_to_be_picked_up
        - in_transit
        - delivered
      config_entry_id: <your_config_entry_id>
    response_variable: my_packages
  - service: input_text.set_value
    data_template:
      value: >-
        {% for package in my_packages.packages %} {{package.tracking_number}} {%
        endfor %}
    target:
      entity_id: input_text.in_transit_packages
mode: single

You can then use the input_text.in_transit_packages (which you need to create before hand) in your markdown card like this for example:

{% set packages = states('input_text.in_transit_packages').split() %}
{% for package in packages %}
- {{ package }}
{% endfor %}

I hope this can help.

[naps62]

After trying to follow up on this I'm still a bit confused

@shaiu 's solution above works, but there's a problem: input_text are limited to 255 characters. I want to build a fairly complex markdown snippet based on a few states and attributes of 17track packages.

I also don't see the point of doing this indirection (triggering an automation to populate a text entity) when I can simply access the attributes of the original 17track sensors using state_attr directly on a markdown card

@joostlek said these were being removed, but I can't find any mention of such thing, and the haas docs still reference state_attr as a valid way to do things. so I'm not sure what it is I'm not getting

[shaiu]

@naps62 you can have multiple input_text as a solution for the limit.

The idea of removing these sensors is because they are originally were written as limited time sensors, i.e. in_transit sensors were needed to be removed as soon as the packages were changes to delivered state. This became very complicated logic and also not best practice for sensors as they should be static and not dynamic (the sensors themselves and not their values) These sensors are currently deprecated and will be removed in next versions and I'm working on a PR that will have a repair flow in order for people to migrate to automations.

[naps62]

oh, so you're saying the specific 17track sensors (such as in_transit) are being removed. I understood you were saying that functions such as state_attr are being removed in the near future from homeassistant itself

@naps62 you can have multiple input_text as a solution for the limit.

I honestly don't understand how this can be a solution. I understand the problem with time-limited sensors. but all I'm doing is accessing attributes of sensors that suposedly are not time limited (i.e.: I'm reading attributes for 17track_in_transit and not the individual sensors created for each package)

What you're suggesting is that I generate the whole markdown string I want to render, and then split it into blocks of 255chars, store each in a separate input_text, and then concat those again in the lovelace card? That sounds absurd

For the record, here's my current temporary solution, as a simple card with no automations (though I wanted to add more features to this, which I'm not yet sure are possible):

{% if int(states('sensor.17track_in_transit')) > 0 %}
## In Transit
{% for p in state_attr('sensor.17track_in_transit', 'packages') %}
{% set name = p.friendly_name if p.friendly_name is not none else p.tracking_number %}
{% set text = p.info_text %}
- **{{ name }}**: {{text}}
{% endfor %}
{% endif %}

{% if int(states('sensor.17track_ready_to_be_picked_up')) > 0 %}
## In Transit
{% for p in state_attr('sensor.17track_ready_to_be_picked_up', 'packages') %}
{% set name = p.friendly_name if p.friendly_name is not none else p.tracking_number %}
{% set text = p.info_text %}
- **{{ name }}**: {{text}}
{% endfor %}
{% endif %}

{% if int(states('sensor.17track_delivered')) > 0 %}
## In Transit
{% for p in state_attr('sensor.17track_delivered', 'packages') %}
{% set name = p.friendly_name if p.friendly_name is not none else p.tracking_number %}
{% set text = p.info_text %}
- **{{ name }}**: {{text}}
{% endfor %}
{% endif %}

[joostlek]

I think a common thing is that people put stuff in state attributes, but I have to check that with some others

[shaiu]

@naps62 if you're using the summary sensors (i.e. in_transit) you're all set. Those aren't being removed. Only the specific package sensors.