Reviving matterbridge-mqtt — interest in a generic MQTT device plugin?

[megusd]

Hi @Luligu,
First, thank you for the excellent work on Matterbridge and the zigbee2mqtt plugin

I noticed that matterbridge-mqtt was published on npm some time ago but the repository no longer appears to be available. I’m guessing it may have been an early experiment that didn’t survive one of the matter.js API upgrade cycles.
I’m in the process of migrating away from Homebridge toward a standalone Matterbridge + Z2M stack on Proxmox LXC, and the one remaining gap I have is exposing arbitrary MQTT devices that aren’t managed by Z2M — specifically ESPHome-based switches and custom exTuya wifi-mqtt devices.
These devices already publish state and accept commands via MQTT topics, but there’s currently no active Matterbridge plugin that can bridge them to Matter without HA in the middle.
Before investing time building something from scratch, I wanted to ask:
1. Was matterbridge-mqtt intentionally retired, or did it simply fall behind the API changes?
2. Is there any interest in reviving or replacing it as an official plugin — either by me contributing or by it being a separate community plugin listed alongside the others?
3. Would you prefer this be a generic MQTT device plugin (config-file-driven topic mappings), or do you see a better architectural approach for non-Z2M MQTT devices?
I’m comfortable with TypeScript and strated contributing to another Zigbee project, so I’m happy to do the work — just want to make sure I’m not duplicating something already in progress, and ideally align with your plugin conventions from the start.
Thanks for any feedback.

[Luligu]

Hi,
first of all thanks for you interest.

The mqtt plugin is not visible anymore cause I filter out the plugin that are just a name reservation or not ready (for better user experience).

In the mqtt case the idea is to allow any custom device to write to a mqtt broker its config and its state and to subscribe to matter commands.

Like matterbridgemqtt general topic then /deviceid then /config and /state.

The plugin just export that to matter.

I will finish it one day... but feel free to do it yourself.

My idea was to configure the config to be exactly what we need for Matter:

• the root endpoint composition (device types ids and cluster ids)

• the children endpoint composition (endpoint id, device types ids and cluster ids)

• for state to just pass the endpoint id (root or any children), cluster id, attribute id and attribute value.

• for Matter commands the device receive the full command request (/command) and act as needed and then update its state (/state).

Use the plugin template that also has the AI support and makes developing very easy.

I'm here if you need any help.

[Luligu]

@megusd
Yesterday I made some progress on the plugin.
Give me one more week and will be published.

[Luligu]

It is released if you are still interested.
Still a couple of point in the todo list.