-
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?)
You are reading a single comment by @JohanWinas and its replies.
Click here to read the full conversation.
fanoush
@JohanWinas
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... :-)