Suggestion to change the DFU name to include part of mac..

I just ran into a funny problem.
I need to upgrade 23 MDBT42Q modules to the latest FW, and since I have already packaged them I have no other option than to use DFU, and I use iOS...
So since all the modules have the same name, iOS remembers the mac, so for each device I have to go into settings of iOS and turn of bluetooth, and then activate it. Or the app will try and talk to the last devices mac adress as it caches this...

Having the module present itself with a name that includes part of the mac would solve this.

I think it's possible that some code actually expects the name DfuTarg so it could be a problematic one to change. Internally the code I use for flashing definitely does.

Which application are you using to do the flashing on iOS?

I know it's frustrating but on Android you wouldn't have the issue. £50 on an Android tablet would fix it for you.

Also it is possible to use https://github.com/thegecko/web-bluetooth-dfu which is a Node.js application to flash from a PC (Mac or Linux - Raspberry Pi works too) - so you could set up something like a Raspberry Pi to do the whole flashing process automatically whenever a device named DfuTarg is found

The web dfu looks very interesting, will have a look at that.

I was a bit quick with my post, as it turns out Nordic has done something "out of the ordinary" with the app, you swipe down to refresh the list it manages to clear the cached data and shows the new device and new device names. This is something we have had issues with in other apps and with other developers. The same problem happens when a device change its name, the old name is shown for a long time in iOS as it is in the cache.

It's an odd one - It's the first I heard of that.

I know there are issues with iOS if a Bluetooth device changes its services, but Nordic side-steps that by adding one (or removing one?) from the device MAC address when entering DFU.

The same problem happens when a device change its name, the old name is shown for a long time in iOS as it is in the cache.

That's different problem. It can be understandable that iOS caches information for same mac address (name, available services).

Caching by name (even when mac address is different) like you described in first post is completely unreasonable because you can have many devices with same name (two pieces of same thing - fitness tracker, watch, thermometer,...). If iOS really does that then well, seem quite unlikely, but OK, but still it is not the same issue at all.

It's fine when you have several units with the same name, they have different mac addresses, like fitness devices etc etc. For normal use this is not a problem, the app will talk to the mac and not the name etc etc.

The problem with the cache is during development and programming, if a device changes it name from the default to the production name iOS then shows the old name instead of the new name as the cache is not updated, after some time it does change over.

The same kind of problem happens when starting new units that have the same name, as I did yesterday where all the units show up as DFUtag, but with new mac addresses one after another, within iOS it self there is no way to tell them apart and apps like LightBlue struggles with this as they try to connect by getting the mac from the cache based on the name.

Now Nordic has managed to go around this byt doing a refresh, not stop/start of scanner or stop/start of the app, but swiping down, this makes the new device show up at the top and the icon is in a different colour the the last unit.
Using for example the LightBlue app this is a problem, I have had units that come from the supplier with the same name for all modules, when I am done with one unit and are moving on to the next it is a hassle to get iOS to go for the new module instead of the previous.

Somehow Nordic has found a way around this, so will have a look if they published the code for the DFU app and I can show that to our iOS developers on how to force iOS to do a refresh or how to go around the cache issue.

Changing services have the same issues, it's cached and the cache has to expire to read the new data. To "force" this a restart of the bluetooth helps, but not always. Can be a pain during development as you don't see whats there but what was there... :-)

It's fine when you have several units with the same name, they have different mac addresses, like fitness devices etc etc. For normal use this is not a problem, the app will talk to the mac and not the name etc etc.

The problem with the cache is during development and programming, if a device changes it name from the default to the production name iOS then shows the old name instead of the new name as the cache is not updated, after some time it does change over.

The same kind of problem happens when starting new units that have the same name, as I did yesterday where all the units show up as DFUtag, but with new mac addresses one after another, within iOS it self there is no way to tell them apart and apps like LightBlue struggles with this as they try to connect by getting the mac from the cache based on the name.

Well, those are two separate unrelated situations and issues. 1. Device with same MAC changing its properties (like name, services). 2. two different devices with different MACs but with same name. Not sure why you mix them together and call them to be same problem.

issue #1 is some per device cache, issue #2 looks like some UI dialog or application issue that apps cannot enumerate over all known devices and pick the right one. Maybe for second issue this could help? https://www.businessinsider.com/how-to-change-bluetooth-name-on-iphone

as for issue #1 nordic solves it by changing mac address when device is switched to DFU mode, the MAC for DfuTarg device changes in last digit so it acts as different device.

Somehow Nordic has found a way around this, so will have a look if they published the code for the DFU app and I can show that to our iOS developers on how to force iOS to do a refresh or how to go around the cache issue.

https://github.com/NordicSemiconductor/IOS-nRF-Connect (but no source?)

As I said in my first reply, this is not an issue any more as the DFU app has found a way to work around how iOS it self and other iOS apps normally shows devices, as long as you operate the app the correct way.
I was just a bit to quick to post a suggestion based on my previous experience, not having used the nRF-Connect app to any extent before.