PIN code would be doable, but a lot more work than NFC 
.
Maybe later on we’ll add a feature to enable the DFU updates remotely, but for now I think I’ll compile a package which enters connectable mode after NFC or button press.
I’ll have the update done by Friday.
Let’s continue the discussion about connectability here.
What are you using to change the device name?
do you need beta testers? I’m available 
With respect to my remark on the MAC address… Either you utilize the URL as-is and get to the ruu.vi site, which will overlook the additional piece of data (to the extent the client goes in any case). Or on the other hand you will need to process the data yourself, which implies you need to recover the data from the promoted bundle and for some odd reason the parcel additionally contains the MAC address of the sender… so regardless I don’t perceive what “use case” you had at the top of the priority list while including that ID byte. Kindly do illuminate me.
The ID byte was to help users to differentiate the tags back when we had only the URL mode with no Android app. Google does no longer show the Eddystone URLs to visitors, so the URL mode is deprecated.
On new raw data format the MAC address is present in data payload for the iOS users: iOS does not let the userland see the MAC address, but rather provides the applications with obfuscated UUID of tag.
