Matterbridge + AI = Revolution for Gladys 🚀

News
1

Hello everyone,

I’ve been tinkering a lot last week around Matterbridge, and I had a real revelation that I wanted to share with you here :smiley:

:backhand_index_pointing_right: We’ll be able to make any device Matter-compatible (and therefore Gladys-compatible), and without coding!!

A bit of context

I already told you about Matterbridge, a project that allows you to install plugins to add non-Matter devices to Matter.

Today, Matterbridge already allows you to use in Gladys:

But Matterbridge is still young, and doesn’t have a plugin for everything.

The problem it solves

In Gladys, I’ve always taken the approach of developing « large custom integrations, » spending a lot of time on the user experience and interface.

However, some of you have very specific needs: devices that are not widely available, sometimes even no longer sold. For these products, it’s difficult to justify the development time of a native integration to serve only a handful of users.

What if these integrations could be simple Matterbridge plugins, developed by an AI?

The Matterbridge plugin system is well-coded, well-documented, with plenty of examples.

And often, these integrations already exist elsewhere in open-source (Node-RED, Home Assistant): we can simply ask the AI to translate a Node-RED plugin into a Matterbridge plugin.

There’s nothing to invent, it’s just « translating code »!

What I’ve tested

I developed a Matterbridge plugin for my Mitsubishi air conditioning, without writing a single line of code.

I’ll show you all that here:

And now?

The logical next step: what if we completely automated the creation of Matterbridge plugins?

Imagine a « plugin factory, » driven by Claude Code, running on a server, that would process GitHub tickets and develop plugins without human intervention.

usine-a-plugin-schema
usine-a-plugin-schema1408×768 267 KB

With a system like this, we could industrialize the development of integrations and reduce the gap between Gladys and projects like Home Assistant.

I think this is a real revolution. And it reassures me in my choice to invest a lot of resources in Matter this year, because it’s really the future of the connected home.

What do you think?

6 Likes
3

I find that this is a very good analysis, as in the same spirit I have used AI to « translate » a scene flow that I had in mind and transform it into JSON importable into Node-red. I find that this is a relevant use of AI.

I am just wondering about the way to secure all this in terms of efficiency: it would be necessary to integrate tests to ensure that the generated plugins are relevant and functional, right? Or is it a manual review on your part?

Because I have the impression that this could quickly become a beautiful mess ^^

In any case, the idea is very interesting and could indeed respond to the famous « weakness » of Gladys, namely the number of integrations/devices supported :+1::+1:

1 Like
4

Claude Code is smart enough to perform tests with a real Matterbridge instance. However, for testing on real hardware, user feedback will be necessary.

For me, this could work through GitHub tickets: the user gives feedback to Claude Code, and it then proposes a fix until a correct result is obtained.

The idea would really be to move towards a « 100% automated » chain. On my side, my time is too limited to manually review all the plugins :grinning_face_with_smiling_eyes:

I actually discussed this with the founder of Matterbridge and it seems to excite him quite a bit as well!

Now remains the question of cost: who finances the tokens necessary to generate the plugins?

1 Like
5

Petite question : Will the developed plugin be usable only for Gladys or can it be used by all systems implementing Matterbridge?

6

Matterbridge is exposed on the Matter protocol. Therefore, all systems can integrate Matter devices.

1 Like
7

Yes, exactly. Matterbridge is just a software that connects Matter ↔ any protocol

So the plugin will work with everything: Apple Home, Google, Alexa, Gladys, Home Assistant, etc…

8

The idea seems excellent, however, it might be better to prioritize plugin requests based on the popularity of the request. That is, if a certain number of users approve or « like » the GitHub ticket for the request. Several advantages to this:

  • Control or validation of the request
  • Avoid too many requests to Claude for unpopular requests: thus reducing the cost of tokens

I don’t know if it’s possible to determine the cost of Claude for your Mitsubishi air conditioning. But if we could have an estimate, it would give an idea of the cost of a plugin.

If this represents costs below a few euros, I think several people would be able to contribute. (Okay, it’s maybe not so simple to set up…)

9

It all depends on the cost. For me, the idea of this « plugin factory » is precisely to allow covering less popular integrations as well.

The problem with voting systems is that a user with a less common device will probably never have a plugin… which is already the case today in Gladys :grinning_face_with_smiling_eyes:

It was through Windsurf, so it’s not entirely transparent, but to give you an idea, I pay $15 per month. I developed the plugin in half a day.

Honestly, I think this pricing is quite aggressive and probably subsidized to attract developers. On Claude Code in CLI, it will probably be more expensive.

I also think it’s a good lead. If we realize that a plugin costs 5 to 10$ to generate, it’s largely affordable. Most people would be willing to pay that to have their device supported in Gladys in a sustainable way :slightly_smiling_face:

1 Like
10

I confirm that personally, if a plugin costs 10 or even 15€, I will go for direct payment! I may not represent the majority of people, but in itself, if a plugin is really indispensable to me, I would even be willing to pay double ^^

2 Likes
11

Yes, same here, my air conditioning cost me more than 2000€, spending a few dozen euros once to have it connected throughout my home automation, it’s obvious :smiley:

1 Like
12

You already know my opinion on this point ^^ :wink: Of course. When you compare it to the usefulness, it’s really not that expensive at all. And in this case, everyone can prioritize according to their real needs.

Don’t forget, however, that for very specific needs, there will be development for Gladys as well. I’m thinking of devices like robotic lawn mowers → New feature category/type; Implementation of Dashboard management / scenes.

But for 90% of standard equipment, it’s all good ^^

1 Like
13

Once we cover 100% of the Matter spec in Gladys, there will be nothing left to do on the Gladys side :grin: but yes, until that’s the case, some adjustments are needed, like what I recently did with robot vacuums for example!

2 Likes
14

We are right in the logic of free software: « development that benefits everyone ».

Now remains the question of cost: who finances the tokens necessary to generate the plugins?

I would see a token purchase system.

For example, 15 tokens for the development of a plugin.

First step: a person deposits the product they want to make compatible.

Second step: people interested in the same product make themselves known to share the costs and move to production.

For example, three people put in 5 tokens.

Third step: if no one else comes forward or if the person is in a hurry, they finance the whole thing and move to production.

1 Like
15

Hello everyone, this is very exciting because it actually addresses Gladys’ « weakness » with somewhat exotic devices…

Honestly, paying €10 for an integration, I would be happy to do so without any problem.

1 Like
16

Today, I am not a Gladys user but a Home Assistant user for two reasons:

  • the number of devices supported by HA is much larger
  • the power of implementing « graphical » dashboards is much more advanced.

The plugin factory is interesting and I am ready to pay 5 or 10 euros for a plugin but what about maintenance? Would we have to pay for a plugin update? Paying 5 or 10 euros seems reasonable but if you have to pay every time an update is necessary, it will make the factory much less interesting.

What about dashboards, which, in my opinion, is another weak point of Gladys?
What is planned, in the long term, to make the Gladys interface more « sexy » for the end user?

2 Likes
17

Hello @filbou40, thank you for your feedback!

Regarding maintenance, that’s a great question :grinning_face_with_smiling_eyes:. It really depends on the modifications. If it’s very complex, it might cost the same as a plugin. If it’s very simple, it might be quite cheap. We could ask the AI to evaluate the task’s complexity before starting.

I’m really interested in this point, would you mind creating a separate topic to discuss it?

Same for that!!

Feedback from users who don’t use Gladys is very valuable to me, so I’m really interested in getting your complete feedback!

1 Like
18

Hello, I have created a topic dedicated to dashboards in « Feature Requests ». I hope I created it in the right place.

1 Like