Calendar tariff #609

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. 🙏

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.

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,

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!