TP-Link/Tapo: switch to real device names

[CiNcH83]

This should add more clarity about which devices are supported. I decided to go with separate brand entries for each device. We could also do one entry and add all devices in a single line, like:

  - brand: TP-Link
    description:
      generic: HS100/HS103/HS105/HS110 Smart Plug

/cc @thierolm

[sourcery-ai]

Hey - I've left some high level feedback:

• Consider using a consistent style for the products entries (either inline { ... } mappings or the multi-line mapping style) across all tplink/tapo YAML files for readability and uniformity.
• In templates/definition/meter/tplink.yaml you still use a single generic HS110 entry while the charger definition lists all HS* devices explicitly; it might be clearer to align these and explicitly list only models that actually support metering.
• Tapo P110 and P115 are now duplicated between charger/tapo.yaml and meter/tapo.yaml; if their capabilities differ, consider clarifying that distinction in the descriptions or otherwise structuring the entries to avoid confusion about which definition applies.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Consider using a consistent style for the `products` entries (either inline `{ ... }` mappings or the multi-line mapping style) across all tplink/tapo YAML files for readability and uniformity.
- In `templates/definition/meter/tplink.yaml` you still use a single generic `HS110` entry while the charger definition lists all HS* devices explicitly; it might be clearer to align these and explicitly list only models that actually support metering.
- Tapo P110 and P115 are now duplicated between `charger/tapo.yaml` and `meter/tapo.yaml`; if their capabilities differ, consider clarifying that distinction in the descriptions or otherwise structuring the entries to avoid confusion about which definition applies.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[thierolm]

@andig is a mixture of yaml and json style acceptable?

[andig]

Yes, no problem

[thierolm]

PR is fine for me. 👍

[andig]

@naltatis I'm not a big fan of this. Instead of saying "we're supporting P Series" we're now mentioning every device. When a new P-Series device appears it will automatically look unsupported just because it's not mentioned. The config docs do NOT convey any notion of "these are the same config". Imho this is a bad idea that we are continuing to spread.

[CiNcH83]

There is in fact already a new one, the P410M. But I don't know whether this works with the same implementation. Unlike the others, it is explicitly declared as Matter compatible.

HS is EOL.

[naltatis]

The config docs do NOT convey any notion of "these are the same config". Imho this is a bad idea that we are continuing to spread.

Mentioning explicit devices has two major benefits.

1. Users have explicit confirmation that their concrete device is supported. They dont have to browse the manufacturers website to understand how their product ranges/groups work. We e.g. had a lot of confusion in the past around shelly devices.
2. Having concrete names also helps people find the implementation via Google or LLM. No-one searches for "Tapo P-Series" when they have a "Tapo P110" on their desk.

Agreed, this is extra manual documentation effort and we need to to keep it up to date. But the benefits definitely justify this.

[andig]

But the benefits definitely justify this.

Even if, we should find a better way than duplicating the config over and over. We could still mention devices while keeping the configuration once. That would generate coherence and signal "all these are the same (and if you have something similar it probably belongs here)"

[CiNcH83]

I for example wasn't so sure whether my HS110 was covered by the H-Series support. So I just tried...

[andig]

That's irrelevant. It surely isn't P-series and we'll only ever know for any "supported" device if it really works once it has been tested.

[CiNcH83]

Guess that the P100 won't work as meter even though P-Series suggests it is supported.

[andig]

But that's also relevant. Even if it's not mentioned you still wouldn't know why...

[naltatis]

Even if, we should find a better way than duplicating the config over and over. We could still mention devices while keeping the configuration once.

Not sure what you mean with "configuration". Do you want to extend the product structure by adding another field? Allowing an array for description to keep the templates more dry? Or is your issue, that product entries currently map to flat select entries in the configuration UI?

[andig]

If I want to test HS110, which config do I try if there's no H-Series? Do I need to try all 5 individual H xyz configs? How do I realize these are all really identical?

[naltatis]

How do I realize these are all really identical?

The identical implementation info is not relevant for the user. He only wants a working setup.

Do I need to try all 5 individual H xyz configs?

Yes, trying a similar device (when mine is not in the list) probably is a thing people would do. This would lead to people reporting success and adding their device to the template as working. Helping all users that follow. We currently dont capture this information.

I'm not against keeping the "product series" info, extending products and introducing another field.

 - brand: TP-Link
   description:
     generic: H-Series Smart Plug
+  devices: [HS100, HS103]

In many cases (Shelly, Elli) there are no clear and obvious "product series/group" descriptions and being concrete is the best way to avoid confusion.

[andig]

If I want to test HS110, which config do I try if there's no H-Series? Do I need to try all 5 individual H xyz configs? How do I realize these are all really identical?

That question in mind:

I'm not against keeping the "product series" info, extending products and introducing another field.

How would that influence documentation or device selection in UI? Specifically, how does that ensure that a user only has to try a "family" of devices that share the identical implementation instead of trying each device individually?

Imho we can already do that today without new config, see op:

Tapo HS100/HS103/HS105/HS110 Smart Plug