-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Documentation] Core Spec 1.3 (and earlier) are unclear as to when a device can expect a ScanNetworks
request
#35506
Comments
@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 |
@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? |
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 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. |
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. |
It is not.
If that were possible, that would mean you are having a concurrent connection, isn't it? |
Yes.
Filed https://github.com/CHIP-Specifications/connectedhomeip-spec/issues/10438 |
Can't see any of these unfortunately (err 404). |
Yes |
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:
ScanNetworks
request for non-concurrent commissioningConnectNetwork
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)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 reliably send a response due to changes of networking interface configuration at runtime for the interface 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
The text was updated successfully, but these errors were encountered: