Publish data model v2 to NovaCore (json/v2) and accept v2 keys from drivers #1527

Problem

FTW publishes to NovaCore in the 1.x format only. NovaCore now has a data model v2 path (srcful-data-models 2.3.0, subject …/telemetry/json/v2). Sourceful's NovaCore consumers (apps, portal, dashboards, EMS) move to v2 only, with no v1 fallback; devnet is first. Gateways still on v1 get a v2 update before those consumers move further.

FTW is out of scope for the current rollout. Until FTW publishes v2, an FTW gateway's telemetry disappears from every consumer that has moved, even though NovaCore still accepts its v1 messages. v1 and v2 are separate subjects, and nothing translates between them.

Where FTW is 1.x today (master)

• go/internal/nova/names.go: the subject is gateways/{serial}/devices/{hardware_id}/ders/{der_name}/telemetry/json/v1.
• go/internal/nova/adapter.go: SchemaLegacy → toLegacy writes the 1.x names (W, Hz, L1_V, total_import_Wh, SoC_nom_fract, …). Its own comment calls it "the deletable bridge" until a unified schema exists. v2 is that schema.
• go/internal/nova/payload.go: the DER kinds are pv, ev and v2x_charger. In v2 they are solar and ev_charger_port, and inverter is its own DER (the AC output stage).
• go/internal/drivers/telemetry_keys.go: the alias table knows the 1.x data-models spellings (W, SoC_nom_fract, L1_V, rated_W, …) but none of the v2 names. A catalog driver that moves to v2 keys would lose its data here, because DerTelemetry drops an unknown key without an error.

What v2 needs

1. A v2 encoder and subject: …/telemetry/json/v2, one flat object per DER per reading. All rules come from the data model (REFERENCE):
   • Every field of the DER type is present, and an unread value is null, never 0.
   • Every W/V/A/VA/Wh field carries _ac or _dc. A battery's own measurement is DC.
   • timestamp is epoch ms, and read_time_ms is null when not measured.
   • make is the lowercase brand (^[a-z0-9]+(_[a-z0-9]+)*$).
   • Sign convention: + import/charge, − export/generation/discharge.
2. v2 aliases in telemetry_keys.go: W_ac, W_dc, soc_nom_fract, l1_V_ac, l1_A_ac, l1_W_ac, total_import_Wh_ac, total_export_Wh_ac, total_charge_Wh_dc, rated_power_W_ac, mppt1_V_dc, and so on. The catalog can then move to v2 keys (Catalog: move emit keys and DER types to data model v2 device-drivers#171) without a second round of host changes.
3. Control: I found no NovaCore control subscription in go/internal/nova. If FTW takes NovaCore control later, v2 is power_W_dc in, and an ack on …/control/ack/json/v2 carrying actual_power_W_dc, the setpoint actually commanded.

Related:

• Catalog: move emit keys and DER types to data model v2 device-drivers#171: the catalog moves its keys and DER types to v2.
• zap: read the Zap's data model v2 local API (pv → solar, W → W_ac, ...) device-drivers#170: zap.lua and the Zap's v2 local API.
• 44 drivers emit numbers they never read (null, never 0) device-drivers#169: drivers that emit numbers they never read.
• docs(spec): describe srcful-data-models v2 in the migration note device-drivers#166: the migration note in spec/host-api.md.

Out of scope for the current data model rollout: tracked here so FTW does not fall behind.

🤖 Generated with Claude Code