Skip to main content

Protocol version changelog

This page tracks changes to the Tensor Cloud battery optimization protocol. The version reflected here is info.version in the AsyncAPI specification and the schema_version field every EMS emits on every message.

Versioning follows semver-style: MAJOR.MINOR.PATCH.

  • MAJOR - backwards-incompatible changes to topic structure, payload shape, or required fields that existing integrations cannot satisfy without code changes.
  • MINOR - additive changes (new fields, new conditional validation, new behaviour) that strengthen guarantees but remain readable by clients on prior versions. Tensor Cloud remains backwards-compatible with messages emitted under older minor revisions.
  • PATCH - documentation clarifications, example corrections, and other changes with no payload impact.

2.3.0 - 2026-06-16​

FCR Assessment II telemetry.

  • The instantaneous-power topics (dt/{siteId}/{gatewayId}/{metric}/power) are now documented as the channel for offline FCR Assessment II data. Resources offering FCR must publish 1-second-resolution supplied power for every FCR-awarded slot, via meter_export_ac/meter_import_ac (grid-connection-point registration) or battery_discharge_ac/battery_charge_ac (equipment-point registration). Tensor Cloud assembles the TSO's Assessment II template (Form 35) from this data and submits it on behalf of the aggregator. See the integration guide's "FCR Assessment II telemetry" section.
  • powerTelemetry channel description in the AsyncAPI specification updated to note this Assessment II use.
  • PowerInstant.measurement_value gains two optional fields: aggregation (instant default, or average) and aggregation_window (ISO-8601 duration, e.g. PT1S), with aggregation_window conditionally required when aggregation is average (enforced via JSON Schema if/then). This lets a power sample declare whether it is an instantaneous point reading or a windowed mean; FCR Assessment II uses average over PT1S. Additive and backward-compatible: omitting both fields keeps the prior instantaneous semantics, and prior-version messages remain accepted.

2.2.0 - 2026-05-28​

Alerts, acknowledgements, and commands strengthened.

  • schema_version is now required on AlertEvent and AlertState payloads. Previously the field was defined but not in the required list of either alert message. Tensor Cloud continues to accept alert payloads emitted under prior versions that omit schema_version; EMS implementations should add the field to alert payloads going forward.
  • CommandResponse.errors is now conditionally required by the schema: present (≥ 1 item) when status: "error", absent when status: "ok". Enforced via JSON Schema if/then/else. Previously the rule was prose-only. No producer-side change required for EMS implementations that already followed the prose rule.
  • TelemetryFeedback.code and TelemetryFeedback.detail are now conditionally required by the schema: both present when status: "error", both absent when status: "ok". Enforced via JSON Schema if/then/else. Affects the testing-only telemetry feedback channel; Tensor Cloud is the producer, EMS implementations only consume.
  • BatteryFcrCommand.control.schedule[*].capacity_kw is now conditionally required by the schema: required when control.action is execute (the default) and forbidden when control.action is cancel. Enforced via JSON Schema if/then/else.
  • BatteryPowerCommand.control.schedule and BatteryFcrCommand.control.schedule now declare minItems: 1. Empty schedules are rejected at the schema layer.
  • Embedded schema examples corrected: CommandResponse examples now include the required schema_version; FCR cancel examples use message_id values that match the documented ^msg_[0-9a-f]{8}-…$ pattern.
  • Top-level additionalProperties is now true on every message family (including BatteryPowerCommand and BatteryFcrCommand). Previously commands were strict and other families lenient - the asymmetry is removed so forward-compatibility is uniform across the protocol.

2.1.0 - Previous baseline​

Pre-changelog baseline. Includes the full set of telemetry, command, alert, and response channels documented in the integration guide and AsyncAPI spec.