Add transmission info about torrents that is accessible with templating

[JPHutchins]

Description:

Added is a new sensor that contains a dictionary of "started torrents" in its state attribute. The inspiration comes from the add_torrent service implemented with an input_text entity. Ultimately I believe Home Assistant can act as a simple interface for adding, sorting, and observing torrent progress, very useful to friends and family that have a hard time managing their Linux ISOs in the regular interface.

This example is just to see if there is interest. I am trying to learn HA architecture while improving my programming ability. To this end I would like to know if a better implementation would be for torrents to be registered as entities (like how discovery or device tracker does)?

Example state attribute:

Here is what you can expect in Developer Tools->States->sensor.transmission_started_torrents->Attributes.

torrent_info: {
  "torrent_file_1_as_added_to_transmission": {
    "added_date": 1569812023,
    "percent_done": "5.83",
    "eta": "02:04:30"
  },
  "torrent_file_2_as_added_to_transmission": {
    "added_date": 1569812048,
    "percent_done": "68.03",
    "eta": "00:05:14"
  }
}

Example templating:

Add a Markdown card like this one. This took me forever Jinja and I do not understand one another.

content: >
  {% set payload = state_attr('sensor.transmission_started_torrents', 'torrent_info') %}

  {% for torrent in payload.items() %} {% set name = torrent[0] %} {% set data = torrent[1] %}
  
  {{ name|truncate(20) }} is {{ data.percent_done }}% complete, {{ data.eta }} remaining {% endfor %}
type: markdown

Clicking on the started_torrents sensor for "more info" yields inadequate results - can this be templated?

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][dev-checklist]

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

• Documentation added/updated in home-assistant.io
  Documentation added: Add info about torrents that is accessible with templating home-assistant.io#10574

Cheers,
J.P.

[frenck]

Thank you for your contribution thus far! 🎖 Since this is a significant contribution, we would appreciate you'd added yourself to the list of code owners for this integration. ❤️

Please, add your GitHub username to the manifest.json of this integration.

For more information about "code owners", see: Architecture Decision Record 0008: Code owners.

[JPHutchins]

Documentation has been updated, not sure how to remove the docs-missing tag. Thanks!
home-assistant/home-assistant.io#10574

[MartinHjelmare]

Thanks!

@engrbm87 ok?

[engrbm87]

I suggest that we use the already existing started_torrents sensor and assign the torrent_info to its attribute instead of creating a new sensor. If the sensor state is > 0 then the attributes will show the info about the started torrents.
Same can be done for completed_torrents.
@MartinHjelmare One concern is that if there are a lot of started torrents (downloading or pending download) will that be a problem to have an attribute with a lot of data?

[MartinHjelmare]

Generally we prefer individual sensors over many sensor attributes.

I don't known what's best in this case.

[JPHutchins]

Ultimately I intended to use the date_added attribute to truncate the dictionary of started torrents to the five (or some number) most recent. The most important thing is that the user sees quick feedback when they call the add_torrent service - new torrent appears at the top of the list with ETA - and I love the idea of seeing a few of the most recent completions as well.

OK to change to started_torrents attr.

@engrbm87 You have also added a config flow that eliminates the need for the monitored_conditions: entry in the configuration.yaml? I would love to learn how to dynamically create an entity for each torrent. Ultimately that would make it easier for the end user to make a GUI. We would definitely want to carefully truncate the number of torrents that could be registered in this way. Thanks for your help!

[engrbm87]

@JPHutchins It will be nice to see the torrent details in the GUI especially for torrents being downloaded. I don't think it is a good idea to create a new entity for each torrent. We should be in control of which entities are added to HA.
If you can manage to show the torrent info for the torrents that are downloading only as put them as an attribute for the started_torrents sensor that would be good as the torrents being downloaded are usually limited.
It would be good idea to test adding 5 to 7 torrents and see how the attribute looks in the more-info dialog of the sensor.

[JPHutchins]

@engrbm87 I have made a small update and added photos. Obviously this needs further thought. Sorry if I missed any leftovers in the code, I will continue tomorrow. For some reason my development hass kept loading an old IP and Port for transmission (I wanted to setup a phony transmission for testing) even though hass was otherwise parsing the configuration.yaml. It did not even respect a complete removal of the transmission component from the yaml. Does this have to do with the new config flow?

[JPHutchins]

The trouble I was having did have to do with the new config flow. An edit of the transmission entry in the configuration.yaml would not have any effect on the integration - it was necessary to delete transmission from the integrations frontend and then re-add. Registering was smooth, good work on that config flow!

[MartinHjelmare]

@engrbm87 please approve when this is ready and I'll merge.

[engrbm87]

Hi @MartinHjelmare,
I would like to get PR #28136 approved and merged first then @JPHutchins can update his code as discussed to get this merged as well.

[JPHutchins]

I don't think there should be any need to make changes since PR #28136. I'd like to get it out in this form, displaying a dictionary of the downloading torrents as a state_attr of the started_torrents sensor, so that hopefully a front end person will be inspired.

[engrbm87]

Hello @JPHutchins ,
The new PR has some changes so you will need to rebase your branch and apply your commits again.

[JPHutchins]

@engrbm87 Thank you for your patience and help, I am learning so much!

[engrbm87]

Can you please explain the need for this? in the SENSOR_TYPES you specified all as None.

[JPHutchins]

This is removed as it was leftover from the original torrent_info sensor.

[engrbm87]

You can directly use self._transmission_api.started_torrent_dict without the need to store it in self._torrent_info

[JPHutchins]

I have removed this - now when the sensor started_torrents is updated it checks for torrent info:

@property
    def device_state_attributes(self):
        """Return the state attributes, if any."""
        if self._tm_client.api.started_torrent_dict and self.type == "started_torrents":
            return {STATE_ATTR_TORRENT_INFO: self._tm_client.api.started_torrent_dict}
        return None

[engrbm87]

You are only using the downloading status. I recommend removing _TRPC and use downloading directly.

[JPHutchins]

I have removed these - if transmissionrpc ever changed their codes they can be found here: https://bitbucket.org/blueluna/transmissionrpc/src/default/transmissionrpc/torrent.py

[engrbm87]

I recommend removing this as it would increase the list of torrents in the attribute if the user has many pending torrents. We should only focus on torrents being downloaded.

[JPHutchins]

Agreed!

[engrbm87]

Unused method. Either remove it or use it in the sensor attributes check.

[engrbm87]

Great @JPHutchins
Hello @MartinHjelmare the code changes are approved.

[engrbm87]

Approved

[MartinHjelmare]

Thanks!