ReadonlyclusterMatter cluster names for type safety and autocomplete Use these constants with updateAccessoryState() and getAccessoryState()
ReadonlyclustersMatter clusters - Direct access to Matter.js cluster definitions For advanced use cases requiring low-level cluster access
Definitions for the AirQuality cluster.
This cluster provides an interface to air quality classification using distinct levels with human-readable labels.
Definitions for the BooleanState cluster.
This cluster provides an interface to a boolean state.
Definitions for the CarbonMonoxideConcentrationMeasurement cluster.
Definitions for the ClosureControl cluster.
This cluster provides an interface for controlling a Closure.
Definitions for the ColorControl cluster.
This cluster provides an interface for changing the color of a light. Color is specified according to the CIE 1931 Color space. Color control is carried out in terms of x,y values, as defined by this specification.
Additionally, color may optionally be controlled in terms of color temperature, or as hue and saturation values based on optionally variable RGB and W color points. It is recommended that the hue and saturation are interpreted according to the HSV (a.k.a. HSB) color model.
Control over luminance is not included, as this is provided by means of the Level Control for Lighting cluster. It is recommended that the level provided by this cluster be interpreted as representing a proportion of the maximum intensity achievable at the current color.
Definitions for the DeviceEnergyManagement cluster.
This cluster allows a client to manage the power draw of a device. An example of such a client could be an Energy Management System (EMS) which controls an Energy Smart Appliance (ESA).
In most deployments the EMS will be the client, and the ESA will host the Device Energy Management Cluster server.
This cluster is intended to be generic in nature and could apply to any electrical load or generator (e.g. a Battery Electric Storage System - BESS, solar PV inverter, EVSE, HVAC, heat pump, hot water heater, white goods appliances etc).
It consists of the following areas which shall be supported by all devices implementing this cluster:
Description of ESA and its capabilities & power limits (sometimes referred to as a nameplate)
Current state of operation (including user opt-out, safety limitations / alarms)
There are some optional capabilities that some ESAs may be able to offer:
Ability to control the load or generation
Forecast data, including when it can be flexible (i.e. modify the power or time period)
The ability to have their power profile adjusted by an EMS, and to provide an updated Forecast back to the EMS.
This allows the EMS to manage multiple home loads and where ESAs can be flexible, continuously optimizing the home energy to minimize cost, reduce CO2 impact, maximize self-consumption of solar PV and provide Demand Side Response (DSR) Grid services.
It is likely that the ESA may also use the Pricing Cluster to obtain incentive signals such as 'grid carbon intensity', 'time of use' or 'type of use' tariffs to schedule its operation to run at the cheapest and greenest times.
NOTE: Grid Services are market dependent and will use other protocols ([OpenADR] / [IEEE2030.5]) to communicate grid events to the EMS. These are outside the scope of Matter.
NOTE: Different markets may follow different approaches, but the UK [PAS1878] and [EUCodeOfConduct] give examples of how ESAs may be mandated to support these features in the future.
Definitions for the DoorLock cluster.
The door lock cluster provides an interface to a generic way to secure a door. The physical object that provides 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.
Definitions for the ElectricalEnergyMeasurement cluster.
This cluster provides a mechanism for querying data about the electrical energy imported or provided by the server.
Definitions for the ElectricalPowerMeasurement cluster.
This cluster provides a mechanism for querying data about electrical power as measured by the server.
Definitions for the EnergyEvse cluster.
Electric Vehicle Supply Equipment (EVSE) is equipment used to charge an Electric Vehicle (EV) or Plug-In Hybrid Electric Vehicle. This cluster provides an interface to the functionality of Electric Vehicle Supply Equipment (EVSE) management.
Devices targeted by this cluster include Electric Vehicle Supply Equipment (EVSE). The cluster generically assumes a signaling protocol (J1772 in NA and IEC61851 in Europe and Asia) between the EVSE and Electric Vehicle (EV) that utilizes a pilot signal to manage the states of the charging process. [SAE J2847/3_202311] version and 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.
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.
This cluster definition assumes AC charging only. DC charging options may be added in future revisions of this 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.
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 Wi-Fi signal). It also allows for a charging profile to be pre-configured, in case there is a temporary communications loss during a charging session.
Definitions for the FanControl cluster.
This cluster specifies an interface to control the speed of a fan.
Definitions for the KeypadInput cluster.
This cluster provides an interface for key code based input and control on a device like a Video Player or an endpoint like a Content App. This may include text or action commands such as UP, DOWN, and SELECT.
This cluster would be supported on Video Player devices as well as devices that support remote control input from a keypad or remote. This cluster provides the list of supported keypad inputs and provides a command for sending them.
The cluster server for Keypad Input is implemented by a device that can receive keypad input, such as a Video Player, or an endpoint that can receive keypad input, such as a Content App.
The key codes used are those defined in the HDMI CEC specification (see HDMI).
Devices may understand a subset of these key codes. Feature flags are used to indicate a specific subset that is supported. Device may support additional codes beyond what is indicated in feature flags.
Definitions for the LevelControl cluster.
This cluster provides an interface for controlling a characteristic of a device that can be set to a level, for example the brightness of a light or lamp, a pump's flow rate setpoint, etc.
Definitions for the MediaPlayback cluster.
This cluster provides an interface for controlling Media Playback (PLAY, PAUSE, etc) on a media device such as a TV, Set-top Box, or Smart Speaker.
This cluster server would be supported on Video Player devices or endpoints that provide media playback, such as a Content App. This cluster provides an interface for controlling Media Playback.
Definitions for the NitrogenDioxideConcentrationMeasurement cluster.
Definitions for the OnOff cluster.
Attributes and commands for turning devices on and off.
Definitions for the OzoneConcentrationMeasurement cluster.
Definitions for the Pm10ConcentrationMeasurement cluster.
Definitions for the Pm25ConcentrationMeasurement cluster.
Definitions for the PowerTopology cluster.
The Power Topology Cluster provides a mechanism for expressing how power is flowing between endpoints.
Definitions for the RvcOperationalState cluster.
This cluster is derived from the Operational State cluster and provides an interface for monitoring the operational state of a robotic vacuum cleaner.
Definitions for the Thermostat cluster.
This cluster provides an interface to the functionality of a thermostat.
Definitions for the ValveConfigurationAndControl cluster.
This cluster is used to configure a valve.
Definitions for the WindowCovering cluster.
The window covering cluster provides an interface for controlling and adjusting automatic window coverings such as drapery motors, automatic shades, curtains and blinds.
ReadonlydeviceThe matter.js requirements behind the feature-gated device types, keyed to match deviceTypes.
Homebridge picks a feature set from the state an accessory declares, which suits almost every device. Use these when it cannot: a thermostat that declares both a heating and a cooling setpoint is given AutoMode too, so a device that heats and cools but has no auto mode has to compose the cluster itself. Homebridge leaves an already-composed cluster alone.
ReadonlydeviceMatter device types for creating accessories.
Maps friendly names to Matter.js device types, including stateless controller types like GenericSwitch.
Get a Matter accessory's current cluster state
Returns the current attribute values that are exposed to Matter controllers. Useful for:
Similar to HAP's characteristic.value getter.
Typed overload for known clusters - returns typed state
OptionalpartId: stringFallback for unknown/custom clusters
OptionalpartId: stringOptional: ID of the part to get state from (for composed devices with multiple endpoints)
const state = await api.matter?.getAccessoryState(uuid, api.matter?.clusterNames.OnOff)
if (state?.onOff) {
console.log('Light is currently on')
}
Get state of a specific outlet in a power strip:
const outletState = await api.matter?.getAccessoryState(
uuid,
api.matter?.clusterNames.OnOff,
'outlet-3' // Part ID
)
Register Matter platform accessories
Returns a promise that resolves when all accessories are fully registered and ready for state updates. This is especially important for external accessories (like robot vacuums) which require additional setup time.
Unlike HAP, register every accessory on every start, including the ones handed to
configureMatterAccessory() from the cache. Handlers are functions and cannot be cached,
so a restored accessory answers every command with a failure until it is registered again.
When an accessory is restored from the cache, its cached state is kept: the clusters
values passed here are the starting state for a new accessory only. To set the current
state of a restored accessory, call updateAccessoryState() once this promise resolves (#4015).
The plugin identifier (e.g., 'homebridge-example')
The platform name (e.g., 'ExamplePlatform')
Array of Matter accessories to register
ReadonlystatusMatter protocol status errors for handlers.
Throw one of these from a handler to send a specific Matter status code to
the controller instead of failing the endpoint. Prefer this over importing
MatterStatus from the homebridge package: a value import resolves the
package when the plugin file is loaded, which fails on installs that keep
Homebridge in a separate node_modules tree, taking the whole plugin down
with it. The api object a plugin already holds has no such problem.
ReadonlyswitchHelpers for GenericSwitch accessories (stateless remotes and buttons).
Device-type-specific helpers live under nested namespaces (e.g. api.matter?.switch)
to keep the top-level MatterAPI surface focused on the generic, UUID-addressed primitives.
ReadonlytypesMatter types - Access to Matter.js cluster type definitions and enums Use these for type-safe attribute values (modes, states, etc.)
Definitions for the AirQuality cluster.
This cluster provides an interface to air quality classification using distinct levels with human-readable labels.
Definitions for the BooleanState cluster.
This cluster provides an interface to a boolean state.
Definitions for the CarbonMonoxideConcentrationMeasurement cluster.
Definitions for the ClosureControl cluster.
This cluster provides an interface for controlling a Closure.
Definitions for the ColorControl cluster.
This cluster provides an interface for changing the color of a light. Color is specified according to the CIE 1931 Color space. Color control is carried out in terms of x,y values, as defined by this specification.
Additionally, color may optionally be controlled in terms of color temperature, or as hue and saturation values based on optionally variable RGB and W color points. It is recommended that the hue and saturation are interpreted according to the HSV (a.k.a. HSB) color model.
Control over luminance is not included, as this is provided by means of the Level Control for Lighting cluster. It is recommended that the level provided by this cluster be interpreted as representing a proportion of the maximum intensity achievable at the current color.
Definitions for the DeviceEnergyManagement cluster.
This cluster allows a client to manage the power draw of a device. An example of such a client could be an Energy Management System (EMS) which controls an Energy Smart Appliance (ESA).
In most deployments the EMS will be the client, and the ESA will host the Device Energy Management Cluster server.
This cluster is intended to be generic in nature and could apply to any electrical load or generator (e.g. a Battery Electric Storage System - BESS, solar PV inverter, EVSE, HVAC, heat pump, hot water heater, white goods appliances etc).
It consists of the following areas which shall be supported by all devices implementing this cluster:
Description of ESA and its capabilities & power limits (sometimes referred to as a nameplate)
Current state of operation (including user opt-out, safety limitations / alarms)
There are some optional capabilities that some ESAs may be able to offer:
Ability to control the load or generation
Forecast data, including when it can be flexible (i.e. modify the power or time period)
The ability to have their power profile adjusted by an EMS, and to provide an updated Forecast back to the EMS.
This allows the EMS to manage multiple home loads and where ESAs can be flexible, continuously optimizing the home energy to minimize cost, reduce CO2 impact, maximize self-consumption of solar PV and provide Demand Side Response (DSR) Grid services.
It is likely that the ESA may also use the Pricing Cluster to obtain incentive signals such as 'grid carbon intensity', 'time of use' or 'type of use' tariffs to schedule its operation to run at the cheapest and greenest times.
NOTE: Grid Services are market dependent and will use other protocols ([OpenADR] / [IEEE2030.5]) to communicate grid events to the EMS. These are outside the scope of Matter.
NOTE: Different markets may follow different approaches, but the UK [PAS1878] and [EUCodeOfConduct] give examples of how ESAs may be mandated to support these features in the future.
Definitions for the DoorLock cluster.
The door lock cluster provides an interface to a generic way to secure a door. The physical object that provides 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.
Definitions for the ElectricalEnergyMeasurement cluster.
This cluster provides a mechanism for querying data about the electrical energy imported or provided by the server.
Definitions for the ElectricalPowerMeasurement cluster.
This cluster provides a mechanism for querying data about electrical power as measured by the server.
Definitions for the EnergyEvse cluster.
Electric Vehicle Supply Equipment (EVSE) is equipment used to charge an Electric Vehicle (EV) or Plug-In Hybrid Electric Vehicle. This cluster provides an interface to the functionality of Electric Vehicle Supply Equipment (EVSE) management.
Devices targeted by this cluster include Electric Vehicle Supply Equipment (EVSE). The cluster generically assumes a signaling protocol (J1772 in NA and IEC61851 in Europe and Asia) between the EVSE and Electric Vehicle (EV) that utilizes a pilot signal to manage the states of the charging process. [SAE J2847/3_202311] version and 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.
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.
This cluster definition assumes AC charging only. DC charging options may be added in future revisions of this 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.
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 Wi-Fi signal). It also allows for a charging profile to be pre-configured, in case there is a temporary communications loss during a charging session.
Definitions for the FanControl cluster.
This cluster specifies an interface to control the speed of a fan.
Definitions for the KeypadInput cluster.
This cluster provides an interface for key code based input and control on a device like a Video Player or an endpoint like a Content App. This may include text or action commands such as UP, DOWN, and SELECT.
This cluster would be supported on Video Player devices as well as devices that support remote control input from a keypad or remote. This cluster provides the list of supported keypad inputs and provides a command for sending them.
The cluster server for Keypad Input is implemented by a device that can receive keypad input, such as a Video Player, or an endpoint that can receive keypad input, such as a Content App.
The key codes used are those defined in the HDMI CEC specification (see HDMI).
Devices may understand a subset of these key codes. Feature flags are used to indicate a specific subset that is supported. Device may support additional codes beyond what is indicated in feature flags.
Definitions for the LevelControl cluster.
This cluster provides an interface for controlling a characteristic of a device that can be set to a level, for example the brightness of a light or lamp, a pump's flow rate setpoint, etc.
Definitions for the MediaPlayback cluster.
This cluster provides an interface for controlling Media Playback (PLAY, PAUSE, etc) on a media device such as a TV, Set-top Box, or Smart Speaker.
This cluster server would be supported on Video Player devices or endpoints that provide media playback, such as a Content App. This cluster provides an interface for controlling Media Playback.
Definitions for the NitrogenDioxideConcentrationMeasurement cluster.
Definitions for the OnOff cluster.
Attributes and commands for turning devices on and off.
Definitions for the OzoneConcentrationMeasurement cluster.
Definitions for the Pm10ConcentrationMeasurement cluster.
Definitions for the Pm25ConcentrationMeasurement cluster.
Definitions for the PowerTopology cluster.
The Power Topology Cluster provides a mechanism for expressing how power is flowing between endpoints.
Definitions for the RvcOperationalState cluster.
This cluster is derived from the Operational State cluster and provides an interface for monitoring the operational state of a robotic vacuum cleaner.
Definitions for the Thermostat cluster.
This cluster provides an interface to the functionality of a thermostat.
Definitions for the ValveConfigurationAndControl cluster.
This cluster is used to configure a valve.
Definitions for the WindowCovering cluster.
The window covering cluster provides an interface for controlling and adjusting automatic window coverings such as drapery motors, automatic shades, curtains and blinds.
Unregister Matter platform accessories by UUID
The plugin identifier
The platform name
Array of Matter accessories to unregister (only uuid is required)
Update a Matter accessory's cluster state when device changes externally
Use this for state updates from:
DO NOT use inside handlers - state auto-updates after handlers complete! Similar to HAP's characteristic.updateValue()
Typed overload for known clusters - provides autocomplete for attribute names
OptionalpartId: stringFallback for unknown/custom clusters
OptionalpartId: stringDevice turned on via native app:
await api.matter?.updateAccessoryState(
uuid,
api.matter?.clusterNames.OnOff,
{ onOff: true }
)
Device brightness changed via physical button:
await api.matter?.updateAccessoryState(
uuid,
api.matter?.clusterNames.LevelControl,
{ currentLevel: 200 }
)
Update a specific outlet in a power strip (composed device):
await api.matter?.updateAccessoryState(
uuid,
api.matter?.clusterNames.OnOff,
{ onOff: true },
'outlet-2' // Part ID
)
Update Matter platform accessories in the cache
Use this to update cached accessory information (displayName, manufacturer, model, etc.) without unregistering and re-registering. This is useful when:
Similar to api.updatePlatformAccessories() for HAP accessories.
Array of Matter accessories to update (must include uuid)
ReadonlyuuidUUID generator (alias of api.hap.uuid for convenience) Use this to generate unique identifiers for Matter accessories
Matter API Interface.
Provides access to Matter protocol functionality for creating Matter-compatible accessories. Similar to
api.hapfor HomeKit Accessory Protocol.api.matterisMatterAPI | undefined— it's defined on bridges where Matter is configured (matchesapi.isMatterEnabled()), undefined otherwise. Plugins must use optional chaining or guard withisMatterEnabled().Example
Example