Goal
Review FTW's tariff and demand model in text before we resume C&I implementation.
This issue defines the contract. It does not ask for code yet. Contributors are welcome to add utility documents, tariff examples, edge cases and review comments here.
Why this review comes first
The ideas explored in #845–#852 cover several separate concerns at once: device power limits, tariff schedules, demand accounting, optimizer input, control enforcement and UI. The review found useful parts, but the combined stack did not provide one agreed source of truth for billing time, direction, missing data or hardware limits.
Thank you @Sanjin-Maker for exploring this area in depth. The closed PRs remain useful research and will be referenced during this review.
Required source material
Before we choose a design, add at least one named, current utility tariff with a link or attached source document. For each tariff, state:
- market, utility and product name;
- effective dates and time zone;
- energy bands and local clock rules;
- demand-window length and alignment;
- billing-cycle and peak-selection rule;
- import, export, reactive-power and apparent-power treatment;
- missing, stale and partial-interval treatment;
- contracted or nominated capacity rules.
Related background:
Contract questions
The written review must settle these points before an implementation issue is accepted:
- What is measured, with an explicit sign and direction for import and export?
- Which timestamps use UTC, and which rules use local civil time, including DST and non-whole-hour offsets?
- When is an interval complete enough to count?
- How do gaps, restarts and late samples affect billing state?
- How are billing cycles and peak timestamps reset and retained?
- When do we need real apparent power instead of a kW proxy?
- Which limits come from the tariff, the site contract and proven hardware ratings?
- Which values may affect planning, and which may affect live control?
- Which real tariff fixtures and failure cases prove the result?
Exit condition
This review ends with an accepted written contract and a small issue sequence. Each implementation issue must cover one concern, name its dependencies and test evidence, and lead to one focused PR. Control and UI work start only after the tariff and accounting foundations have passed review.
Goal
Review FTW's tariff and demand model in text before we resume C&I implementation.
This issue defines the contract. It does not ask for code yet. Contributors are welcome to add utility documents, tariff examples, edge cases and review comments here.
Why this review comes first
The ideas explored in #845–#852 cover several separate concerns at once: device power limits, tariff schedules, demand accounting, optimizer input, control enforcement and UI. The review found useful parts, but the combined stack did not provide one agreed source of truth for billing time, direction, missing data or hardware limits.
Thank you @Sanjin-Maker for exploring this area in depth. The closed PRs remain useful research and will be referenced during this review.
Required source material
Before we choose a design, add at least one named, current utility tariff with a link or attached source document. For each tariff, state:
Related background:
Contract questions
The written review must settle these points before an implementation issue is accepted:
Exit condition
This review ends with an accepted written contract and a small issue sequence. Each implementation issue must cover one concern, name its dependencies and test evidence, and lead to one focused PR. Control and UI work start only after the tariff and accounting foundations have passed review.