Improve device name normalization for Bluetooth device matching

[latishab]

Currently, the device name normalization process in libdivecomputer has some limitations when matching Bluetooth device names to device descriptors:

1. Device descriptors use short names (e.g. "D5") while Bluetooth devices broadcast longer names with manufacturer prefix and serial numbers (e.g. "Suunto D5 12345678")

2. The find_matching_descriptor() function fails to match these longer names because it looks for exact matches with the product names in the descriptor list

3. The fallback string parsing in normalizeDeviceType() is basic and may not handle all manufacturer naming patterns correctly

Example cases:

• Suunto: "Suunto D5 12345678" should match descriptor "D5"
• Shearwater: "Petrel 2 1234" should match "Petrel 2"
• Mares: "Mares Genius 5678" should match "Genius"

Suggested improvements:

1. Add manufacturer-specific name parsing rules that understand common patterns:

   • Known manufacturer prefixes ("Suunto ", "Mares ", etc.)
   • Serial number patterns (trailing digits/hex)
   • Model variants (e.g. "2", "Air", "Pro")

2. Update the descriptor matching to:

   • Try exact matches first
   • Then try matching without manufacturer prefix
   • Then try matching the normalized name
   • Consider fuzzy matching for close matches

3. Add test cases for various real-world device name formats

This would improve the reliability of device identification, especially for Bluetooth devices where we have less control over the advertised names.

Related files:

• src/descriptor.c
• include/descriptor.h

[ArtCC]

Indeed, an example is with the Cressi Goa. In my case, its BLE device name is 2_466a. If you directly search for the descriptor, it returns an incorrect computer. In my case, in previous tests, I solved it by first selecting the brand and model of the computer, then using that data to scan with BLE and filter.

In the case of your library, the openBLEDevice function returns an error because it detects an incorrect computer.

I am not a C developer, and I find it difficult to understand the internal workings of the libdivecomputer library, but I would like to help in any way I can to make it work with Cressi dive computers.

[latishab]

Could you try to send me the logs shown on your console? I'll see what I can do too. Thanks for the help! It's quite hard to verify for all computer brands because I only have Suunto.

[ArtCC]

Could you try to send me the logs shown on your console? I'll see what I can do too. Thanks for the help! It's quite hard to verify for all computer brands because I only have Suunto.

Of course! At the moment, I’m not receiving many logs. I connect to my computer correctly, but as I mentioned, it doesn’t identify it properly.

ℹ️ INFO [17:28:04.841] [BLEManager.swift] Bluetooth is powered on
🔍 DEBUG [17:28:19.976] [DeviceConfiguration.swift] Attempting to open BLE device: 2_466a at address: 67A48076-99C4-8...
🔍 DEBUG [17:28:19.977] [StoredDevice.swift] No stored devices data found in UserDefaults
❌ ERROR [17:28:19.998] [DeviceConfiguration.swift] Failed to identify device: dc_status_t(rawValue: -1)
ℹ️ INFO [17:28:19.999] [BLEManager.swift] Successfully connected to 2_466a

In my case, I solved it as I mentioned, by filtering by brand, model, and BLE name.

- (NSDictionary<NSString *, NSString *> *)getDiveComputerForBrand:(NSString *)brand
                                                            model:(NSString *)model
                                                       deviceName:(NSString *)deviceName {
    dc_iterator_t *iterator = NULL;
    dc_status_t status = dc_descriptor_iterator(&iterator);

    if (status != DC_STATUS_SUCCESS) {
        NSLog(@"Error initializing the descriptor iterator.");

        return nil;
    }

    dc_descriptor_t *descriptor = NULL;

    while (dc_iterator_next(iterator, (void **)&descriptor) == DC_STATUS_SUCCESS) {
        const char *vendor = dc_descriptor_get_vendor(descriptor);
        const char *product = dc_descriptor_get_product(descriptor);

        if (vendor && product && [brand isEqualToString:@(vendor)] && [model isEqualToString:@(product)]) {
            if (dc_descriptor_filter(descriptor, DC_TRANSPORT_BLE, [deviceName UTF8String])) {
                unsigned int modelNumber = dc_descriptor_get_model(descriptor);

                dc_iterator_free(iterator);

                return @{
                    @"brand": @(vendor),
                    @"model": @(product),
                    @"modelNumber": [NSString stringWithFormat:@"%u", modelNumber]
                };
            }
        }
    }

    dc_iterator_free(iterator);

    return nil;
}

[latishab]

Thanks for the info! I have made a lot of changes on configuredc.c. Now it matches name using dc_descriptor_filter(). Could you try bluetooth-device-matching branch with your Cressi device?

Let me know if it works.

[ArtCC]

Thanks for the info! I have made a lot of changes on configuredc.c. Now it matches name using dc_descriptor_filter(). Could you try bluetooth-device-matching branch with your Cressi device?

Let me know if it works.

Of course!

In the function:

dc_status_t find_descriptor_by_name(dc_descriptor_t **out_descriptor, const char *name) {}

It correctly detects my Cressi Goa, but in the line:

if (product && strstr(name, product) != NULL) {}

It doesn't enter because, in Cressi devices, the name (2_466a) is not part of the product (Goa), so it returns:

return DC_STATUS_UNSUPPORTED;

I believe Jef Driesen mentioned this case to me, or I might be remembering it wrong. I think in this case, when vendor, product, and family are correct, the model is 2_ (model 2 = Goa).

[latishab]

Hmm, yeah I noticed that. I noticed how descriptor.c have these dc_match_name() and dc_match_prefix(). But I couldn't figure out how it couldn't find the exact match.

So I ended up surfing through subsurface's bluetooth discovery algorithm, and came up with the solution that there could be 3 ways to do it; match exact name, match substring, or match prefix just like your use case.

Can you try out the bluetooth-device-matching new update? Let me know if it works, and if something doesn't work in your use case, please update the find_descriptor_by_name algorithm a bit.

[ArtCC]

From what I see, it now correctly detects the Cressi Goa family and continues the process, reaching:

ℹ️ INFO [11:02:10.419] [BLEManager.swift] Successfully connected to 2_466a  
🔍 DEBUG [11:02:12.481] [DeviceConfiguration.swift] Attempting to open BLE device: 2_466a at address: 67A48076-99C4-81F9-F...  
🔍 DEBUG [11:02:12.482] [StoredDevice.swift] No stored devices data found in UserDefaults  

In the function:

dc_status_t open_ble_device(device_data_t *data, const char *devaddr, dc_family_t family, unsigned int model) {}

rc = find_descriptor_by_model(&descriptor, family, model);

It's correct; I receive:

(lldb) print family  
(dc_family_t) DC_FAMILY_CRESSI_GOA  

But in:

if (!connectToBLEDevice(io, devaddr)) {}

It seems to get stuck at:

success = [manager discoverServices];

I'm looking to see if I can find anything else.

[ArtCC]

From what I see, it gets stuck in the loop and doesn’t search for the services.

@objc(discoverServices)
    public func discoverServices() -> Bool {
        guard let peripheral = self.peripheral else { return false }
        peripheral.discoverServices(nil)
        while writeCharacteristic == nil || notifyCharacteristic == nil {
            RunLoop.current.run(until: Date(timeIntervalSinceNow: 0.05))
        }
        
        return writeCharacteristic != nil && notifyCharacteristic != nil
    }

[latishab]

Hmm, the problem is, it works well in my side, could the problem is the BLEManager didn't detect your Cressi's services? Because I have put all the possible services in DeviceConfiguration based on Subsurface's qt-ble.cpp.

[ArtCC]

A question, do we need to do something before?:

DeviceConfiguration.openBLEDevice(name: deviceName, deviceAddress: bleAddress)

In this case, I receive that it's not fully connected. I notice a 1-second delay, but it might not be enough to proceed with sending messages:

API MISUSE: <CBPeripheral: 0x303dc8340, identifier = 67A48076-99C4-81F9-F3B0-74C121A15E6D, name = 2_466a, mtu = 0, state = connecting> can only accept commands while in the connected state