API: publish forecast as arrays with unix timestamps (BC)

[andig]

replaces #31765

The forecast is the largest payload evcc publishes and RFC3339 timestamps are the bulk of it. Publishing slots as [start, end, value] and solar entries as [ts, val] with unix seconds cuts it by two thirds, measured on a live instance with 2784 entries: 209 609 → 72 745 bytes.

Loadpoint plan/plan-preview and /api/tariff responses are untouched, they still use api.Rate with RFC3339 strings.

• forecast slots are published as [start, end, value], solar timeseries entries as [ts, val], timestamps in unix seconds
• the UI expands the arrays once in the store, so components keep reading { start, end, value } and { ts, val }, now in unix milliseconds instead of RFC3339 strings
• no encoding/json/v2, so this builds on the current Go baseline and does not need the 1.27 upgrade that core: publish forecast start/end/ts as unix timestamps (BC) #31765 pulled in

Breaking Change

• ha integration relevant? @marq24
• adjust iOS app widgets fix: accept forecast arrays in widget decoder app#225 @naltatis (v1.4.1 ✅)
• Garmin App Support Unix timestamps for forecast data METIQ-Solutions/evcc-garmin#180 @TheNinth7
• openHAB binding @marcelGoerentz
• evcc-io/docs: API documentation of the forecast payload (via API: generate /api/state documentation from UI types #32431 on release)

🤖 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="assets/js/utils/forecast.ts" line_range="38" />
<code_context>
+// milliseconds so components can keep using named fields and `new Date(...)`.
+// State arrives sharded, one key per forecast field, plus the whole object on
+// initial load.
+export function expandForecast(key: string, value: any): any {
+  if (!key.startsWith("forecast") || !value) return value;
+
</code_context>
<issue_to_address>
**issue (complexity):** Consider replacing the generic string-key-based `expandForecast` function with explicit, typed forecast field converters that the store layer calls directly to avoid key parsing and recursion.

You can keep the sharded update behavior while reducing the key-string + recursion complexity by making the transformation API explicit and typed, then using it from your store layer.

### 1. Replace string-based dispatch with typed helpers

Instead of `expandForecast(key: string, value: any)`, you can introduce explicit converters for the known wire types, and let the store call the appropriate one based on its own key logic:

```ts
// Explicit converters, no key parsing
export function expandFullForecast(forecast: {
  co2: WireForecastSlot[];
  feedin: WireForecastSlot[];
  grid: WireForecastSlot[];
  planner: WireForecastSlot[];
  temperature: WireForecastSlot[];
  solar: WireSolarDetails;
  // ...add other fields if needed
}) {
  return {
    co2: expandSlots(forecast.co2),
    feedin: expandSlots(forecast.feedin),
    grid: expandSlots(forecast.grid),
    planner: expandSlots(forecast.planner),
    temperature: expandSlots(forecast.temperature),
    solar: expandSolar(forecast.solar),
  };
}

export type ForecastField =
  | "co2"
  | "feedin"
  | "grid"
  | "planner"
  | "temperature"
  | "solar";

export function expandForecastField(
  field: ForecastField,
  value: WireForecastSlot[] | WireSolarDetails
): ForecastSlot[] | SolarDetails {
  switch (field) {
    case "solar":
      return expandSolar(value as WireSolarDetails);
    default:
      return expandSlots(value as WireForecastSlot[]);
  }
}
```

Then the store can keep using its `forecast.*` keys but route them through the typed functions instead of having `expandForecast` depend on string conventions:

```ts
// Example usage in the store layer
if (key === "forecast" && value) {
  nextState.forecast = expandFullForecast(value);
} else if (key.startsWith("forecast.")) {
  const [, field] = key.split(".") as [string, ForecastField];
  (nextState.forecast as any)[field] = expandForecastField(field, value);
}
```

This preserves the sharded updates and initial full object handling, but makes the transformation code independent of key naming and removes the recursion on `expandForecast`.

### 2. Make solar wire/UI types explicit and local

You already have `WireSolarDetails` as a widened type. Moving it near the other wire types and delegating the conversion to a dedicated function improves clarity and removes the need for `any`/`Omit` in the main transformer:

```ts
// types.ts (or wherever the wire types live)
export type WireSolarDetails = {
  // same shape as SolarDetails, but with optional timeseries in wire form:
  timeseries?: WireTimeseriesEntry[];
} & Omit<SolarDetails, "timeseries">;

// converter module
export function toSolarDetails(wire: WireSolarDetails): SolarDetails {
  const { timeseries, ...rest } = wire;
  return {
    ...rest,
    timeseries: timeseries?.map(([ts, val]) => ({ ts: ts * 1000, val })),
  };
}
```

Then your forecast expansion code becomes simpler and more self-contained:

```ts
import { toSolarDetails } from "./toSolarDetails";

function expandSolar(solar: WireSolarDetails): SolarDetails {
  return toSolarDetails(solar);
}
```

These changes keep all current behavior but reduce cognitive load by:
- Removing generic `key: string, value: any` routing from the transformation layer.
- Replacing `SLOT_KEYS` + `key.split(".")` indirection with typed, explicit APIs.
- Encapsulating solar wire-to-UI conversion in a dedicated helper.
</issue_to_address>

---

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

[andig]

Addressed, though not the way suggested. The recursion was the real complexity and it was unreachable: publishTariffs always wraps the forecast in util.NewSharder, and server/socket.go emits sharded values as forecast.<field>, never a bare forecast key. The store is fed only from the websocket, so the whole-object branch could not run. It is gone, leaving one string split and two lookups.

The suggested split was not adopted. Routing in the store means reaching into state.forecast directly, which bypasses setProperty and needs an as any, and expandForecastField still dispatches on the same field name, just one layer further out.

Added tests for slot shards, the solar timeseries and pass-through of unrelated keys.

🤖 Generated with Claude Code

[TheNinth7]

The change has now been implemented in the Garmin app's v2.0.6-beta4, which supports both the old and the new data format. Testing of the new format will have to wait until the corresponding evcc release, however, as the transformation is performed server-side using JQ.

METIQ-Solutions/evcc-garmin#183

[marq24]

I have to admit, I AM LOST in the information generated by Claude (and probably that's already the root of my problem)... TooMuch inconsistent information (at least when I try to parse it)...

is it now just an int[] - or is this just the "old" change where the timestamp format has been replaced (which is already supported since a couple of weeks)...

[andig]

Start/end sind int, value ist float, also wie immer.

[marq24]

so 'original'

{
  "start": "2026-07-13T21:00:00+02:00"
  "end": "2026-07-13T21:15:00+02:00"
  "value": 222
}

intermed version #31765 (never released)

{
  "start": 1783969200 
  "end": 178396xx00
  "value": 222
}

now/new

[1783969200, 178396xx00, 222]

?!

[marq24]

implemented change in HA Integration https://github.com/marq24/ha-evcc/releases/tag/2026.8.0

[TheNinth7]

@andig There is also another integration to consider: the openHAB binding by @marcelGoerentz.

[andig]

ping @marcelGoerentz regarding openHAB

[marcelGoerentz]

Thanks, I will need to fix it in openHAB. But that should be a no brainer.

[andig]

@naltatis could you check if 9e2da18 is correct?

[andig]

@naltatis is this one good to merge?

[naltatis]

I've update the forecast data handling in UI to match the pattern we already use for loadpoints: state mirrors api structure, derived (computed) Ui__ types where applicable.

@naltatis is this one good to merge?

Yes, fine for me.