Issue using 128 bit UUID about unity-android-bluetooth-low-energy HOT 9 CLOSED

Hey @DucampGaspard

You didn't miss anything, this is a mistake on my part! In the SubscribeToCharacteristic class there's a check to see if a UUID is a short 4-bit part of the first 8-bits UUID, since most BLE services and characteristics only differ in the that part (where 0000[unique 4-bit ID]-0000-1000-8000-00805f9b34fb will remain the same for most services and characteristics).

So I've added a _customGatt field to most commands that interact with services and characteristics to see if it's a custom GATT UUID (128-bit) or short UUID (4-bit). At the Start() it checks if the _customGatt field is true or not, but this field is not set in the constructor.

I'll roll out a fix in around an hour or so!

from unity-android-bluetooth-low-energy.

If you're able to pull the new version of development ( #10 ) then the issue should be fixed if you pass true as the last argument if you're using a 128-bit UUID instead of an 4-bit UUID. Let me know if this works for you, if so I'll roll out the fix into master.

from unity-android-bluetooth-low-energy.

Thanks a lot, it works perfectly now ! 😊

Regarding the subscription to multiple characteristics, it seems that I receive notifications only for the first one, e.g. :

• the battery info if I do :

BleManager.Instance.QueueCommand(new SubscribeToCharacteristic(_deviceUuid, UUID_BATTERY_SERVICE.Get8BitUuid(), UUID_CHARACTERISTIC_BATTERY_LEVEL.Get8BitUuid());

BleManager.Instance.QueueCommand(new SubscribeToCharacteristic(_deviceUuid, UUID_PROCESSING_SERVICE, UUID_CHARACTERISTIC_PROCESSING, true));

• the result of the processing (an integer) if I first subscribe to this characteristic.

Can we have concurrent subscriptions and notifications, or just one at the time ?

from unity-android-bluetooth-low-energy.

Interesting, from what I see there shouldn't be a reason why 2 concurrent subscriptions shouldn't work. There are 2 constructors for the SubscribeToCharacteristic class, one where you can also add a method that needs to execute when the Characteristic updates it's value. Could you try that one with both? Pass in a simple lambda like

(x) => Debug.Log("Battery" + x.Length) for both methods to see if they're updating.

I'll also setup a local BLE server with two subscribe Characteristics to see if I can reproduce the issue.

from unity-android-bluetooth-low-energy.

Alright, so I found a wrong check inside the CommandReceived method of SubscribeToCharacteristic, perhaps this should fix the issue that you were having. It has been pulled in to development ( #12 )

from unity-android-bluetooth-low-energy.

Regarding this function I think there is an issue as well line 59 (and 68) where you check for :

string.Equals(obj.Service, DeviceAddress) &&

instead of

string.Equals(obj.Service, Service) &&

Nevertheless, and with this changed, I still can't manage to get both messages simultaneously.

from unity-android-bluetooth-low-energy.

Haha, must have written this code when sleep deprived or something. This afternoon I'll have a fix for you, I'll have access to the BLE server by then.

from unity-android-bluetooth-low-energy.

Hahaha no problem and thank you for your reactivity !

I have another question regarding the BleObject.GetByteMessage() function, at the moment it's defined as follows :

public byte[] GetByteMessage() => Convert.FromBase64String(command);

Shouldn't we convert the base64_message attribute of the received message ? For example using something like :

#region Message
public string Message => base64_message;
[SerializeField]
private string base64_message = string.Empty;
#endregion

public byte[] GetByteMessage() => Convert.FromBase64String(base64_message);

from unity-android-bluetooth-low-energy.

Yeah, seems like when I rewrote the project I forgot to add the base64message field, since that is given by received JSON.
Good catch!

from unity-android-bluetooth-low-energy.