I was hanging out at the Nashville Game Jam when I noticed several unrecognized notifications for websites pop up on my phone. Not something I’d seen before, I had to look into this interesting new (to me) thing. These turned out to be Bluetooth beacons configured with Eddystone URLS. On recent Android phones, the default Google software includes something called “Nearby” which, if Bluetooth and locations are enabled on your phone (which I guess they probably are for most), if it picks up the appropriate broadcast code, it will display a notification with an icon, a link and a short description. With a little work, I was able to get this working for my own needs and I will describe how.
I was already a little familiar with Bluetooth beacons from a locating project at a previous place of employment but this was a new thing on me. A Bluetooth beacon transmits (and potentially receives) specific data packets. There is a variant of this which is called an Eddystone URL which is a format which slightly condenses a URL in order to fit it into a data packet.
If you want to dip your toes into the water and you have a Raspberry Pi, you’re in luck. If you have Bluetooth (and the Pi 3 has this built in), you can make it behave as one of these beacons. I found excellent instructions here. This may work out-of-the-box for you but there are several pitfalls and trick that are not well documented. The page is also an excellent source if you are interested in familiarizing yourself with the Eddystone format and the Pi’s Bluetooth operations without getting into too much depth.
Google pre-verifies the web page: The Nearby app also does not retrieve the information from the web page directly but it is loaded within their network and forwarded to the Nearby app.
Google’s pre-verification is cached: If you make an error which means that Google will not pass your page to the Nearby app, once you have corrected it, it may not recheck the page for a long time. I have not managed to pin down exactly how long but I have seen *at least* 4-6 hours. There appears to be no way to force a re-check. This also applies if your page is working and you make changes.
The URL must be an https URL: Google decided for reasons that the URL must be an https url. It’s not well explained but I suspect that this is to prevent people with open WiFi hot-spots from directing people to websites and stealing information. https, in theory, at least ensures that people are connecting to the sites they believe they are.
The certificate must be valid: This seems like a no-brainer but it eliminates self-signed certificates, expired certificates and certificates that don’t represent the site. As an additional wrinkle, I was running with a certificate from StartSSL which several providers decided to revoke their CA status and my certificate chain became invalid, causing my URL to no longer function. Easily fixed by obtaining a certificate from a different provider but something to be aware of.
The page must have a title tag: Easy to miss when you’re doing some quick testing but if you don’t have a title tag, you won’t show up in Nearby.
Icons: The usual browser icon types seem to be supported. favicons or link tags work.
Pre-verification: You can pre-verify your page here. Note that this doesn’t seem to detect some error conditions such as a missing title tag and my unacceptable StartSSL certificate was verified fine but it is helpful.
Description: The description is, by default, taken from the text on the web page. I have not determined if there’s a way to specify the description in a different way. However, there is a meta description tag which is probably the answer to that question. I will be testing that.
Having succeeded with the Raspberry Pi, I wanted a more efficient version than a small computer running at 5V, 1A so I bought two small battery-powered beacons. More on those later.