I’ve been following your exchanges on GitHub with the plugin factory, particularly this comment:
Please find another solution to be sure that those “new” devices are in fact the same as the previous ones saved in Gladys.
In reality, this part isn’t managed by the plugin, so Claude Code won’t really be able to improve anything regarding the pairing mechanism.
If you’re having difficulties with Matterbridge in your development and testing cycle, the most relevant approach would be to open an issue on Matterbridge’s main repository to explain precisely what isn’t working and see with its developer if it’s possible to improve the workflow.
However, if we start this discussion, it’s better to come with reproducible cases and, if possible, examples from plugins already used in production. This will help show that it’s indeed a general limitation of Matterbridge and not a case specific to the plugin.
cc @prohand: I think you’re also concerned in your tests
Yes, this AI is starting to get on my nerves with this dev
Matterbridge isn’t the issue for me.
There’s a serial number for Mitsubishi air conditioners that’s 36 characters long: I don’t know who generates them, knowing that Matterbridge only sends 32 to Gladys.
So when there’s a plugin stop and restart, we get new endpoints with the same serial numbers in Matterbridge but not in Gladys, hence the new devices instead of a simple update.
So I asked the AI to find a solution to have a shorter serial number.
And this idiot AI (sorry, the mustard…) modifies the code (twice already) and generates an even longer serial number!
In short, if it doesn’t work with my last comment, I give up because I don’t know how to talk to it properly (but well, it started with the early days of Siri and I still don’t know how to talk to it).
From my experience, Claude Opus 4.8 is really at the level of a good developer. So if the experience is frustrating, the problem probably comes from something other than Claude’s “intelligence”
Confusing Scope: Here, you’re actually asking it to manage “2 plugins in one”. This significantly increases complexity and makes the behavior difficult to frame, especially if you’re only testing one of the two branches. I think it would be worth creating a simpler ticket: one plugin, one API, one use case. This makes development and especially validation much simpler.
Lack of AI Feedback: The experience could be improved by systematically returning feedback in the GitHub issue. For example, a simple phrase like: “I modified X / I found nothing to change / not enough information”. Today, we have the impression of working “in a vacuum”, which is frustrating on the test side, because we don’t even know if the AI had something to do or if it concluded that there was nothing to modify.
The SERIAL_NUMBER displayed in Gladys is purely informational: it is not used to reconcile two devices with different NodeIDs.
For deduplication / updating an existing device, if no device exists with the same NodeId, Gladys relies on the uniqueId provided by Matter, and not on the serial number!
I understand, and that probably fuels my frustration, and starting over from scratch makes it even worse… well, I’ll see when I feel better.
For the last factory fix, he handled the sending of serial number and unique ID from matterbridge to Gladys very well, and they are strictly identical.
My question is who manages/generates the NodeID?
How can I find it?
In all logic and following what you describe as behavior, Gladys should see that the Unique ID is identical, right? And therefore perform an update instead of an addition?
At this point, I think the issue is with Gladys and not the factory, am I right?
I looked into it, in the case of Matterbridge, the NodeId is generated/assigned during the pairing of the instance with the Matter fabric (so Gladys in this case).
Then, each device is in « ChildBridge » mode under Matterbridge, and is identified by its endpoint number.
So in fact, here you will have a single Node ID, it’s really a particular case of Matter, the Matterbridge case.
In Gladys, you can find this structure directly in the Matter integration settings: you will see the NodeId of the Matterbridge instance, then the endpoints associated with each device.
I’m sharing the pastebin of my discussion with the AI on the matterbridge repo that helped me understand all this
Thanks!
Not on my side, I didn’t understand everything
I don’t necessarily agree with what is written but okay.
For example, I tested and retested the official somfy plugin of matterbridge: adding all my shutters in Gladys, uninstalling the plugin, reinstalling and therefore new endpoints → no new device to add in Gladys, everything was recognized and functional.
Totally identical behavior with just a disable plugin and enable plugin.
That’s why I don’t understand why for now there is such a difference in behavior.
