Has 1.7.5 broken 16 bit service UUID's on iOS?

[ml-imas]

Hi,

The fixes in #1021 for #905 and #1014 seem to have broken 16 bit service UUID's like 180a (Device Information Service). Calling ble.read with "180a" as service_uuid used to work fine, but now results in an error saying

Malformed UUID: 180a

This looks like l. 1104 in BLECentralPlugin.m , and it matches with the change from using CBUUID's UUIDWithString to NSUUID's initWithUUIDString .

Using the full 128 bit UUID (like in UUIDHelper.java) doesn't work. The UUID is no longer rejected but we end up with

Could not find service with UUID 0000180A-[...]

instead; it doesn't seem to match the services reported by the device.

[gwhenne]

We're having the same issue with 1.7.5 - it was working fine in 1.7.4. Here is what is showing on the Safari remote console:

[sam-higgs]

Also experiencing this issue with versions 1.7.5 and 1.7.6.

[peitschie]

Can confirm the regression. Will get out a fix shortly.

[peitschie]

A fix has been released in 1.7.7 (and I've added some more test cases to cover this!)

Thanks for the quick reports!

[gwhenne]

Thank you! The main problem is solved.

The message "Malformed UUID: 180F" is gone, but ble.startNotification still shows the second message, "The attribute could not be found."
Something is still wrong.
Although it looks connected and works okay, ble.isConnected fails. But once the device turns off, the app receives the "Peripheral disconnected" message.

[peitschie]

@gwhenne is this issue on iOS or Android?
Are you able to raise a new issue with some more detail, and potentially confirm if the behaviour was different with a previous version of the plugin?

What you are describing sounds unrelated to this particular regression.

[gwhenne]

Thank you. Yes, it does appear to be a different problem. A new issue has been opened here:

#1035