AI Plugin Factory to accelerate Matterbridge ecosystem growth

[Pierre-Gilles]

Hi @Luligu 👋

First of all, thank you for creating and maintaining Matterbridge. It's an incredible project that fills a crucial gap in the smart home ecosystem by bridging legacy devices to Matter.

I've been actively promoting Matterbridge within my own project, Gladys Assistant (an open-source home automation software), and the feedback from our community has been overwhelmingly positive.

The Idea: An AI-Powered Plugin Factory

I recently built a Matterbridge plugin entirely using AI (Claude Opus 4.5 on Windsurf), and it got me thinking: could we take this further and automate plugin creation at scale?

Context

I analyzed the Home Assistant Analytics data and identified many popular integrations that control physical devices compatible with Matter device types (lights, switches, thermostats, sensors, covers, locks, etc.) but don't have a Matterbridge plugin yet.

The Concept

Automate the plugin creation with an AI coding agent (Claude Code) that would:

1. Pick an integration from a prioritized backlog
2. Analyze the device's API (using HA integration source code, official docs, existing npm libraries)
3. Generate a complete Matterbridge plugin following your plugin template structure
4. Create a PR on GitHub with the generated code
5. Run automated tests (lint, build, unit tests)

Community Testing Workflow

Since the AI can't physically test devices, we'd need feedbacks from real users:

Agent creates PR 
→ Community testers install from GitHub 
→ Feedback in Github Issue
→ Agent iterates 
→ Merge & Publish

I'd love to hear your thoughts on this approach!

[Luligu]

Hi,
first of all thanks for your appreciation.

The big part of users, use the Hass plugin to port those devices to Matter.

But having specific plugins for those integrations, would be great and very appreciated.

I love your idea and suggestion, but personally I reached (probably exceeded) my capacity to maintain so many projects so I don't think I can make other plugins.

What can certainly be done on my side is to implements more and better the AI guides for the Matterbridge ecosystem (https://code.visualstudio.com/docs/copilot/customization/custom-instructions).

[Pierre-Gilles]

Thanks for your reply, and no worries, I wasn’t asking you to build this 🙂 I just wanted to share the idea.

I’ll check with the community to identify which Matterbridge plugins are most needed, and we’ll see if we can build something around that.

If we do, I’ll make sure to share the GitHub repo with you.

[Pierre-Gilles]

I've started building the AI plugin factory: https://github.com/GladysAssistant/matterbridge-ai-plugin-factory

It's still work in progress, but very promising.

[Luligu]

Hi,
I spent a couple of hours on your site and I want to tell you that the project is amazing!!!

I will install it during the weekend.

And also try to implement the AI custom instructions.

If you allow me, I will add a link to your site in https://matterbridge.io.

[Pierre-Gilles]

Thank you so much!!

If you have any feedback or notice anything that isn’t working properly, don’t hesitate to reach out 🙂

If you allow me, I will add a link to your site in https://matterbridge.io/.

Yes, of course, that would be awesome, thank you! 🙏

[Luligu]

Thank you so much!!

If you have any feedback or notice anything that isn’t working properly, don’t hesitate to reach out 🙂

If you allow me, I will add a link to your site in https://matterbridge.io/.

Yes, of course, that would be awesome, thank you! 🙏

Since you asked, I noticed a thing on the website that I didn't understand probably my fault.

I had the feeling that intentionally Gladys drops 99% (I guess but I don't really know) of systems in the world.

Why not use Windows and macOS PCs that all potential users have at home ?

If I missed something, I apologize in advance and forget this.

Also the docker script, I had to manually edit it cause it doesn't work on PowerShell.

I drop a double script for all systems: https://matterbridge.io/reflector/Reflector.html.

[Pierre-Gilles]

Good question 🙂

Gladys is designed to run on a dedicated mini-PC at home (Beelink, Miniforum, Intel NUC, Raspberry Pi, ...) that stays powered on 24/7.

A regular Windows or Mac computer that you use day-to-day isn’t really a good fit. If you shut it down or reboot it, your whole smart home goes offline, meaning you can’t control things like your lights anymore.

I’m not sure it’s a good idea to encourage users to run their entire smart home on their personal desktop machine.

That said, for testing, Gladys runs in Docker and can easily be started on macOS or Windows using Docker Desktop or OrbStack.

Hope that makes sense 🙂

[Luligu]

Hi,
I added the link.

Here

here

and here https://hub.docker.com/r/luligu/matterbridge

[Pierre-Gilles]

Amazing, thank you! 🙌

[Luligu]

For the AI custom instruction for Copilot and Claude, I made some progress, I will migrate them in all repo during the week.

And get back here.

[Apollon77]

Whatever you plan the following is very important to keep in mind: We need QUALITY not QUANTITY!
Anything you do need to ensure that the generated integrations are compliant to the matter system and also definitions that the matter specification takes and must not abuse things. We should also discuss any ecosystem specific issues and "Pragmatic workarounds" to really ensure that these are not making things worse "just because it is possible".

Keep in mind that all work here is awesome for users but 100% uncertified and we should try to ensure that all work here is as best compatible with the ecosystems as possible to still have good ways to work together and not against each other.

So "Scale" .. ok ... but who does the real human review?

[Pierre-Gilles]

Yes, I entirely agree! The goal is definitely not to flood the ecosystem with low-quality or untested plugins.

My primary goal here is twofold: show that this kind of AI-assisted development workflow is actually possible, and help spread the word about Matterbridge, which I think is a hugely underrated project. I've already published 2 YouTube videos on Matterbridge (in French) and the feedback has been genuinely great!

The second goal is more practical: jumpstart plugin development for "less known" devices that have been stuck in limbo simply because there weren't enough developers or time to cover them. That's where AI can really make a difference. Not by replacing human judgment, but by unblocking things that were previously impossible for small communities to tackle.

And your point about human review is well taken. All plugins will go through real user testing before being considered stable.

For now, I'm only generating .tar.gz archives, not publishing anything to NPM.

[Luligu]

The first release of AI instruction (for both Copilot and Claude) is spreading through the plugins repos.
The most interesting for your goal is the plugin template (always the first to be updated with new features).

[Luligu]

That's great,
Keep me up to date cause the actual one is just the first release.
I will add more instruction files in the next (always keeping double layer Copilot and Claude).

[Pierre-Gilles]

Just to keep you in the loop, we currently have two plugins in development:

• Yeelight: Thanks to your updated instructions, Claude nailed it in one shot: it worked on the first try. You can check it out here.

• Daikin Onecta: This one was a bit more challenging due to a complex authentication flow. After a few iterations with the end user, we now have something solid (link). A few more refinements are still needed.

One piece of feedback I’ve received from several users: the plugin upload process is a bit confusing. Currently, users need to:

1. Upload the plugin
2. Enter its name
3. Click "Install"

The issue is that the modal shown after upload says "plugin installed, restart required", while in reality, there’s still a step missing.
Do you see what I mean?

[Luligu]

Hi,
that's really great.
What AI are you using: Copilot or Claude ?

Thanks for the feedback.

I added a best effort to add the plugin: b75d73d

[Pierre-Gilles]

Hi, I’m using Claude Code running on a VPS on Hetzner. It picks up issues as “new jobs” and generates plugins autonomously.

I was away all week, and people were still building plugins with it entirely on their own while I wasn’t involved at all 😄

We’re already managing to get fully functional plugins out of it, which is honestly pretty wild :o

I added a best effort to add the plugin: b75d73d

Thanks a lot for this contribution!

[Luligu]

I will push an upgrade to instructions during the weekend.

Also working (that will take a few more days) to make usable for everyone my "automator". The piece of software that keeps all packages up to date with just one click. That's working at the moment only when running on my machine for my packages but it will work also for third parties packages soon.

The idea is that devs just focus on code while the package upgrades are handled automatically like I do for my packages.

[Luligu]

@Pierre-Gilles
Hi,
as promised I updated the instructions.

I will also add some specific prompt/task to make the agent check the code... this agent integration is really cool.

Check also this please: #558

[Pierre-Gilles]

Ooh indeed now I understand!

[Pierre-Gilles]

Would it be possible to add some kind of recovery mechanism for these plugins so they can survive a container re-creation? For example, by storing the .tar.gz files in a persistent volume.

Otherwise, we could publish all packages to NPM even while they’re still under review, but I’m a bit concerned that this could lead to low-quality plugins being published publicly on NPM.

[Luligu]

I can work on that if you need it.
Actually I like the idea.
The uploaded packages are already stored in a persistent volume (.matterbridge/uploads).
I need to find some best effort way to find the correct one...

Concerning
"Otherwise, we could publish all packages to NPM even while they’re still under review, but I’m a bit concerned that this could lead to low-quality plugins being published publicly on NPM."
I agree with you and would avoid to publish on npm even with tag dev something that is not working at all.
If they are working but under development maybe with tag dev could be a solution.
But if you want to give a correct feeling of professionality to users, the way you are managing these new plugins is already the best: no public access before they are ready for production.

[Pierre-Gilles]

That would be great!

Yes, I agree, we should continue testing plugins using .tar.gz packages. My concern is that if this breaks production instances for users, some of them may become reluctant to try these plugins again in the future. Those testers (like "prohand") are not developers, just tech enthusiasts.

[Luligu]

That would be great!

Yes, I agree, we should continue testing plugins using .tar.gz packages. My concern is that if this breaks production instances for users, some of them may become reluctant to try these plugins again in the future. Those testers (like "prohand") are not developers, just tech enthusiasts.

I got it.
I will do my best.

[Luligu]

Hi @Pierre-Gilles @prohand

I finished today what will be in the next release:

• manage tarball plugins not published on npm (it needs private=true in package.json). On docker recreate, matterbridge reinstalls them automatically from the last used tarball. And will not try to install from npm. So docker recreate (your case) will do everything automatically.

• manage local plugins correctly also in docker. It links matterbridge in the plugin (no need to override the container command). So docker recreate (your case) will do everything automatically.

Test on code are green and real life tests too.

[Pierre-Gilles]

Nice!! Thanks a lot 🙌

[prohand]

Thank you very much :)