Skip to main content

Controller Compatibility Matrix

This page documents which Matter device types work with which controllers, based on community testing and the vendors' published Matter device-type lists.

info

Compatibility depends on controller firmware versions. This matrix reflects the latest known state. If you find discrepancies, please open an issue.

Device Type Support​

Rows flagged with a footnote number link to the vendor source that establishes the value. Rows without a number are established by community testing or by earlier releases of HAMH.

HA DomainMatter Device TypeApple HomeGoogle HomeAlexaAqara HomeSmartThings
lightOnOffLight✅✅ ¹✅ ²✅ ⁴✅
lightDimmableLight✅✅ ¹✅ ²✅ ⁴✅
lightColorTemperatureLight✅✅ ¹✅ ²✅ ⁴✅
lightExtendedColorLight✅✅ ¹✅ ²✅ ⁴✅
switchOnOffPlugInUnit✅✅ ¹✅ ²✅ ⁴✅
switchDimmablePlugInUnit✅❌ ¹✅ ²✅ ⁴✅ ⁶
lockDoorLock✅✅ ¹✅ ²✅ ⁴✅
coverWindowCovering✅✅ ¹✅ ²✅ ⁴✅
climateThermostat✅✅ ¹✅ ²✅ ⁴✅
fanFan✅✅ ¹✅ ²✅ ⁴⚠️
sensorTemperatureSensor✅✅ ¹✅ ²✅ ⁴✅
sensorHumiditySensor✅✅ ¹✅ ²✅ ⁴✅
sensorPressureSensor❌ ⁵✅ ¹❌ ²✅ ⁴✅
sensorIlluminanceSensor✅✅ ¹✅ ²✅ ⁴✅ ⁶
sensorFlowSensor❌ ⁵✅ ¹❌ ²✅ ⁴✅ ⁶
sensorAirQualitySensor✅ ⁵✅ ¹✅ ²✅ ⁴✅ ⁶
sensorElectricalMeter❌✅ ¹❌❓❓
sensor (override)SolarPower❌❌ ¹❓✅ ⁴✅ ⁶
sensor (override)ElectricalUtilityMeter❌✅ ¹❌❓❓
sensor (override)BatteryStorage❌❌ ¹❌✅ ⁴✅ ⁶
sensor (override)EnergyEvse❌❌ ¹❌✅ ⁴✅ ⁶
binary_sensorContactSensor✅✅ ¹✅ ²✅ ⁴✅
binary_sensorOccupancySensor✅✅ ¹✅ ²✅ ⁴✅
binary_sensorSmokeCoAlarm✅ ⁵✅ ¹✅ ²✅ ⁴✅ ⁶
binary_sensor (override)WaterLeakDetector✅ ⁵❌ ¹❌ ²✅ ⁴✅ ⁶
binary_sensor (override)WaterFreezeDetector❌ ⁵❌ ¹❌ ²✅ ⁴✅ ⁶
media_playerSpeaker❌ ⁵✅ ¹❌ ²✅ ⁴✅ ⁶
media_playerBasicVideoPlayer❌ ⁵❌ ¹❓✅ ⁴✅ ⁶
valveWaterValve❌ ⁵❌ ¹❌ ²✅ ⁴✅ ⁶
vacuumRoboticVacuumCleaner✅ ³⁵✅ ¹✅* ²✅ ⁴✅ ⁶
water_heaterThermostat✅✅✅✅ ⁴✅ ⁶
water_heater (override)WaterHeater (Matter 1.4)❌❌ ¹❓✅ ⁴✅ ⁶
alarm_control_panelModeSelect❌ ⁵❓❌**❌ ⁴❓
selectModeSelect❌ ⁵❌***❌**❌ ⁴❓
eventGenericSwitch✅ ⁵❌ ¹✅ ²✅ ⁴✅ ⁶
event (override)Doorbell❌✅ ¹❌❌ ⁴❓
humidifierFan✅✅ ¹✅ ²✅ ⁴⚠️
switch (override)Dishwasher❓ ⁵✅ ¹⚠️ ²✅ ⁴✅ ⁶
switch (override)LaundryWasher❓ ⁵✅ ¹❌ ²✅ ⁴✅ ⁶
switch (override)LaundryDryer❓ ⁵❌ ¹❌ ²✅ ⁴✅ ⁶
weatherTemperatureSensor (+Humidity, +Pressure)⚠️****⚠️****⚠️****❓❓
Apple Home and power readings (iOS 27)

iOS 27 is the first version that shows Matter power readings. Live wattage only appears on outlet tiles, so a metered light needs to be set to On/Off Plug-in Unit, see Light. The Energy view only lists devices paired directly, bridged ones only count towards the total (#484).

ElectricalUtilityMeter is opt-in

ElectricalUtilityMeter (0x0511, Matter 1.4) is only used when you set the Matter device type to "Electrical Utility Meter (Meter Identification)" by hand. It adds the MeterIdentification cluster (meter serial number and point of delivery from the mapping, null when unset) on top of the same power/energy measurements as ElectricalMeter. Google Home lists the type; SmartThings has no driver match for it. Consumption sensors keep defaulting to ElectricalMeter (0x0514), so existing pairings are untouched. See mapping blueprints.

Apple Home refreshes battery percentages only on read

Apple's framework lists PowerSource.BatPercentRemaining as changes-omitted: it stores the value from pairing or from a read and drops subscription updates for it, then re-reads on demand. Charge state updates live. See the FAQ.

EnergyEvse is opt-in and bridge-sensitive

EnergyEvse (0x050C) is only used when you set the Matter device type to "EV Charger (EVSE)" by hand. Home Assistant, Aqara Home and SmartThings render it. SmartThings sets the charge limit through EnableCharging and addresses modes by list position, so the bridge numbers its Manual mode 0. UserMaximumChargeCurrent is optional and not exposed. A bridged EVSE has been reported to break Alexa device recognition, so keep it off any bridge that Alexa pairs with. See mapping blueprints.

The Matter 1.4 water heater is opt-in

By default a water_heater entity is exposed as a plain heating Thermostat, which every controller renders. Setting the Matter device type to "Water Heater with Boost (Matter 1.4)" by hand swaps the endpoint to WaterHeater (0x050F) with the WaterHeaterManagement (cluster revision 2), WaterHeaterMode and Thermostat clusters, which adds the Boost and CancelBoost commands for energy-management controllers. Aqara and SmartThings list 0x050F, the other controllers don't, and changing the type on an already-paired entity requires re-pairing it. See mapping blueprints.

The Doorbell type is opt-in

By default an event entity is exposed as a GenericSwitch, which keeps existing pairings intact. Setting the Matter device type to "Doorbell (experimental)" by hand swaps the endpoint to Doorbell (0x148) with the same momentary Switch cluster. Google Home lists 0x148 as a doorbell. SmartThings only knows the video doorbell (0x0143), and Apple, Alexa and Aqara don't know the type; they fall back to the plain Switch cluster, if they show the device at all. Switching an already-paired entity needs a re-pair.

Leak and freeze detectors are opt-in

By default a moisture or cold binary sensor is exposed as a plain ContactSensor (Matter 1.3), which every controller handles. The WaterLeakDetector and WaterFreezeDetector rows above are Matter 1.4 types that are only used if you set the entity's Matter device type by hand in the Entity Mapping dialog. Setting WaterLeakDetector gives Apple Home (iOS 18.4+) a real leak/alarm tile, but Google does not list these types, Alexa maps water leak to no capability, and exposing a 1.4 detector type can knock out an Alexa bridge so every device on it goes unresponsive (#365). Stay on the default unless you are Apple-only.

Legend​

  • ✅ = Supported, per the vendor source in the footnote or user reports
  • ⚠️ = Partial support or known issues
  • ❓ = Untested or unknown
  • ❌ = Not supported by the controller

* Alexa vacuum support requires the vacuumOnOff feature flag enabled.

** Alexa does not support the standalone ModeSelect device type (0x0027). The ModeSelect cluster is only recognized on specific device types like Lamp or Fan. See Alexa Supported Device Categories and #273.

*** Google Home does not support the standalone ModeSelect device type (0x0027): it is absent from Google's published Matter device types, so Google shows a generic info screen with no options control (#356). The option labels are sent correctly on the wire, this is a controller-side device-type gap, not a bridge bug. The Home Assistant Google Assistant cloud integration does expose these entities as Google "Modes", but that is a separate non-Matter path, not the HAMH bridge. Workaround: use that cloud integration, enable the per-entity "Expose as an on/off switch" mapping (maps on/off to two chosen options, works on all controllers), or expose the entity as an HA template switch or script. See #356 and #296.

**** A weather entity is exposed as a TemperatureSensor with Humidity and Pressure clusters stacked on one device. Temperature and Humidity should work where the standalone sensor rows do; Pressure will not show on Apple or Alexa (see the PressureSensor row). The stacked-cluster shape on a single device is not yet community-tested, so treat these cells as expected, not confirmed.

No switch tile over Matter. Matter has no on/off device type that controllers render as a plain "switch": every controller shows 0x010A as a plug/outlet and 0x0100 (the OnOffSwitch override) as a light. The switch tile you may know from HA's HomeKit Bridge comes from the HomeKit-native Switch service, which has no Matter equivalent. The plist does map 0x0103 (On/Off Light Switch) to the HAP Switch service, but 0x0103 is a controller-side device type (a wall switch that binds to lights), not something a bridge can expose as a controllable endpoint, so the gap stands. Apple's "Show as" works on Matter outlets but only offers Outlet, Light, or Fan. The Matter 1.4 Mounted On/Off Control type (experimental override) shows as a switch on SmartThings and Aqara; Apple, Google, and Alexa don't know the type and are expected to fall back to its advertised plug subset (not yet verified on real devices). For a genuine switch tile on Apple or Google, expose that entity through HA's HomeKit Bridge or Google integration in parallel (#380).

Sources​

Footnote references for the ✅ / ❌ cells above:

  1. Google Home, Supported devices (read 2026-09-23; the page footer still says 2024-12-20, but it lists the 2025 additions like Dishwasher and Laundry Washer). Rows marked ❌ for Google are device types not listed on that page. Laundry Dryer, Refrigerator, Oven and Room AC only show up in Google's developer API catalog so far.
  2. Amazon Alexa, Supported Matter Device Categories and Clusters (doc dated 2026-04-08). Rows marked ❌ for Alexa are device types absent from that page.
  3. Apple Home, Use Matter accessories with the Home app (doc dated 2025-12-12) plus iOS 18.4 release coverage for robot vacuum support. Apple's public doc does not list dishwashers as a supported category.
  4. Aqara Home, Aqara Supported Matter Device Type List (updated 2026-06-05). ❌ for Aqara means the type is not on that list, ❓ that HAMH's endpoint carries more than one type and it's unclear which one Aqara picks.
  5. Apple Home (iOS 26), the internal chipplugin-protocol-map.plist from HomeKitMatter.framework, surfaced in discussion #410. This is Apple's actual Matter to HomeKit translation table. A device type missing from it gets no HomeKit tile unless Apple handles it natively; the plist's NativeMatterDeviceTypes lists only Robot Vacuum (0x0074) and Network Infrastructure Manager (0x0090). Apple cells marked ❌ with this footnote have no entry in the plist, so they get no tile over Matter; Apple's separate media paths (AirPlay, HomeKit native) are outside this matrix. iOS 27 (beta 3 plist) adds Refrigerator, Laundry Washer, Dishwasher, Cooktop, Oven, Laundry Dryer, Electrical Sensor and Electrical Meter as native types. A tester said in July the appliances weren't finished yet, and it's not confirmed that the released Home app shows them, so those cells are ❓. Fans (0x2B), air quality sensors (0x2C) and air purifiers (0x2D) are in the mapping table, so Apple shows them.
  6. SmartThings, the matterGeneric fingerprints of the matter-* Edge drivers (read 2026-09-23). ❓ means no fingerprint for the type, the driver may still pick it up another way.

Apple, Google, Alexa, Aqara, and SmartThings each move at a different cadence. A ❌ here means the vendor has not published support on their current device-type page, not that the device is known to fail. When a vendor adds the category we flip the cell and cite the update.

Aqara Home​

Aqara Home is recognized as a controller: when an Aqara fabric is commissioned, the per-device support chips and the warnings reflect the Aqara column above. These warnings show on the bridge's own page and in the Health Dashboard. Aqara surfaces a wide range of Matter device types, so it rarely warns.

A few Aqara quirks are handled for you:

  • Power/energy clusters are kept off light endpoints, which Aqara would otherwise drop (#374).
  • The root softwareVersionString is aligned with the numeric version so bridge registration does not stall (#316).
  • productName is stripped of characters that crash Aqara when the productNameFromNodeLabel flag is on (#330).

If Aqara does not show an air conditioner, set the entity's disableClimateFanControl flag to expose it as a plain Thermostat (#318). The flag needs a full HAMH restart to take effect, and Aqara caches the bridge's device list, so remove the bridge from Aqara Home and pair it again afterwards. Alternatively, Aqara Home app 5.1.9 with controller firmware 4.3.5 or newer knows the Room Air Conditioner type natively, so updating Aqara can make the default exposure work without the flag. For naming, the productNameFromNodeLabel bridge flag and the per-entity customProductName / customVendorId overrides help Aqara show the device name you expect.

SmartThings​

SmartThings is recognized as a controller too (vendor 0x110A): its column shows in the per-device support chips. The column comes from the device types SmartThings' own Matter drivers match on. None of them is a hard ❌ right now, so a SmartThings fabric raises no warnings yet.

Controller Profiles​

HAMH includes built-in controller profiles that pre-configure feature flags for optimal compatibility:

ProfileKey Settings
Apple HomeautoComposedDevices: true, autoBatteryMapping: true, autoHumidityMapping: true, autoPressureMapping: true
Google HomeautoForceSync: true, autoComposedDevices: true, autoBatteryMapping: true, autoHumidityMapping: true, autoPressureMapping: true
AlexaautoForceSync: true, autoBatteryMapping: true, autoHumidityMapping: true, autoPressureMapping: true, coverUseHomeAssistantPercentage: true
Multi-ControllerautoForceSync: true, autoComposedDevices: true, autoBatteryMapping: true, autoHumidityMapping: true, autoPressureMapping: true

See Bridge Configuration for details on how to select a profile.

Controllers that cannot pair at all​

A controller that only accepts CSA certified devices rejects HAMH during the attestation step of pairing and never gets as far as the device list above. HAMH serves the development attestation matter.js generates by default (test vendor 0xFFF1, "Matter Test PAA", certification type "test"), because an uncertified bridge has no CSA issued Certification Declaration to offer. Nothing in the bridge configuration changes it.

ControllerStateNote
Philips Ambiscape (Ambilight TVs)❌Pairing fails with "Failed", the TV aborts right after attestationRequest. Its compatible list is CSA certified bulbs and hubs only (#465)

See Connectivity Issues for how to recognise this in the log.

Official Controller Documentation​

Contributing​

If you have tested a device type with a controller not marked above, please open an issue or PR with your findings. Include:

  • Controller name and firmware version
  • Device type tested
  • Whether it works, partially works, or doesn't work
  • Any specific issues encountered