[Documentation] Core Spec 1.3 (and earlier) are unclear as to when a device can expect a ScanNetworks request

[ivmarkov]

Documentation issues

I find the wording in section 11.9.7.1 ("ScanNetworks Command") unclear, specifically for the case when NON-concurrent commissioning flow is used (and indicated as such via the General Commissioning Cluster (0x0030), attribute 0x04 SupportsConcurrentConnection = false).

My interpretation of the non-concurrent commissioning flow is that - in layman's terms - it is designed specifically for devices which cannot maintain - simultaneously - the BLE connection over which the commissioning is initiated, as well as a Wifi (or Thread) connection which is the ultimate "operational network" once the ConnectNetwork cmd is carried over.

And here's the problem: if my device is currently having an active BLE connection, how am I supposed to even carry out a ScanNetworks request, given that this would require the device to tear-down the BLE session, stop the BT driver, start the Wifi driver and do the scan? Effectively killing the commissioning flow...

I think if ScanNetworks is not supposed to be send by the controller for non-concurrent commissioning, then probably the spec should be a tad more explicit about that....

Evidence from the field as to how various controllers behave:

• OK: Google controller - does not send ScanNetworks request for non-concurrent commissioning
• OK: Apple HomeKit - ditto - sends directly a ConnectNetwork command, just like Google. To which - the device of course answers with "yeah I did it" (even if it didn't) and then switches over to Wifi and only then it tries to connect (of course)
• NOT ok? Alexa - sends ScanNetworks even though the commissioning flow is explicitly non-concurrent (?)

There's also this interesting paragraph in the spec w.r.t. ScanNetworks and BUSY:
"
This command SHALL fail with a status code of BUSY if the server determines that it will fail to reli­ably send a response due to changes of networking interface configuration at runtime for the inter­face over which the command was invoked, or if it is currently unable to proceed with such an operation."
"

Not really sure if BUSY in that particular case means "busy right now, retry later" (most likely) or "no I'm not able to" (as I wish it was).
Unless I have a bug in my code, Alexa does not seem to react to a BUSY signal either - it just terminates the BLE connection with failure each time it receives one of busy/invalid-command/empty set of scanned networks/.

So is it really Alexa misbehaving (and the spec is in a need for extra-clarity therefore), or am I misinterpreting the spec, and the device should be capable of answering ScanNetworks request, even in non-concurrent flow (but then what's the point of non-concurrent commissioning flow in the first place?)

CC @Apollon77 @kedars @andy31415

Platform

No response

Anything else?

No response

[ivmarkov]

@bzbarsky-apple Sorry for pinging you here... but noticed you were active on similar issues like this one which seems related.

Also, another weirdness: the "auto commissioner" has a flag / configuration as to whether it should send a ScanNetworks request. This flag does not seem related - in any way - with the fact whether the commissioning flow is concurrent or not. Shouldn't this flag be always set to false for non-concurrent commissioning?

[bzbarsky-apple]

@ivmarkov Alexa is in fact using that flag, which as you note is buggy, so it gets buggy behavior.

That said, I have no idea how they expect to work with the non-concurrent commissioning situation. That's a question for @chrisdecenzo

I agree that the spec probably needs to be clearer here. @ivmarkov I assume you are not in a position to file spec issues?

[ivmarkov]

@ivmarkov Alexa is in fact using that flag, which as you note is buggy, so it gets buggy behavior.

Just to confirm: The fact that this flag is currently unrelated to whether the commissioning is non-concurrent or concurrent needs a fix, right?

I agree that the spec probably needs to be clearer here. @ivmarkov I assume you are not in a position to file spec issues?

I guess not. I'm not even an Adopter-Member of CSA-IOT (yet) so I guess I don't have access to the spec repo.

[chrisdecenzo]

I believe the SupportsConcurrentConnection feature is new in 1.3 and you are correct that the AutoCommissioner needs to bypass that command during commissioning when the feature is present - unless there is some way to drop the BLE connection and then resume it without causing the commissioning session to exit.

[ivmarkov]

I believe the SupportsConcurrentConnection feature is new in 1.3

It is not.
SupportsConcurrentConnection is also described in the 1.1 Core spec, and I'm quite sure, that it is there since the first ever 1.0 spec as well.

and you are correct that the AutoCommissioner needs to bypass that command during commissioning when the feature is present - unless there is some way to drop the BLE connection and then resume it without causing the commissioning session to exit.

If that were possible, that would mean you are having a concurrent connection, isn't it?

[bzbarsky-apple]

The fact that this flag is currently unrelated to whether the commissioning is non-concurrent or concurrent needs a fix, right?

Yes.

I guess not. I'm not even an Adopter-Member of CSA-IOT (yet) so I guess I don't have access to the spec repo.

Filed https://github.com/CHIP-Specifications/connectedhomeip-spec/issues/10438

[Apollon77]

And also https://github.com/CHIP-Specifications/connectedhomeip-spec/issues/10429

[ivmarkov]

Can't see any of these unfortunately (err 404).
Do I need to be a CSA-IOT member to get access?

[Apollon77]

Yes