🚀 Matter & Gladys Assistant: Here we go!

[pierre-gilles]

No, I use their plugin matterbridge-example-dynamic-platform, it’s really handy — it generates dozens of devices of every existing type, so you can test lots of devices!

[pierre-gilles]

I pushed an image to fix a small bug, in some cases I had devices with an empty deviceData which broke the integration

However, I can control the plugs in Matterbridge, so good news everything works!

It’s just the device « CookTop » that I can’t control, but I wonder if it’s just a sensor…

Ah, I think I understood:

Since these are cooktops, they can only be turned OFF, not ON (which would be very dangerous!). That only allows turning them off remotely

Well, another thing to implement aha, but I don’t think there are that many devices on the market for this, so it’s not my priority.

[pierre-gilles]

This morning I’m adding control for 2 essential features: brightness management and color of connected bulbs

I’m testing all of this in real life with the excellent bulb Nanoleaft Matter Thread E27:

[pierre-gilles]

I’ve just published a new image with color and brightness control for the bulbs

[pierre-gilles]

I just published a new image with humidity sensor support

[pierre-gilles]

I just published a new image with thermostat management (heating + air conditioning), for now I handle the target temperature as well as turning it on/off

[guim31]

You can’t be stopped anymore!

[mutmut]

a Machine our @pierre-gilles

[mutmut]

Some test feedback

@pierre-gilles

I improved the title of the deviceFeatures

An excellent feature! I see the Endpoint numbers in the names of the devices to add and have added them.

However, I just removed the somfy plugin from matterbridge and the paired devices are still present
Then I reinstalled the plugin and I ended up with new Endpoint numbers BUT Gladys kept the old numbers for the paired devices.
I tested up/down and it doesn’t work.

I decommissioned that matterbridge; the paired somfy devices did disappear.

I added the matterbidge and the somfy devices reappeared with their new Endpoints, and my saved devices are no longer linked to anything :(, forcing me to delete them and redo everything.

@pierre-gilles

However, I removed device replacement via unique_id, it’s no longer possible; moreover it never fully worked, because I have no way to identify a child_device, only the physical device. Inside the device, each endpoint number can change, so it’s impossible to do full matching, especially for devices with the same feature multiple times!

From what I could see (with the somfy plugin), the Endpoints change with each reinstallation as you said, however the serialNumber and uniqueId are identical each time. I don’t know if that could be a possible lead.

@pierre-gilles

Spinner when adding a new device with a small message to warn that this can take several minutes (like on iOS)

There should also be a spinner when decommissioning a device because decommissioning a matterbridge can take time and you can’t tell if it’s in progress.

[pierre-gilles]

@mutmut

However, I just removed the somfy plugin from matterbridge and the paired devices are still present

Yes, paired devices do not disappear even if you delete them on the Matterbridge side; that’s how Matter works.

Similarly, if my Eve Energy smart plug is unreachable, it remains visible everywhere (on my iPhone for example, it stays in HomeKit).

In this case, this behavior comes from Matter and not from Gladys.

@mutmut

Then reinstalling the plugin and I end up with new Endpoint numbers BUT Gladys kept the old numbers for the paired devices.

Yes, unfortunately since the plugin changes the endpoint numbers we cannot match the old and the new.

However, we could at least display a « No Response » on the old one, that’s what iOS does for example:

@mutmut

however the serialNumber and uniqueId are identical each time

That’s not sufficient unfortunately, the uniqueId is specific to the Matter « parent » device, whereas within that device I can have multiple "child_device"s each with their own list of features.

There is no identifier beneath that doesn’t change.

I’d be curious to see what happens on another Matter controller — could you test the same behavior on iOS or on Google Home?

@mutmut

There should also be a spinner when decommissioning a device because decommissioning a matterbridge can take time and you don’t know if it’s running or not.

Good point! I’ll add that

[Terdious]

@pierre-gilles

Yes, unfortunately since the plugin changes the endpoint numbers we can’t match the old and the new.

@pierre-gilles

That’s not sufficient unfortunately, the uniqueId is specific to the Matter « parent » device, whereas in this device I can have multiple « child_device » each with their own list of features.

I made several attempts switching on Matterbridge from « bridge » to « childbridge » and yes, of course the endpoint changes but the endpoints of the features are always in the same order, i.e. the device’s endpoint + 1 etc. So, in essence, you should be able to re-pair them together but by trying another way.
For me I still maintain that :

• node_id is a parameter => that can change
• endpoint is a parameter => that can change.

If for external_id you take :

• device => the serial number if available, or the unique_id if available, or something else… (to find; if nothing else is available then warn that historical data will be lost in case of re-pairing)
• features => device’s external_id + « -1 » for the device’s first endpoint, « -2 » for the second etc.

Normally there is no reason you shouldn’t be able to re-associate them and you update the parameters « node_id » and « endpoint » for each of the devices…

[pierre-gilles]

You’re basing yourself on the use of Matterbridge, they do their own thing internally but that’s not representative of the Matter protocol as a whole, it’s not enough to draw conclusions

@Terdious

If for the external_id you take:

I don’t think the approach you propose is compliant with the Matter standard, and I haven’t yet seen any other implementation in the Matter ecosystem operate that way.

That said, you’re right on one point: one could consider offering the user the option to attach a new device to an old one, provided that both have exactly the same features in the same order.

But that’s not always possible, because:

• A physical device can receive updates and expose new features as the protocol evolves.
• In the case of Matterbridge, the software itself can evolve and add features to devices that are already integrated.

I will nevertheless look into the matter further to see how Apple or Google handle this case. My goal remains to follow the Matter standard as rigorously as possible.

[pierre-gilles]

@Terdious I tested a matching approach (to replace devices) based on the pair unique_id + position, but the risk is really merging one device into another. I haven’t seen anything in the spec that guarantees this behavior.

As long as it remains just a matching for replacement, I’m less concerned. On the external_id side, we keep the current approach which is the official approach.

[mutmut]

@pierre-gilles

On the other hand, we could at most display a « No response » on the old one

It would be great to have the info live!

@pierre-gilles

Yes, the paired devices don’t disappear even if you remove them on the Matterbridge side, that’s how Matter works.

An idea by the way: what if we had a button that would decommission and automatically re-pair the device, do you think that would be doable?
That would allow refreshing the paired devices. It could be available only for Matterbridge, not necessarily for individual devices like yours currently (since I don’t think there’s any point).

[pierre-gilles]

@mutmut

One idea, by the way: what if we had a button that would decommission and automatically re-pair the device — do you think that would be doable?

Not really, because in this case there isn’t a unique identifier at that level.

(And I can hear you coming — no, « VendorID » and « ProductID » are not unique identifiers )

In the case of Matterbridge, the unique identifier is at the child device level that represents a device, so I can offer the user a matching at that level! I think it won’t work perfectly, but it’ll be better than nothing…

@pierre-gilles

I’d be curious to see what happens on another Matter controller — could you test the same behavior on iOS or on Google Home?

I’m taking this opportunity to follow up with you on that

[pierre-gilles]

Added a spinner during decommissioning:

[pierre-gilles]

Added a badge on disconnected nodes:

[mutmut]

@pierre-gilles

What I do in the code is list the interfaces available in Gladys (a bit like if you run an ifconfig on your machine), and if there is at least one ipv6 interface, I display “IPv6 interfaces are available on this machine ”.

and with a ping6, do you think that would work better for testing rather than checking the interface’s inet6?
When I disable ipv6 on the syno, I do see inet6 disappear from ifconfig on the syno (not in the Gladys docker terminal, I can’t check because there is no network command installed).

@pierre-gilles

In your case, that means there is still an ipv6 interface available, even when you disable ipv6, but hard to know what disabling ipv6 does on your syno!

So I really have things I no longer understand and that are beyond my docker/network skills.
So on my syno I activated IPv6 on the network:

my dockers (including Gladys) are in host and IPv6 seems inactive:

and yet matterbridge sees IPv6 and it’s the syno’s own IPv6 (normal since host)

@Terdious @pierre-gilles docker on PC/MAC or NAS?

[mutmut]

@pierre-gilles

@pierre-gilles

I would be curious to see what happens on another Matter controller, could you test the same behavior on iOS or on Google Home?

I’m taking the opportunity to follow up on that

You’re right!! (though I don’t have Google Home)

So I just tested on iOS :

• creation of a home in the Home app
• pairing with Matterbridge via QR code: ok
• automatic detection of Somfy devices and addition in the Home app in different rooms and creation of an open/close scene
• up/down tests: ok (I find the slider handling not great)
• scene test: ok
• disabling the Somfy plugin in matterbridge: ALL devices (thus saved) disappear from Home as well as the associated scene
• re-enabling the plugin: ALL Somfy devices reappear and are all placed in a single default room (garage) but the scene did not come back
• open/close test: ok
• removing the Somfy plugin in matterbridge: ALL devices (therefore saved) disappear from Home
• reinstalling the Somfy plugin (so new Endpoint): ALL Somfy devices reappear and are all placed in a single default room (garage)
• open/close test: OK

Interestingly, the matterbridge-somfy plugin « found » the old Endpoints and seems to match them with the new ones:

I decommission and add matterbridge in Gladys: the names keep the old Endpoints but it seems a sync happened because my test shutter (Salon PF) asks me again for a room to save even though I had set « home ». However the open/close doesn’t work.
I decommission again and add it back… well I try because it won’t let me anymore

[pierre-gilles]

@mutmut

and with a ping6, do you think that would work better for tests rather than checking the interface network inet6?
When I disable IPv6 on the Synology, I do see inet6 disappear when running ifconfig on the Synology (not in the Gladys docker terminal, I can’t check because no network command is installed).

I don’t use exactly ifconfig, I use the Node.js core module os:

OS | Node.js v25.1.0 Documentation

I do:

const interfaces = os.networkInterfaces()

Which returns something like this:

{
  lo: [
    {
      address: '127.0.0.1',
      netmask: '255.0.0.0',
      family: 'IPv4',
      mac: '00:00:00:00:00:00',
      internal: true,
      cidr: '127.0.0.1/8'
    },
    {
      address: '::1',
      netmask: 'ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff',
      family: 'IPv6',
      mac: '00:00:00:00:00:00',
      scopeid: 0,
      internal: true,
      cidr: '::1/128'
    }
  ],
  eth0: [
    {
      address: '192.168.1.108',
      netmask: '255.255.255.0',
      family: 'IPv4',
      mac: '01:02:03:0a:0b:0c',
      internal: false,
      cidr: '192.168.1.108/24'
    },
    {
      address: 'fe80::a00:27ff:fe4e:66a1',
      netmask: 'ffff:ffff:ffff:ffff::',
      family: 'IPv6',
      mac: '01:02:03:0a:0b:0c',
      scopeid: 1,
      internal: false,
      cidr: 'fe80::a00:27ff:fe4e:66a1/64'
    }
  ]
} 

Then I check if any « IPv6 » addresses are available

@mutmut

When I disable IPv6 on the Synology, I do see inet6 disappear when running ifconfig on the Synology (not in the Gladys docker terminal, I can’t check because no network command is installed).

Normally, if you no longer have any IPv6 interfaces, it should also disappear on the Gladys side.

If you want to see the result of the request on your side, you can open your browser inspector and select this request:

@mutmut

@Terdious @pierre-gilles docker on PC/MAC or NAS?

Not sure I understand the question? I develop on a Mac and my Gladys runs on a Beelink mini S12 Pro

@mutmut

So I just tested on iOS:

Thanks for testing!

@mutmut

• disabling the Somfy plugin in matterbridge: ALL devices (so they were saved) disappear from Home as well as the associated scene
• re-enabling the plugin: ALL Somfy devices reappear and are all placed in a single default room (garage) but the scene did not come back

Okay, I expected that — iOS doesn’t keep any record of devices, and therefore doesn’t do any old ↔ new matching, it just deletes everything. That’s brutal I think Also, for now on these platforms there is no history (no graphical view), so they don’t care much about legacy, which is not our case.

@mutmut

I decommission and add matterbridge in Gladys: the names keep the old Endpoint but it seems a sync happened because my test shutter (Living room PF) asks me again for a room to save even though I had set « home ». However open/close doesn’t work.

For info, I hadn’t pushed my improvements from this morning yet, so you tested the Saturday night version

I just pushed a new Docker build with automatic matching based on the « UNIQUE_ID + position » pair (imperfect solution I remind you, but « good enough »)

@mutmut

I decommission again and add again … well I try because it won’t anymore

Even so, you should still see it in the list under « settings », right? The decommissioning must not have worked.