homebridge/homebridge · info
Matter is not supported on accessory child bridges. Ignoring
Error message
Matter is not supported on accessory child bridges. Ignoring matter configuration.
What it means
Informs that a child bridge hosting a single accessory (PluginType.ACCESSORY) has a 'matter' config block, but Matter is not supported for accessory-type child bridges, so the configuration is ignored. The fork checks isMatterActive(bridgeConfig.matter) combined with the bridge type and logs this warning instead of loading Matter. Only platform-type child bridges can expose Matter.
Source
Thrown at src/childBridgeFork.ts:157
// load plugin
this.plugin = this.pluginManager.loadPlugin(data.pluginPath)
await this.plugin.load()
await this.pluginManager.initializePlugin(this.plugin, data.identifier)
// change process title to include plugin name
process.title = `homebridge: ${this.plugin.getPluginIdentifier()}`
this.sendMessage<ChildProcessPluginLoadedEventData>(ChildProcessMessageEventType.LOADED, {
version: this.plugin.version,
})
}
async startBridge(): Promise<void> {
// Conditionally load Matter support only if this child bridge has Matter active
// (configured + enabled OR externalsOnly). Prevents loading heavy Matter.js
// libraries for child bridges that don't use it.
if (isMatterActive(this.bridgeConfig.matter) && this.type === PluginType.ACCESSORY) {
matterLogger.warn('Matter is not supported on accessory child bridges. Ignoring matter configuration.')
}
if (isMatterActive(this.bridgeConfig.matter) && this.type !== PluginType.ACCESSORY) {
matterLogger.info('Loading Matter support for child bridge...')
// Note: api.loadMatterAPI() was already called at the start of loadPlugin()
// so api.matter is already defined by the time the plugin's initializer ran.
// Dynamically import Matter manager only when needed
const { ChildBridgeMatterManager } = await import('./matter/index.js')
// Create Matter bridge manager
this.matterManager = new ChildBridgeMatterManager(
this.bridgeConfig,
this.bridgeOptions,
this.api,
this.externalPortService,
this.pluginManager,View on GitHub (pinned to edf5493034)
Solutions
- Remove the 'matter' block from the accessory's _bridge configuration
- If Matter is required, host the accessory under a platform-type child bridge instead of an accessory child bridge
- Leave HAP enabled on the accessory child bridge so it remains reachable
Example fix
// before
{ "accessories": [{ "accessory": "X", "name": "X", "_bridge": { "matter": { "enabled": true } } }] }
// after
{ "accessories": [{ "accessory": "X", "name": "X", "_bridge": { "name": "X bridge" } }] } Defensive patterns
Strategy: validation
Validate before calling
const bridge = accessoryConfig._bridge
if (bridge?.matter) console.warn('matter is ignored on accessory child bridges; move to a platform child bridge') Prevention
- Only add 'matter' blocks to platform-type child bridges
- Document that accessory child bridges are HAP-only
- Use Config UI X which knows the valid schema per bridge type
When it happens
Trigger: An accessory config block with a '_bridge': { 'matter': {...} } section, started via ChildBridgeFork with type = PluginType.ACCESSORY.
Common situations: User copies a platform child bridge's _bridge config onto a single accessory block; config-ui generates a child bridge for an accessory and Matter was enabled by mistake.
Related errors
- Both HAP and Matter are disabled for this child bridge; it w
- Failed to allocate Matter port for child bridge. Please spec
- Matter configuration validation failed: ${errors.map(e => `
- Storage path is required for Matter server
- Error loading the ${type} "${identifier}" requested in your
AI-assisted analysis of homebridge/homebridge@edf5493034 (2026-08-30).
Data as JSON: /api/errors/e94cda9aa3550e0b.
Report an issue: GitHub.