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.
Problem
capabilities/info.mddefinesnameplate-capacityas an energy quantity and explicitly routes power-rated devices elsewhere:devices/distribution-enclosure.mdthen gives the proxied PV child exactly that property, in watts:and both worked examples publish it (
info/nameplate-capacity 6000and81).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, whichinfo.mdnames as the correct property for exactly this case, is not used there.Why it matters beyond tidiness
nameplate-capacitycarries the abstractenergyunit token documented inconventions/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 readsnameplate-capacityand expects an energy figure, per the catalog, gets a power figure from any PV child. Nothing in$descriptiondistinguishes the two, since both are floats and the$unitis whatever the publisher writes.It also makes
soc's relationship unsound where it is stated:info.mdsayssocis roughlysoe / nameplate-capacity, which is meaningless if the denominator is watts.Suggested resolution
Publish PV rated power as
nominal-poweron the PV child, matchinginfo.md:21and:36, and dropnameplate-capacityfrom 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.mdnames all three as power-rated.Note on the reference implementer
The shipping reference publisher already emits
pv/info/nominal-power, i.e. the propertyinfo.mdprescribes. It is the device model that diverges, not the implementation.