Tariff templates: add usages to restrict grid or feed-in

[naltatis]

pairs with evcc-io/docs#1184, follow-up to #33635

Tariff templates with group: price are offered in both the grid and the feed-in modal. Supplier import tariffs show up as feed-in options and feed-in remunerations as grid tariffs. A new top-level usages field lets a template declare which direction it fits.

• usages: ["grid"] or usages: ["feedin"] on a tariff template. Omitted means both, so raw market data (Energy-Charts, ENTSO-E, Nordpool, …) and templates with a direction param (Octopus API, Amber, Esios, …) stay unchanged.
• Products endpoint filters tariff templates by the existing usage query param. The tariff modal passes grid, feedin, or grid for the planner.
• Tagged grid only: Tibber, Ostrom, Octopus Germany, CKW, EKZ, EWS, Groupe E, smartENERGY. Tagged feed-in only: BKW.
• Generated docs emit usages, the docs side lists templates under grid or feed-in and uses the matching tariffs: key in yaml examples.

TODO

• tag feedin-de-2025 from Tariff: forfeit feed-in tariff on negative exchange price (§ 51 EEG) #33635 with usages: ["feedin"] once both are merged

🤖 Generated with Claude Code

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="templates/definition/tariff/octopus-it.yaml" line_range="12" />
<code_context>
 requirements:
   evcc: ["skiptest"]
 group: price
+usages: ["grid"]
 countries: ["CH"]
 params:
</code_context>
<issue_to_address>
**issue (bug_risk):** The Octopus Italy tariff template is marked as grid-only, so it is removed from the feed-in tariff options. The change description lists only Octopus Germany among the Octopus templates to tag, leaving Octopus Italy unrestricted.

**Triggers:** When configuring a feed-in tariff for an Octopus Italy installation.

**Suggested fix:** Remove `usages: ["grid"]` from `octopus-it.yaml` unless the Italian product is intentionally grid-only.

```suggestion

```
</issue_to_address>

Sourcery assessment

Approval pending. 1 finding to address first.

Blocking findings: templates/definition/tariff/octopus-it.yaml:12

---

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

• X
• Mastodon
• LinkedIn
• Facebook

[andig]

Since the param is usages- shall we keep it Usages here for sake of consistency? Template is a general construct anyway?

[andig]

Other option: we already have group- differentiate that group further?

[naltatis]

I also looked a group. Did decide against it because we have tariffs that can be part of both groups (today all are). Or we would have to introduce three groups (grid, feedin, grid_feedin). The filter products by usage mechanism already exists (meter usages) in the api endpoints.

[andig]

Or we would have to introduce three groups (grid, feedin, grid_feedin). The filter products by usage mechanism already exists (meter usages) in the api endpoints.

This is different since we're not filtering on a parameter. The asymmetry is ugly?

[naltatis]

Template is a general construct anyway?

Good point

Since the param is usages- shall we keep it Usages here for sake of consistency?

This conflicts with the existing Usages method. We would have to merge the usages (meter/tariff) than.

I'll give this a second round ...

[naltatis]

I've changed it. Replacing the specific TariffUsages with Usages.

For meters it's required to have a usage param. Noticed that two meters (growatt-min-tlxe, ada-p1-meter) didnt have it and were thereby absent from docs and ui configuration. Added this param there.

For tariffs usage is now top level and restricts the usage (grid, feedin). If absent both are allowed. We could also move the meters model of having it as a param. This would enable using the same template for feedin or grid but with logic differences in render block. But I currently dont see any use-case for this. So static top level is the easier way and we get the usage based filtering (config ui, docs) for free (same as meters).

[andig]

We could also move the meters model of having it as a param.

Not sure how exactly, but consistency would be nice. Not that some devices need the usage routed through to the backend...