Calendar tariff

[alexmc1510]

Hello, I have read setup guide and readme files but I am not able to understand how to setup tariff price based on calendar. In Spain, we pay a certain amount of money based on power * nb of days and energy consumption.
90% of people in Spain have the following periods for power and for energy.

I pay for example:

• Power: 0.09 * 30 days (month) * max power I have contracted at home 4,6kwh.
• Energy: depending on the period kwh * price.
• There are some other concepts in the invoice, fix price....like meter rent, tax + tax + tax + tax...and another tax.

If we want to really have a realistic € of our invoice we should have the possibility to include everything.

Yesterday I changed my electriciy contract to a new one and the app they offered is offering a really simple and nice feature. I introduced my investment on solar panel installation, my api connection details to the huawei fusion solar app to retrieve historical info and based on current tariff, the app was able to tell me....Your installation is already paid and you have generated 980€ savings on top...WoW.

Thanks in advance,

Regards

[traktore-org]

Hi @alexmc1510 — thanks for the detailed write-up, and great question! Here's where SEM stands against the three parts of a Spanish bill.

1. Energy term (time-of-use) — SEM has three tariff modes in Settings → Configure → Tariff & Advanced:

• Static — fixed import/export rates.
• Dynamic — reads a live price sensor (Tibber, Nordpool, aWATTar, Amber, Octopus).
• Calendar — time-based HT/NT windows.

The honest caveat for Spain: the Calendar mode currently only models 2 rate levels (peak/off-peak), not the 3 periods (P1 punta / P2 llano / P3 valle) that a Spanish energy term uses, and the per-day time windows aren't yet editable from the UI (only in-code presets exist today). So the 3-period energy structure can't be fully expressed right now.

2. Power/capacity term (0.09 × days × contracted kW) — not supported today. SEM has a Demand charge (per kW) setting, but that models a monthly peak-demand charge (your highest 15-min average), which is a different thing from Spain's fixed contracted-power term with two power periods.

3. Fixed costs, meter rent, taxes (IVA + the rest) — not modelled yet either.

The good news — the ROI feature you loved already exists in SEM! 🎉 Set your installation cost in number.sem_system_investment_cost, and SEM tracks:

• sensor.sem_lifetime_total_savings — total € saved,
• sensor.sem_roi_payback_years — when it pays off,
• sensor.sem_roi_percentage and sensor.sem_roi_annual_savings.

That's exactly the "your installation is already paid off, you've saved €980" experience you described — no external API needed.

For the full Spanish-tariff modelling (3-period energy + contracted-power term + fixed costs/taxes), I've filed #612 as an enhancement so the maintainer can pick it up. Credited to you. 🙏

[traktore-org]

Quick follow-up with the maintainer's scope decision on #612, so expectations are set right:

Coming: the Spanish tariff model. ✅ 3-period (P1/P2/P3) time-of-use energy pricing, a UI-configurable calendar schedule, and Spanish presets. With correct period prices, SEM's cost signals become accurate relative to your tariff — charge in valle, avoid punta — which is what actually drives the automation.

Not coming: invoice replication (contracted-power term, meter rent, taxes/IVA). ❌ This is a deliberate product boundary rather than a missing feature: SEM's cost figures are estimations that exist to drive decisions, computed from inverter/CT sensors that are not certified billing meters. Layering capacity terms and taxes on top of uncertified measurements would produce a convincing-looking but wrong bill — so SEM won't go there. Your supplier's invoice stays the source of truth for money; SEM stays the source of truth for what your system should do.

The ROI/savings experience you described is unaffected — that's estimation territory, and it works today as described above. The retitled issue tracking the in-scope work is #612.

[alexmc1510]

Hello,

Thanks for the acceptance of my proposal. To be honest, the main and important point is the one you accepted. The other was a nice to have but a stupid thing because it is something I can easily do with a template if I want.

For tariff, if you have a look at others integrations, they use tariff sensor which reduce complexity of the integration. If you want to reduce the workload, adding compatibility with a tariff sensor could be also an option, explaining always how that sensor should behave.

Thanks

Regards,

[traktore-org]

Great suggestion — and the good news is SEM already supports the tariff-sensor pattern today, so you don't have to wait for #612 to get a working setup. 👍

In Settings → Configure → Tariff & Advanced, pick Dynamic mode and set dynamic_tariff_entity to any Home Assistant sensor whose state is the current price in €/kWh. When you configure that entity explicitly, SEM treats it as the authoritative source ("custom" provider) and simply reads its numeric state each cycle — it doesn't have to be Tibber/Nordpool/Octopus. If the sensor also exposes an upcoming-price array in its attributes (a shape SEM recognises), SEM will use that for look-ahead too, but a plain current-price state is enough to drive the cost signals.

For Spain specifically, that means either:

• point it at a community price integration that already outputs the current €/kWh (e.g. the PVPC / ESIOS sensors), or
• if you're on a fixed 3-period contract, a tiny template sensor that maps the current P1/P2/P3 period → your contracted price, exactly as you mentioned you're comfortable doing. Point dynamic_tariff_entity at that template and SEM will charge in valle, avoid punta, etc.

The requirement for such a sensor is simply: its state must be a single numeric current price in €/kWh (no unit prefix), updating as the period changes.

I've relayed your tariff-sensor idea to #612 as the suggested lower-complexity implementation path for native Spanish presets — credited to you. 🙏 Thanks for the thoughtful feedback!