Add Energy management built in types to ZAP tool

[jamesharrow]

As part of Spring 2024 we are targetting new Energy Management clusters which have introduce 4 new types (like epoch_s):

This spec PR has added new changes to Data-Model.adoc: https://github.com/CHIP-Specifications/connectedhomeip-spec/pull/7830/files#diff-05653d18812836190adf870ff988791e0e3901478a63ab1eca4c3e9df0168a8c

                 | Power                       s| <<ref_DataTypePower, power-mW>>          | int64     | 0xD9 | 8 bytes
                 | Amperage                    s| <<ref_DataTypeAmperage, amperage-mA>>    | int64     | 0xDA | 8 bytes
                 | Voltage                     s| <<ref_DataTypeVoltage, voltage-mW>>      | int64     | 0xDB | 8 bytes
                 | Energy                      s| <<ref_DataTypeEnergy, energy-mWh>>       | int64     | 0xDC | 8 bytes

[[ref_DataTypePower, Power]] ==== Power This type, derived from int64, represents power measured in milliwatts.

[[ref_DataTypeAmperage, Amperage]] ==== Amperage This type, derived from int64, represents amperage measured in milliamps.

[[ref_DataTypeVoltage, Voltage]] ==== Voltage This type, derived from int64, represents voltage measured in millivolts.

[[ref_DataTypeEnergy, Energy]] ==== Energy This type, derived from int64, represents energy measured in milliwatt-hours.

https://github.com/project-chip/zap/blob/346129357ae10897c17be991b6220989e3f3d7bf/zcl-builtin/matter/data-model/chip/chip-types.xml#L57

These need to be added to ZAP tool to unblock chip repo Issues: https://github.com/project-chip/connectedhomeip/issues/30665

and it's PR: https://github.com/project-chip/connectedhomeip/pull/30701

[jamesharrow]

I may withdraw this issue - since it looks like the logic is in chip repo and possibly not needed here...

[brdandu]

@jamesharrow this requires a xml change in the Matter GSDK. What we have in ZAP is just default meta data which allows zap to be tested. Actually xml/json meta data should be retrieved from the GSDKs. Are there any other concerns here or is it ok to close this issue here?

[jamesharrow]

I think this issue can be closed now - it was raised during development of 1.3 and we now have that working.