You probably need to add a selection event for savedList ListView, to retrieve the TinyDB value for the bib.
Also, maybe bib should be the value, and device the tag?
Also, don't calll a selection a list.
My take on it, with two TinyDBs for back and forth lookup:
BLE_Reader (1).aia (200.6 KB)
Of course, I can't test.
P.S. I left out convenience factors for the bib number assignment phase, tracking high water mark for bib numbers and omitting already assigned devices for new device entry.
Thanks, yes it is working - but I need the second list (savedlist) to also show the saved bib no. at the moment it only show teh saved name.
Ive replaced the get Tags with Get Entries?
So this screen will be a athelte registration screen.
The next step is to create a second screen where the actual timing will be done with a start/stop timer, and once started it will scan for saved suernames, and once detected, it will write to a list again, with the bib no abd timestamp.
The ListView component can be set up to show major and minor element parts in different font sizes.
Alternatively, you could loop through the tinydb tags/value pairs and join them with \n separators for a combined ListView Elements list.
So the first part pretty much do what it needs to do - save the device MAC and Name and Bib no to the TinyDB
NOw, I have a second screen, that start scan again, this time it should check the recieved device (could be the MAC or name or both?) against the DB, and if found, then add to the list, with a timestamp.
I have no clue how to do that 
Attached my AIA
BLE_Reader_1.aia (203.1 KB)
Here is a cleaner way to populate a ListView from a TinyDB (written before I read your last post)
BLE_Reader (2).aia (201.6 KB)
Regarding timestamp collection, you need yet another TinyDB instance and NameSpace, with bib number as tag and timestamp as value. You would need to capture the time of the start of the race too, to translate arrival timestamps into minutes and seconds.
Pull in the Clock component from Sensors and use SystemTime (milliseconds from 1970) for your stored values. They are database friendly numbers and math-friendly too. The Clock component has lots of formatting blocks.
Before I jump into your new code, there is something nagging at me I would like you to resolve with actual experiment.
The Device List - Does it shrink and grow as devices leave and return, or is it cached, available to speed up connection attempts?
Also, where will be the user of the app when the race starts?
- At the finish line, away from all the racers, or
- In their midst, awash in Devices?
Might need a bit of record keeping to detect runners falling off the Device list at the start of the race, then reappearing later for the finish? Perhaps count how many reappearances on the Device list, for laps around the track, if circular?
This will only show arrivals of new devices, as detected during a race.
Times are logged as HH:MM:SS values, along with bib numbers (if available, otherwise devices)
I copied over from Screen1 the TinyDB instance that stores the bib number values for device tags.
BLE_Reader_1.aia (206.1 KB)
All the action happens in the Device Found event.
I am unable to test this.
P.S. I used the device address as the default for the TinyDB bib number lookup, just to prove I was capturing new arrivals.
You might want to restrict logging to the Elements only to devices that return a bib number, using a different (not found) default and an enclosing if/then test on the TinyDB value.
Otherwise, the app would record arrivals of random people in the finish line crowd.
P.P.S. You could also add yet another TinyDB Namespace, mapping bib numbers to people names. That's more user friendly.
I just got a good look at your device list in a prior post.
The devices end in a negative two digit number.
I suspect that is the signal strength of the device in decibels.
That number might change as the device approaches and departs, causing the app to regard it as different devices.
To handle that possibility, split each device at '-' and just take item 1 of the resulting list.
Do that in both screens, where you fill the TinyDBs and where you do the lookups.
I have added signal strength omission to the app, but am unable to download .aia files now.
Windows 10 MS Defender just decided that the aia files have a virus.
So here are block images.
To work around Microsoft Defender's sudden allergy to the BLE extension, here are draggable png downloads of my latest changes, thanks to the AI2Helper browser addon.
Screen1:
RaceTimer blocks:
(I am awash in technical debt.)
Good morning, Thanks, this is realy really helpfull. Will work through this today.
I am really grateful!
I dont have the AI2Helper, so will just redo all 
The changes make sense, end does help. SOmehow the timer dont run. (Fixed - just add Timer enabled)
So when tested, screen 2 should list should only show the devices saved in the TinyDB saved in screen 1
Also, by using the MAC adress, it might not work - and have to use only the Advertiser names. Everytime a participant stop and start his brodcast, the MAC adress change. But the Device bluetooth name stays the same. SO ive changed the Devicelist to AdvertiserNames
Attached th AIA
BLE_Reader_3.aia (206.8 KB)
Here's an Advertiser Name based version, allowing only registered Advertisers to be logged.
Hope the Advertiser names are unique and available for all runners!
BLE_Reader_3 (1).aia (207.5 KB)
The MINUS function subtracts a list from another, like in set theory.
I had it in one of my list block collections.
I also expanded registration validation to cover all cases .
Tested quickly, but am at a race currently. working good. The next challenge for me is to now on page 2 to scan all the time when started, and not just a scan period. Also monitor the selected devices, and if they are not in the list anymore, it should be available to log their time again once they are in range. This is basically to be able to scan bibs doing laps.
The Bluetooth name can be the Bib number. That will reduce the amount of interaction required between apps. If there was only one athlete BLE might be good enough for the task 
Another issue you have to solve is keeping the Apps on for a prolonged time (not to mention potential weather issues).
I think ultimately you are going to have to ditch the smartphones and apps and look into a sensors + mini computer solution. Sorry for the doom and gloom.
Scan in the clock timer.
Keep lists of runner arrivals, by runner bib.
Here are changes to record lap times by bib.
(I leave it to you to figure out how to keep those Device Found events triggering with incoming advertiser names, probably by adding a Clock Timer for that)
BLE_Reader_3.aia (207.9 KB)
(Changes made in the RaceTimer Screen)
Yet another TinyDB instance, mapping bib numbers into lists of arrival times
Clearing the arrival times db at race start
Logging arrivals during the race and loading the ListView, one Element per bib:
Good morning, thanks for all the help!
I did not had any luck with teh testing - somehow when I stop scanning on Page 1 after assigning the bib no's, and switch to Page 2 for timekeeping, the assigned bib no's dont pick up. Only when I keep scanning on page 1, then page 2 work. and dont know how the Page 2 read the Page 1 DB?
Also, when on page 2, the timing page, when on I simulate the race, when the bluetooth is out of range and within range again, it does not log the new time.