Server ignores SupportsConcurrentConnection=false

[jan-xyz]

Expected Behavior

When a device reports that it doesn't support concurrent connections (vie SupportsConcurrentConnection) then the matter server does not try to establish a thread connection while BLE is active

Actual Behavior

When a device reports that it doesn't support concurrent connections (vie SupportsConcurrentConnection) then the matter server still tries to establish a thread connection while BLE is active and calls ScanNetworks.

How to Reproduce

1. flash an ESP32H2 with the light_thread example from the rs-matter-embassy project
2. try to commission the device

Additional Information

I worked with the maintainer to figure out the problem, and more information can be found in this GitHub issue: sysgrok/rs-matter-embassy#13 (comment)

[Apollon77]

That's an interesting one, and likely not to be seen with "real" devices because from current knowledge the matter SDK itself does not use this (no clue if it is really implemented to have devices with "no concurrent connections". Are other controllers correctly support this?

[jan-xyz]

Yes, Apple TV and HomePod have no problems with it

[ivmarkov]

That's an interesting one, and likely not to be seen with "real" devices because from current knowledge the matter SDK itself does not use this (no clue if it is really implemented to have devices with "no concurrent connections". Are other controllers correctly support this?

The Matter SDK should (and im pretty sure it does) somehow use it if it wants to pass the TCK tests, because non-concurrent commissioning is part of the Matter Core Spec since 1.0.

Also, both Google and Apple implement this correctly, as @jan-xyz mentioned and they do use the Mattter C++ codebase. It is Alexa and HA which are non-compliant.

My suspicion is that this is some sort of conf setting you need to enable. I'll try to dig up again in the Matter C++ codebase where this is happening.

[ivmarkov]

W.r.t. the controller (which is what we are discussing here), I see this in the code.

Weirdly, I never see such an attribute read coming from HA (Google and Apple do this).
In fact, I don't see a read for all the other attributes enumerated in this method either.

It is almost as if DeviceCommissioner::ContinueReadingCommissioningInfo is not even called - for whatever reason.

I can dig up a bit further next week, after Monday.

As for the device side, there is a conf setting called CHIP_DEVICE_CONFIG_SUPPORTS_CONCURRENT_CONNECTION and you can compile the C++ SDK either with, or without concurrent connections' support, depending on the caps of your device. The code is littered with #ifdefs checking this config.

[Apollon77]

In fact Apple and Google usually do not scan for networks at all - at least not for thread (for WiFi I would need to check). They just push the details. So with this it does not matter :-). Amazon for example should also not work because they scan for networks too.

I would also not really consider the matter sdk „controller code base“ as „used by default“. In my experience controller logics are always implemented custom by the ecosystems. The controller logic in chip sdk is mainly used by Chiptool and for testing and by the python layer.

And as said above: till now there are basically no real devices out there that use this. So it is a high chance that because of this these issues appear.

So yes the issue here is right to have because basically not compliant. I just wanted to tell about the reasons.

So if the rs-matter variant used here would allow a concurrent flow then this would be the best choice to avoid such issues in a wider scope.

[ivmarkov]

In fact Apple and Google usually do not scan for networks at all - at least not for thread (for WiFi I would need to check). They just push the details. So with this it does not matter :-).

Maybe. Or maybe not. All I can say again, is that Apple & Google at least do query the "Clusters::GeneralCommissioning::SupportsConcurrentConnection" attribute value, while HA (and Alexa) don't even bother. This:

Weirdly, I never see such an attribute read coming from HA (Google and Apple do this).
In fact, I don't see a read for all the other attributes enumerated in this method either.
It is almost as if DeviceCommissioner::ContinueReadingCommissioningInfo is not even called - for whatever reason.

Amazon for example should also not work because they scan for networks too.

Yes, it doesn't either as I mentioned in the rs-matter-embassy thread.
Here's the relevant issue. It might help you figure out how to fix it in HA. (I need to re-read my analysis in there again as that was ~ 1y ago.)

But the fact that Alexa is buggy does not make the bugginess "normal". I think Boris from Apple was pretty explicit about that.

I would also not really consider the matter sdk „controller code base“ as „used by default“. In my experience controller logics are always implemented custom by the ecosystems. The controller logic in chip sdk is mainly used by Chiptool and for testing and by the python layer.

Can't comment as I've never seen the controller logic of Google/Apple/Alexa. :)

So if the rs-matter variant used here would allow a concurrent flow then this would be the best choice to avoid such issues in a wider scope.

rs-matter does support either concurrent or non-concurrent flow. It is not about rs-matter at all.

It is all about the device hardware itself (the MicroController Unit) or the network drivers on top of it that might not allow concurrent workflow (or rather, Thread+BLE or Wifi+BLE) "co-existence".

Or even if they allow it, you might not want it. Bringing up Wifi and BLE means gobs of RAM. These devices typically have between 256KB to 400KB SRAM max (and about a meg of flash to fit your device code, but that's another story), so when you have both the BLE Controller + Host impl, and then Wifi impl with wpa_supplicant running (not to mention the IP stack impl), you don't have that much RAM left for other stuff. As in, rs-matter itself and the device "app" logic (dealing with pins, running motors and whatnot).

[Apollon77]

All fine and valid. It clearly is a bug ... I also took the chance to just add full support for Non-Concurrent commissioning to matter.js :-) - and also optimized some more around scanning/connecting. matter-js/matter#2185

[ivmarkov]

All fine and valid. It clearly is a bug ...

I'll try to look at the HA Matter controller codebase later this week (if you don't beat me to it), and figure out what is necessary to fix so that it does support non-concurrent comm. But if you use the C++ SDK built-in controller, chances are it is indeed that buggy flag.