Skip to content
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

Inconsistent behaviour between BLE and SoftAP #24

Closed
mk-prins opened this issue Mar 18, 2021 · 4 comments
Closed

Inconsistent behaviour between BLE and SoftAP #24

mk-prins opened this issue Mar 18, 2021 · 4 comments

Comments

@mk-prins
Copy link

When creating an ESPDevice using ESPProvisionManager.shared.createESPDevice when using softap as the transport protocol, an ESPDevice device instance is successfully created. However when using ble as the transport protocol it first tries to connect to the device and if that connection fails it will not return the ESPDevice instance. Is there a specific reason for trying to connect to the device in the case of ble?

To give some context; My use-case requires me to create an ESPDevice instance before the device is connected to any power source and therefore not available. Now if I were to only have to create an ESPDevice manually this wouldn't be too much of a problem. However my use-case requires me to create the ESPDevices using a QR code. The scanQRCode method eventually makes use of the createESPDevice method to create and return the ESPDevice instance, causing me to run into the same problem.

@vikas-chandra-mnnit
Copy link
Contributor

Hi @mk-prins, In case of BLE, SDK does not connect with the device. Whenever ESPProvisionManager.shared.createESPDevice is called, it actually scan for available BLE device with the name given in parameter. ESPDevice then keep the instance of CBPeripheral in order to connect and make communication using other APIs. There are particular two reason for using this flow:

  1. Keeping BLE scan and connection as part of separate APIs.
  2. Making sure BLE device is available when ESPDevice.connect is called and thus reducing scope for failure.

@mk-prins
Copy link
Author

mk-prins commented Mar 25, 2021

@vikas-chandra-mnnit Thanks for the explanation. I do think the ability to create an ESPDevice instance without initially having the Peripheral available would be nice to have. If i'm not mistaken this is actually already the case in the Android version of this SDK. At least when using the createESPDevice method.

A somewhat unrelated question; If there happen to be two EspDevices with the same name, transport and security parameters and only have the pop be different. It will probably find both devices and essentially select the first in the list, ignoring the specified pop value. Is this assumption correct (for both the iOS and Android SDK)?

@vikas-chandra-mnnit
Copy link
Contributor

@mk-prins

  • Yes for Android flow is little different in terms of create ESPDevice for BLE. However connect will not work in Android as it also need Bluetooth peripheral internally. For your use case in iOS I can suggest that you try to add new method in ESPProvisionManager class using extension.
  • Yes this assumption is true in case of BLE because we match the peripheral name with the ESPDevice name. So two instance of ESPDevice can refer to the same peripheral or physical device.

@shahpiyushv
Copy link
Collaborator

Closing this issue since appropriate solution has been provided. Please fell free to reopen/file new issues if required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants