Skip to content

PV child publishes rated power as info/nameplate-capacity in W, but info.md defines that property as energy and routes power-rated devices to nominal-power #12

Description

@dcj

Problem

capabilities/info.md defines nameplate-capacity as an energy quantity and explicitly routes power-rated devices elsewhere:

nameplate-capacity | float | energy | MAY | Rated nameplate energy capacity, a term of art for energy-storage devices, reported in the device's native energy unit (a BESS in kWh electrical, a storage water heater in Wh thermal) via $unit. [...] Energy-storage device types (BESS, thermal storage) SHOULD publish it; power-rated devices (PV, inverter, EVSE) publish rated power via nominal-power instead.

devices/distribution-enclosure.md then gives the proxied PV child exactly that property, in watts:

| `nameplate-capacity` | float | W | SHOULD | Nameplate capacity. |

and both worked examples publish it (info/nameplate-capacity 6000 and 81).

So a PV array's rated power is published under the property the catalog reserves for stored energy, carrying a unit from a different dimension. nominal-power, which info.md names as the correct property for exactly this case, is not used there.

Why it matters beyond tidiness

nameplate-capacity carries the abstract energy unit token documented in conventions/property-json.md, which exists precisely because stored-energy magnitudes are reported in the device's native energy unit and are not comparable across device classes. A consumer that reads nameplate-capacity and expects an energy figure, per the catalog, gets a power figure from any PV child. Nothing in $description distinguishes the two, since both are floats and the $unit is whatever the publisher writes.

It also makes soc's relationship unsound where it is stated: info.md says soc is roughly soe / nameplate-capacity, which is meaningless if the denominator is watts.

Suggested resolution

Publish PV rated power as nominal-power on the PV child, matching info.md:21 and :36, and drop nameplate-capacity from that table. The two examples move with it.

Worth checking the same pattern on the EVSE child and on any inverter child while this is open, since info.md names all three as power-rated.

Note on the reference implementer

The shipping reference publisher already emits pv/info/nominal-power, i.e. the property info.md prescribes. It is the device model that diverges, not the implementation.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions