@matter/types 0.13.1-alpha.0-20250508-047aa0277 → 0.13.1-alpha.0-20250511-74ef153aa

package/src/clusters/door-lock.ts

@@ -131,7 +131,6 @@ export namespace DoorLock {
          * CredentialOverTheAirAccess (COTA)
          *
          * If this feature is supported then the lock supports the ability to verify a credential provided in a
-         *
          * lock/unlock command. Currently the cluster only supports providing the PIN credential to the lock/unlock
          * commands. If this feature is supported then the PIN Credential feature shall also be supported.
          *
@@ -1073,10 +1072,9 @@ export namespace DoorLock {
         /**
          * This field shall indicate the next occupied index in the database for the credential type requested, which is
          * useful for quickly identifying occupied credential slots in the database. This shall NOT be null if there is
-         * at least one occupied entry after the requested credential index in the corresponding
-         *
-         * database and shall be null if there are no more occupied entries. The NextCredentialIndex reported shall NOT
-         * exceed the maximum number of credentials for a particular credential type.
+         * at least one occupied entry after the requested credential index in the corresponding database and shall be
+         * null if there are no more occupied entries. The NextCredentialIndex reported shall NOT exceed the maximum
+         * number of credentials for a particular credential type.
          *
          * @see {@link MatterSpecification.v14.Cluster} § 5.2.10.39.5
          */
@@ -1093,10 +1091,10 @@ export namespace DoorLock {
          * Otherwise, the value of this field shall be the value of the relevant credential, as a 65-byte uncompressed
          * elliptic curve public key as defined in section 2.3.3 of SEC 1.
          *
-         * NOTE
+         * > [!NOTE]
          *
-         * Since the Aliro credentials are public keys, there is no security risk in allowing them to be read.
-         * Possession of the credential octet string does not allow operating the lock.
+         * > Since the Aliro credentials are public keys, there is no security risk in allowing them to be read.
+         *   Possession of the credential octet string does not allow operating the lock.
          *
          * @see {@link MatterSpecification.v14.Cluster} § 5.2.10.39.6
          */
@@ -1742,12 +1740,12 @@ export namespace DoorLock {
      *
      * * Interface Operational: Yes, No or N/A
      *
-     * NOTE
+     * > [!NOTE]
      *
-     * For modes that disable the remote interface, the door lock shall respond to Lock, Unlock, Toggle, and Unlock with
-     * Timeout commands with a response status Failure and not take the action requested by those commands. The door
-     * lock shall NOT disable the radio or otherwise unbind or leave the network. It shall still respond to all other
-     * commands and requests.
+     * > For modes that disable the remote interface, the door lock shall respond to Lock, Unlock, Toggle, and Unlock
+     *   with Timeout commands with a response status Failure and not take the action requested by those commands. The
+     *   door lock shall NOT disable the radio or otherwise unbind or leave the network. It shall still respond to all
+     *   other commands and requests.
      *
      * @see {@link MatterSpecification.v14.Cluster} § 5.2.6.15
      */
@@ -3217,7 +3215,6 @@ export namespace DoorLock {
              * Fields used for different use cases:
              *
              * Return status is a global status code or a cluster-specific status code from the Status Codes table and
-             *
              * shall be one of the following values:
              *
              *   • SUCCESS, if setting User was successful.
@@ -3242,10 +3239,8 @@ export namespace DoorLock {
             /**
              * Retrieve user.
              *
-             * An InvokeResponse command shall be sent with an appropriate error
-             *
-             * COMMAND, etc.) as needed otherwise the GetUserResponse Command shall be sent implying a status of
-             * SUCCESS.
+             * An InvokeResponse command shall be sent with an appropriate error (e.g. FAILURE, INVALID_COMMAND, etc.)
+             * as needed otherwise the GetUserResponse Command shall be sent implying a status of SUCCESS.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.10.33
              */
@@ -3638,11 +3633,10 @@ export namespace DoorLock {
              * door lock server to send PINs over the air. This attribute determines the behavior of the server’s TX
              * operation. If it is false, then it is not ok for the device to send PIN in any messages over the air.
              *
-             * The PIN field within any door lock cluster message shall keep the first octet unchanged and
-             *
-             * masks the actual code by replacing with 0xFF. For example (PIN "1234" ): If the attribute value is True,
-             * 0x04 0x31 0x32 0x33 0x34 shall be used in the PIN field in any door lock cluster message payload. If the
-             * attribute value is False, 0x04 0xFF 0xFF 0xFF 0xFF shall be used.
+             * The PIN field within any door lock cluster message shall keep the first octet unchanged and masks the
+             * actual code by replacing with 0xFF. For example (PIN "1234" ): If the attribute value is True, 0x04 0x31
+             * 0x32 0x33 0x34 shall be used in the PIN field in any door lock cluster message payload. If the attribute
+             * value is False, 0x04 0xFF 0xFF 0xFF 0xFF shall be used.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.9.34
              */
@@ -3703,10 +3697,10 @@ export namespace DoorLock {
             /**
              * Clear out all PINs on the lock.
              *
-             * NOTE
+             * > [!NOTE]
              *
-             * On the server, the clear all PIN codes command SHOULD have the same effect as the ClearPINCode command
-             * with respect to the setting of user status, user type and schedules.
+             * > On the server, the clear all PIN codes command SHOULD have the same effect as the ClearPINCode command
+             *   with respect to the setting of user status, user type and schedules.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.10.8
              */
@@ -3806,13 +3800,13 @@ export namespace DoorLock {
              * applies to the sum of the number of AliroEvictableEndpointKey credentials and the number of
              * AliroNonEvictableEndpointKey credentials.
              *
-             * NOTE
+             * > [!NOTE]
              *
-             * The credential indices used for these two credential types are independent of each other, similar to all
-             * other credential types. As long as NumberOfAliroEndpointKeysSupported is at least 2 a client could add a
-             * credential of type AliroEvictableEndpointKey at any index from 1 to NumberOfAliroEndpointKeysSupported
-             * and also add a credential of type AliroNonEvictableEndpointKey at the same index, and both credentials
-             * would exist on the server.
+             * > The credential indices used for these two credential types are independent of each other, similar to
+             *   all other credential types. As long as NumberOfAliroEndpointKeysSupported is at least 2 a client could
+             *   add a credential of type AliroEvictableEndpointKey at any index from 1 to
+             *   NumberOfAliroEndpointKeysSupported and also add a credential of type AliroNonEvictableEndpointKey at
+             *   the same index, and both credentials would exist on the server.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.9.46
              */
@@ -3837,11 +3831,11 @@ export namespace DoorLock {
              * This command allows clearing an existing Aliro Reader configuration for the lock. Administrators shall
              * NOT clear an Aliro Reader configuration without explicit user permission.
              *
-             * NOTE
+             * > [!NOTE]
              *
-             * Using this command will revoke the ability of all existing Aliro user devices that have the old
-             * verification key to interact with the lock. This effect is not restricted to a single fabric or otherwise
-             * scoped in any way.
+             * > Using this command will revoke the ability of all existing Aliro user devices that have the old
+             *   verification key to interact with the lock. This effect is not restricted to a single fabric or
+             *   otherwise scoped in any way.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.10.43
              */
@@ -4046,10 +4040,10 @@ export namespace DoorLock {
              * an optional code for the lock. The door lock may require a code depending on the value of the
              * RequirePINForRemoteOperation attribute.
              *
-             * NOTE
+             * > [!NOTE]
              *
-             * If the attribute AutoRelockTime is supported, the lock will transition to the locked state when the auto
-             * relock time has expired.
+             * > If the attribute AutoRelockTime is supported, the lock will transition to the locked state when the
+             *   auto relock time has expired.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.10.41
              */
@@ -4157,7 +4151,6 @@ export namespace DoorLock {
              * CredentialOverTheAirAccess
              *
              * If this feature is supported then the lock supports the ability to verify a credential provided in a
-             *
              * lock/unlock command. Currently the cluster only supports providing the PIN credential to the lock/unlock
              * commands. If this feature is supported then the PIN Credential feature shall also be supported.
              *
@@ -4310,7 +4303,7 @@ export namespace DoorLock {
             ),
 
             /**
-             * Indicates the current operating mode of the lock as defined in OperatingModeEnum.
+             * This attribute shall indicate the current operating mode of the lock as defined in OperatingModeEnum.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.9.24
              */
@@ -4337,10 +4330,8 @@ export namespace DoorLock {
 
             /**
              * Indicates the default configurations as they are physically set on the device (example: hardware dip
-             * switch setting, etc…) and represents the default setting for some of the
-             *
-             * attributes within this cluster (for example: LED, Auto Lock, Sound Volume, and Operating Mode
-             * attributes).
+             * switch setting, etc…) and represents the default setting for some of the attributes within this cluster
+             * (for example: LED, Auto Lock, Sound Volume, and Operating Mode attributes).
              *
              * This is a read-only attribute and is intended to allow clients to determine what changes may need to be
              * made without having to query all the included attributes. It may be beneficial for the clients to know
@@ -4461,10 +4452,10 @@ export namespace DoorLock {
              * lock. The door lock may require a code depending on the value of the RequirePINForRemoteOperation
              * attribute.
              *
-             * NOTE
+             * > [!NOTE]
              *
-             * If the attribute AutoRelockTime is supported the lock will transition to the locked state when the auto
-             * relock time has expired.
+             * > If the attribute AutoRelockTime is supported the lock will transition to the locked state when the auto
+             *   relock time has expired.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.10.2
              */
@@ -4515,9 +4506,8 @@ export namespace DoorLock {
              *     ◦ shall generate a LockOperation event of LockOperationType Unlatch when it is actuated from the
              *       outside.
              *
-             *     ◦ may generate a LockOperation event of LockOperationType Unlatch when it is actuated
-             *
-             * from the inside.
+             *     ◦ may generate a LockOperation event of LockOperationType Unlatch when it is actuated from the
+             *       inside.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 5.2.11.3
              */
@@ -4588,8 +4578,6 @@ export namespace DoorLock {
      * the locking functionality is abstracted from the cluster. The cluster has a small list of mandatory attributes
      * and functions and a list of optional features.
      *
-     * Figure 16. Typical Usage of the Door Lock Cluster
-     *
      * DoorLockCluster supports optional features that you can enable with the DoorLockCluster.with() factory method.
      *
      * @see {@link MatterSpecification.v14.Cluster} § 5.2

package/src/clusters/ecosystem-information.ts

@@ -83,12 +83,12 @@ export namespace EcosystemInformation {
         /**
          * This field shall indicate the timestamp of when the UniqueLocationIDs was last modified.
          *
-         * NOTE
+         * > [!NOTE]
          *
-         * If multiple server instances update the UniqueLocationIDs field at the same time, it is possible one of the
-         * updates will be missed. This is considered an acceptable limitation to reduce the complexity of the design.
-         * Since this is meant to be provided from user input, it is unlikely these signals would be happening at one
-         * time.
+         * > If multiple server instances update the UniqueLocationIDs field at the same time, it is possible one of the
+         *   updates will be missed. This is considered an acceptable limitation to reduce the complexity of the design.
+         *   Since this is meant to be provided from user input, it is unlikely these signals would be happening at one
+         *   time.
          *
          * @see {@link MatterSpecification.v14.Core} § 9.18.4.1.7
          */
@@ -121,11 +121,9 @@ export namespace EcosystemInformation {
          * location as a result of an external interaction. (For example, the user changes the location assignment.)
          *
          * UniqueLocationID shall NOT be changed when the LocationDescriptor changes name, but still represents the same
-         * location. (For example, the user renames a room.)
-         *
-         * UniqueLocationID shall be changed when LocationDescriptor changes as a result of another Ecosystem
-         * Information Cluster server instance changing and the UniqueLocationID on the remote server instance also
-         * changes.
+         * location. (For example, the user renames a room.) UniqueLocationID shall be changed when LocationDescriptor
+         * changes as a result of another Ecosystem Information Cluster server instance changing and the
+         * UniqueLocationID on the remote server instance also changes.
          *
          * UniqueLocationID shall NOT be changed when LocationDescriptor changes as a result of another Ecosystem
          * Information Cluster server instance changing and the UniqueLocationID on the remote server instance does not
@@ -173,9 +171,7 @@ export namespace EcosystemInformation {
             /**
              * This attribute shall contain the list of logical devices represented by a Bridged Node. Most of the time
              * this will contain a single entry, but may grow with more complex device compositions (e.g. another
-             * bridge.)
-             *
-             * An empty list indicates that the information is not available.
+             * bridge.) An empty list indicates that the information is not available.
              *
              * @see {@link MatterSpecification.v14.Core} § 9.18.5.1
              */
@@ -189,9 +185,8 @@ export namespace EcosystemInformation {
              * This attribute shall contain the list of rooms, areas and groups associated with the DeviceDirectory
              * entries, and shall NOT contain locations which are dynamically generated and removed by an ecosystem.
              * (E.g. a location that is generated and removed based on the user being home is not permitted. However, an
-             * initially generated location name that does not quickly change is acceptable.)
-             *
-             * An empty list indicates that the information is not available.
+             * initially generated location name that does not quickly change is acceptable.) An empty list indicates
+             * that the information is not available.
              *
              * LocationDirectory entries shall be removed if there is no DeviceDirectory that references it.
              *

package/src/clusters/electrical-energy-measurement.ts

@@ -127,10 +127,10 @@ export namespace ElectricalEnergyMeasurement {
          * This field shall indicate the time elapsed since boot at the beginning of the period during which the value
          * of the Energy field was measured.
          *
-         * If this EnergyMeasurementStruct represents cumulative energy, this field shall be omitted. Otherwise, if the
-         * server had not yet determined the time in UTC at the start of the measurement
+         * If this EnergyMeasurementStruct represents cumulative energy, this field shall be omitted.
          *
-         * period, or does not have the capability of determining the time in UTC, this field shall be indicated.
+         * Otherwise, if the server had not yet determined the time in UTC at the start of the measurement period, or
+         * does not have the capability of determining the time in UTC, this field shall be indicated.
          *
          * Otherwise, if the server had determined the time in UTC at or before the beginning of the measurement period,
          * this field may be omitted; if it is indicated, its value shall be the time elapsed since boot at the UTC time

package/src/clusters/electrical-power-measurement.ts

@@ -91,9 +91,8 @@ export namespace ElectricalPowerMeasurement {
          * milliamps (mA). A positive value indicates that the measured harmonic current is positive, and a negative
          * value indicates that the measured harmonic current is negative.
          *
-         * For the Harmonic Phases attribute, this value is the most recent phase of the given harmonic order
-         *
-         * in millidegrees (mDeg). A positive value indicates that the measured phase is leading, and a negative value
+         * For the Harmonic Phases attribute, this value is the most recent phase of the given harmonic order in
+         * millidegrees (mDeg). A positive value indicates that the measured phase is leading, and a negative value
          * indicates that the measured phase is lagging.
          *
          * If this measurement is not currently available, a value of null shall be returned.
@@ -497,9 +496,8 @@ export namespace ElectricalPowerMeasurement {
         attributes: {
             /**
              * This shall indicate a list of HarmonicMeasurementStruct values, with each HarmonicMeasurementStruct
-             * representing the most recent phase of the harmonic current reading for the harmonic
-             *
-             * order specified by Order.
+             * representing the most recent phase of the harmonic current reading for the harmonic order specified by
+             * Order.
              *
              * The reporting interval of this attribute shall be manufacturer dependent. The server may choose to omit
              * publication of deltas considered not meaningful.
@@ -527,8 +525,9 @@ export namespace ElectricalPowerMeasurement {
              *
              * If the neutral current cannot be measured or derived, a value of null shall be returned.
              *
-             * A positive value represents an imbalance between the phase currents when power is imported. A negative
-             * value represents an imbalance between the phase currents when power is exported.
+             * A positive value represents an imbalance between the phase currents when power is imported.
+             *
+             * A negative value represents an imbalance between the phase currents when power is exported.
              *
              * The reporting interval of this attribute shall be manufacturer dependent. The server may choose to omit
              * publication of deltas considered not meaningful.

package/src/clusters/energy-evse-mode.ts

@@ -104,7 +104,6 @@ export namespace EnergyEvseMode {
 
         /**
          * While in modes with this tag, and once enabled with the EnableCharging, the EVSE will attempt to
-         *
          * automatically start charging based on available excess solar PV generation, limiting the charging power to
          * avoid importing energy from the grid.
          *
@@ -117,10 +116,11 @@ export namespace EnergyEvseMode {
          * discharging based on the current charge state of the EV, and its control from an associated Device Energy
          * Management cluster.
          *
-         * NOTE
+         * > [!NOTE]
          *
-         * being in a mode with this tag set or not does not affect the handling of the EnableDischarging command by the
-         * Energy EVSE cluster, but once enabled, only modes with this tag enable the discharging to actually occur.
+         * > being in a mode with this tag set or not does not affect the handling of the EnableDischarging command by
+         *   the Energy EVSE cluster, but once enabled, only modes with this tag enable the discharging to actually
+         *   occur.
          *
          * @see {@link MatterSpecification.v14.Cluster} § 9.4.7.1.4
          */
@@ -196,9 +196,8 @@ export namespace EnergyEvseMode {
          * specification of the derived cluster defines a namespace, the set of standard mode tags also includes the
          * mode tag values from that namespace.
          *
-         * Mode tags can help clients look for options that meet certain criteria, render the user interface, use
-         *
-         * the mode in an automation, or to craft help text their voice-driven interfaces. A mode tag shall be either a
+         * Mode tags can help clients look for options that meet certain criteria, render the user interface, use the
+         * mode in an automation, or to craft help text their voice-driven interfaces. A mode tag shall be either a
          * standard tag or a manufacturer specific tag, as defined in each ModeTagStruct list entry.
          *
          * A mode option may have more than one mode tag. A mode option may be associated with a mixture of standard and
@@ -256,10 +255,9 @@ export namespace EnergyEvseMode {
              * At least one entry in the SupportedModes attribute shall include the Manual mode tag in the ModeTags
              * field list.
              *
-             * Modes with entries in the SupportedModes attribute which contain multiple mode tags permitting
-             *
-             * charging or discharging under different conditions shall permit the charging or discharging to occur if
-             * any of the conditions are satisfied.
+             * Modes with entries in the SupportedModes attribute which contain multiple mode tags permitting charging
+             * or discharging under different conditions shall permit the charging or discharging to occur if any of the
+             * conditions are satisfied.
              *
              * Modes shall NOT have both the Manual tag and the TimeOfUse or SolarCharging tags defined in the
              * SupportedModes attribute.

package/src/clusters/energy-evse.ts

@@ -271,9 +271,8 @@ export namespace EnergyEvse {
          *   • the AddedEnergy field shall take precedence over the TargetSoC field, and if the EVSE does not support
          *     the SOC feature then the TargetSoC field may only take the values null or 100%.
          *
-         *   • if the AddedEnergy field has not been provided, the EVSE SHOULD assume the vehicle is empty
-         *
-         * and charge until the vehicle stops demanding a charge.
+         *   • if the AddedEnergy field has not been provided, the EVSE SHOULD assume the vehicle is empty and charge
+         *     until the vehicle stops demanding a charge.
          *
          * @see {@link MatterSpecification.v14.Cluster} § 9.3.7.6.2
          */
@@ -293,11 +292,11 @@ export namespace EnergyEvse {
          * battery size of the vehicles on the market (e.g. 70000Wh), however this is up to the client to carefully
          * choose a value.
          *
-         * NOTE
+         * > [!NOTE]
          *
-         * If the EVSE can obtain the Battery Capacity of the vehicle, it SHOULD NOT limit this AddedEnergy value to the
-         * Battery Capacity of the vehicle, since the EV may also require energy for heating and cooling of the battery
-         * during charging, or for heating or cooling the cabin.
+         * > If the EVSE can obtain the Battery Capacity of the vehicle, it SHOULD NOT limit this AddedEnergy value to
+         *   the Battery Capacity of the vehicle, since the EV may also require energy for heating and cooling of the
+         *   battery during charging, or for heating or cooling the cabin.
          *
          * @see {@link MatterSpecification.v14.Cluster} § 9.3.7.6.3
          */
@@ -447,7 +446,7 @@ export namespace EnergyEvse {
         PluggedInDischarging = 4,
 
         /**
-         * The EVSE is transitioning from any plugged- in state to NotPluggedIn
+         * The EVSE is transitioning from any plugged-in state to NotPluggedIn
          */
         SessionEnding = 5,
 
@@ -483,7 +482,7 @@ export namespace EnergyEvse {
         DisabledError = 3,
 
         /**
-         * The EV is not currently allowed to charge or discharge due to self- diagnostics mode.
+         * The EV is not currently allowed to charge or discharge due to self-diagnostics mode.
          */
         DisabledDiagnostics = 4,
 
@@ -972,8 +971,7 @@ export namespace EnergyEvse {
             /**
              * Indicates the target SoC the EVSE is going to attempt to reach when the vehicle is next charged.
              *
-             * A null value indicates that there is no scheduled charging
-             *
+             * A null value indicates that there is no scheduled charging (for example, the EVSE Mode is set to use
              * Manual mode tag), or that the vehicle is not plugged in with the SupplyState indicating that charging is
              * enabled, or that the next ChargingTargetStruct is using the AddedEnergy value to charge the vehicle.
              *
@@ -1003,7 +1001,7 @@ export namespace EnergyEvse {
              *
              * ApproxEVEfficiency (km/kWh x 1000): 4800 (i.e. 4.8km/kWh x 1000)
              *
-             * AddedEnergy (Wh): 10,000
+             * ### AddedEnergy (Wh): 10,000
              *
              * AddedRange (km) = 10,000 x 4800 / 1,000,000 = 48 km
              *
@@ -1210,14 +1208,13 @@ export namespace EnergyEvse {
              * The State attribute shall change when the EVSE detects change of condition of the EV (plugged in or
              * unplugged, whether the vehicle is asking for demand or not, and if it is charging or discharging).
              *
-             * NOTE
-             *
-             * SessionEnding is not really a state but a transition. However, the transition period may take a few
-             * seconds and is useful for some clean up purposes.
+             * > [!NOTE]
              *
-             * The Fault state is used to indicate that the FaultState attribute is not NoError.
+             * > SessionEnding is not really a state but a transition. However, the transition period may take a few
+             *   seconds and is useful for some clean up purposes.
              *
-             * A null value shall indicate that the state cannot be determined.
+             * The Fault state is used to indicate that the FaultState attribute is not NoError. A null value shall
+             * indicate that the state cannot be determined.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 9.3.8.1
              */
@@ -1266,9 +1263,8 @@ export namespace EnergyEvse {
             circuitCapacity: Attribute(0x5, TlvInt64.bound({ min: 0 }), { persistent: true, default: 0 }),
 
             /**
-             * Indicates the minimum current that can be delivered by the EVSE to the EV.
-             *
-             * The attribute can be set using the EnableCharging command.
+             * Indicates the minimum current that can be delivered by the EVSE to the EV. The attribute can be set using
+             * the EnableCharging command.
              *
              * @see {@link MatterSpecification.v14.Cluster} § 9.3.8.7
              */
@@ -1306,10 +1302,8 @@ export namespace EnergyEvse {
              *
              * This attribute value shall be limited by the EVSE to be in the range of:
              *
-             * MinimumChargeCurrent <= UserMaximumChargeCurrent <= MaximumChargeCurrent
-             *
-             * where MinimumChargeCurrent and MaximumChargeCurrent are the values received in the EnableCharging
-             * command.
+             * MinimumChargeCurrent <= UserMaximumChargeCurrent <= MaximumChargeCurrent where MinimumChargeCurrent and
+             * MaximumChargeCurrent are the values received in the EnableCharging command.
              *
              * Its default value SHOULD be initialized to the same as the CircuitCapacity attribute. This value shall be
              * persisted across reboots to ensure it does not cause charging issues during temporary power failures.
@@ -1465,9 +1459,8 @@ export namespace EnergyEvse {
      * IEC61841 define Pilot signal as a modulated DC voltage on a single wire.
      *
      * Power Line Communication (PLC) is supported by some EVSEs (e.g. for support of ISO 15118 in Europe and SAE
-     * J2931/4 in NA) and may enable features such as Vehicle to Grid (V2G) or Vehicle to
-     *
-     * Home (V2H) that allows for bi-directional charging/discharging of electric vehicles.
+     * J2931/4 in NA) and may enable features such as Vehicle to Grid (V2G) or Vehicle to Home (V2H) that allows for
+     * bi-directional charging/discharging of electric vehicles.
      *
      * More modern EVSE devices may optionally support ISO 15118-20 in Europe and SAE J2836/3 for NA to support
      * bi-directional charging (Vehicle to Grid - V2G) and Plug and Charge capabilities.
@@ -1476,15 +1469,15 @@ export namespace EnergyEvse {
      * cluster.
      *
      * This cluster supports a safety mechanism that may lockout remote operation until the initial latching conditions
-     * have been met. Some of the fault conditions defined in SAE J1772, such as Ground- Fault Circuit Interrupter
-     * (GFCI) or Charging Circuit Interrupting Device (CCID), may require clearing by an operator by, for example,
-     * pressing a button on the equipment or breaker panel.
+     * have been met. Some of the fault conditions defined in SAE J1772, such as Ground-Fault Circuit Interrupter (GFCI)
+     * or Charging Circuit Interrupting Device (CCID), may require clearing by an operator by, for example, pressing a
+     * button on the equipment or breaker panel.
      *
      * This EVSE cluster is written around support of a single EVSE. Having multiple EVSEs at home or a business is
      * managed by backend system and outside scope of this cluster.
      *
      * Note that in many deployments the EVSE may be outside the home and may suffer from intermittent network
-     * connections (e.g. a weak WiFi signal). It also allows for a charging profile to be pre- configured, in case there
+     * connections (e.g. a weak WiFi signal). It also allows for a charging profile to be pre-configured, in case there
      * is a temporary communications loss during a charging session.
      *
      * EnergyEvseCluster supports optional features that you can enable with the EnergyEvseCluster.with() factory

package/src/clusters/energy-preference.ts

@@ -182,7 +182,9 @@ export namespace EnergyPreference {
         attributes: {
             /**
              * Indicates a list of BalanceStructs, each representing a condition or set of conditions for the device to
-             * enter a low power mode. This shall contain at least two BalanceStructs.
+             * enter a low power mode.
+             *
+             * This shall contain at least two BalanceStructs.
              *
              * Each BalanceStruct shall have a Step field larger than the Step field on the previous BalanceStruct in
              * the list.
@@ -259,8 +261,6 @@ export namespace EnergyPreference {
     /**
      * This cluster provides an interface to specify preferences for how devices should consume energy.
      *
-     * NOTE Support for Energy Preference cluster is provisional.
-     *
      * Per the Matter specification you cannot use {@link EnergyPreferenceCluster} without enabling certain feature
      * combinations. You must use the {@link with} factory method to obtain a working cluster.
      *

package/src/clusters/fixed-label.ts

@@ -42,12 +42,10 @@ export namespace FixedLabel {
      *   • A manufacturer can use this to identify a characteristic of an endpoint. For example to identify the
      *     endpoints of a luminaire, one pointing up, the other pointing down, one of the endpoints would have a
      *     LabelList entry "orientation":"up" while the other would have "orientation":"down". Using such indication,
-     *     the user interface of a Node controlling this luminaire
+     *     the user interface of a Node controlling this luminaire knows which of the endpoints is which of the lights.
      *
-     * knows which of the endpoints is which of the lights.
-     *
-     * Note that the TagList in the Descriptor cluster provides an alternative mechanism for such self- description
-     * using standardized tags rather than manufacturer-selected strings, yielding a standardized mechanism for features
+     * Note that the TagList in the Descriptor cluster provides an alternative mechanism for such self-description using
+     * standardized tags rather than manufacturer-selected strings, yielding a standardized mechanism for features
      * defined in the various namespaces. The second example above can be implemented using semantic tags
      * Direction.Upward and Direction.Downward instead of (or in addition to) the Fixed Label cluster.
      *

package/src/clusters/flow-measurement.ts

@@ -45,9 +45,7 @@ export namespace FlowMeasurement {
             minMeasuredValue: Attribute(0x1, TlvNullable(TlvUInt16.bound({ max: 65533 }))),
 
             /**
-             * Indicates the maximum value of MeasuredValue that can be measured. See
-             *
-             * Measured Value for more details.
+             * Indicates the maximum value of MeasuredValue that can be measured. See Measured Value for more details.
              *
              * The null value indicates that the value is not available.
              *