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

Plugin.BLE - Issue Regarding ambiguous connection #836

Open
DhairyaOza005 opened this issue Apr 5, 2024 · 2 comments
Open

Plugin.BLE - Issue Regarding ambiguous connection #836

DhairyaOza005 opened this issue Apr 5, 2024 · 2 comments

Comments

@DhairyaOza005
Copy link

DhairyaOza005 commented Apr 5, 2024

Information

So i have included Plugin.BLE as Nuget package for BLE Connection and retrieving data from a device from it. Device has wait , enabled , disabled mode and BLE can be connected when enabled mode is on

Expected behavior vs Actual behavior

Now what is happening is the particular device even when its on Wait Mode ( Its configuration of turning ble things on ) Plugin.ble can connect with it and Device_connected event is raised and but as we know the device is not connected so connetion_lost event is raised after like 5-6 seconds which is fair but how come device is connecting first .....it should give connection_error event raised.

Code Snippet

        public async Task ConnectBleDevice(ScannedDeviceInfo selectedDevice)
        {
        try
        {
            TimeSpan timeout = TimeSpan.FromSeconds(10);

            await _bleAdapter.StopScanningForDevicesAsync();

            // Create a CancellationTokenSource with the specified timeout
            using (var cancellationTokenSource = new CancellationTokenSource(timeout))
            {
                await _bleAdapter.ConnectToDeviceAsync(selectedDevice.BleDevice, new ConnectParameters(false, false), cancellationTokenSource.Token);
            }

            _bleDevice = selectedDevice.BleDevice;
            
        return true;
        }
        catch (TaskCanceledException)
        {
            await DisconnectDevice();
            await Shell.Current.DisplayAlert("Alert", "Device Communication error", "OK");
            await Shell.Current.GoToAsync("../..");
        }
        catch (DeviceConnectionException ex)
        {
            await DisconnectDevice();
            await Shell.Current.DisplayAlert("Alert", "Device Communication error", "OK");
            await Shell.Current.GoToAsync("../..");
        } 
    return false;
}

Crashlog

Not causes App crash but ambiguous connection,connection-termination happens

Issue

Now what should i add here to make sure that device is connected when its in only enabled mode and not in wait mode.
Thanks for help

@smsissuechecker
Copy link

Hi @DhairyaOza005,

I'm the friendly issue checker.
It seems like (87.50 %) you haven't used our issue template 😢 I think it is very frustrating for the repository owners, if you ignore them.

If you think it's fine to make an exception, just ignore this message.
But if you think it was a mistake to delete the template, please close the issue and create a new one.

Thanks!

@axa88
Copy link

axa88 commented May 8, 2024

It appears to me if you receive the DeviceConnected event, then the connection is complete and you will not receive a DeviceConnectionException as it did not fail from the perspective to the central device.
From this point if there is a problem with the connection, it will be reflected as a DeviceConnectionLost event.

Frankly I find myself not even using the DeviceConnectionError as simply NOT receiving a DeviceConnected event is suffice in telling me the connection failed. In all other cases the DeviceConnected event is returned and any unexpected disconnection is detected by the DeviceConnectionLost event.

Regardless, I feel this adhoc use of pseudorandom events demonstrates a poor design.
A single ConnectionInfo event passing a single ConnectingIfoEventArgs should have been used.

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