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

  1. Remove the 'matter' block from the accessory's _bridge configuration
  2. If Matter is required, host the accessory under a platform-type child bridge instead of an accessory child bridge
  3. 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

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


AI-assisted analysis of homebridge/homebridge@edf5493034 (2026-08-30). Data as JSON: /api/errors/e94cda9aa3550e0b. Report an issue: GitHub.