@mutmut Thanks for the feedback.
Regarding the battery level of the shutters, the Tahoma plugin displays:
As there is a lot of sun at the moment, I don’t know if it’s reliable…
Regarding the Cosytouch plugin, do you need a Cosytouch hub or just an account?
Does it go through the cloud?
Both, my captain 
Well, I say that but I don’t have Cosytouch, but I use this plugin for Somfy with a ConneXoon box.
I tried to go local without success and I didn’t get a response to my request on GitHub.
I’ll test this new plugin then.
Hi everyone 
After the release of external integrations in Gladys, I wanted to share my experience with Matterbridge and explain why I will now direct users towards external integrations.
When I discovered Matterbridge, I found the concept really excellent: allowing devices that are not yet Matter-compatible to be integrated with Gladys through an abstraction layer. I believed in it, recommended this solution, and even directed several developments in this direction hoping it would allow more users to join the Gladys ecosystem.
After about two months of use and community feedback, I must admit that I am no longer entirely satisfied with this approach. In hindsight, I think that Gladys external integrations are superior in every way, and this will now be the solution I recommend.
Matterbridge is a very good project, but it is primarily designed by developers, for developers.
From the feedback I’ve read on the forum, the experience often becomes complicated when something doesn’t work. Problems are difficult to diagnose, and solutions are not always obvious.
In my opinion, this mainly comes from the technical choices made.
Matterbridge works a bit like Gladys v3: plugins are installed directly in the main container, with dependencies installed at startup (runtime). This approach is convenient at first, but it quickly becomes fragile: a dependency update can break a plugin without warning.
Gladys external integrations follow a very different approach:
This architectural choice completely changes the game in terms of stability.
Matterbridge remains dependent on the Matter standard.
However, if some devices are still not Matter-compatible today, it’s often not by chance: it’s often because the protocol does not yet allow expressing all their features, or because certain types of devices simply do not exist in the specification.
In other words, Matterbridge will always be limited by the possibilities offered by Matter.
On the other hand, a Gladys external integration can exploit 100% of a device’s capabilities, without being constrained by an intermediate standard.
Finally, Matterbridge is an external project.
When some users encountered bugs, it was often frustrating for me because I simply couldn’t fix them. I was dependent on the evolution of another project.
With external integrations, we fully control the platform. Developers can publish their integrations freely, evolve them at their own pace, and we can improve the ecosystem without depending on an intermediate layer.
Now that external integrations exist, I no longer see any reason to continue promoting Matterbridge for this use case.
External integrations fulfill exactly the same role, with better stability, a better user experience, and many more possibilities.
As external integrations replace the Matterbridge plugins I had recommended, I will update the documentation and gradually remove Matterbridge tutorials in favor of these new integrations.
Regarding the plugin factory, it represents a monthly cost (servers + AI). I don’t think I will keep it in the long term: I prefer to invest these resources directly in the development of Gladys. 
I hope you will understand this change of position. It’s not about being indecisive: AI is evolving our way of developing at an incredible speed, and I think it’s important to know how to question your choices when better solutions appear.
In the end, I mainly retain one thing from this adventure: Matterbridge gave me the idea that led to Gladys external integrations.
Without this experience, this feature would probably never have seen the light of day. And today, I genuinely think it’s one of the most important evolutions of Gladys in a long time.
Thank you all for your feedback, your tests, and your trust 
Hello @pierre-gilles,
I am watching with interest what is happening in the Gladys universe with the arrival of AI. I fear that Gladys may be carried away by this creative euphoria of creating new modules without thinking too much about the philosophy of Gladys. Let me explain. I notice that most of the new modules rely on manufacturers’ clouds. Now (in my opinion) what makes Gladys strong (and all its interest for me) is the security of our data.
Can you reassure me on this question?
Hello @l.dolle,
The philosophy hasn’t changed: I continue to prioritize local integrations as much as possible (Zigbee, Matter, etc.).
However, we also need to be realistic: most people, in France and elsewhere, already own devices that are neither Zigbee nor Matter. A camera bought at Lidl, a plug found on Amazon, a weather station given by a relative… These devices exist, and users want to be able to integrate them.
So far, this has been a real hurdle for Gladys. Every year, users chose Home Assistant because it is compatible with almost everything (over 1,300 integrations), while Gladys only had 36 until last week.
In my opinion, sticking to a very strict position would have ended up harming the project. The goal isn’t to abandon our values, but to allow more people to use Gladys with the equipment they already own.
External integrations completely change the game: they finally allow us to become competitive without sacrificing the core of the project. Local integrations remain the reference, but we no longer exclude other possibilities when they meet a real need.
And I even think this is beneficial in the long term. Someone who starts with a cloud integration, for example, will gradually discover the advantages of Zigbee or Matter (speed, reliability, cloud independence) and will naturally tend to prioritize local devices for their next purchases.
Today, our problem isn’t that users are buying too many cloud devices. Our problem is that they aren’t coming to Gladys because they can’t connect the devices they already own. External integrations allow us to remove this barrier to entry while continuing to promote local and sustainable home automation.
Thanks for your reply.
Indeed, this gives users more freedom.
Great job on your work.
