New Ruuvitag Sensor Beacon

There’s an interesting new sensor beacon at Ruuvitag.  It provides temperature, humidity, air pressure and acceleration and will be coming soon to kickstarter.

ruuvi

At first sight it doesn’t provide that much more than standard sensor beacons. However, the differentiating factor is that this beacon is open source.

This means that the beacon is not just configurable but also fully user-reprogrammable. For example, you can run proprietary protocols and form mesh networks. The open hardware and software design to allows adaptation for your proprietary solution. Open hardware and software also reduces the risk should you base your system on it and Ruuvitag (the company) no longer support it.

How Does Sensoro Support Eddystone-EID?

We stock Sensoro beacons that support Eddystone EID.

Sensoro supports two ways to get Eddystone EID. The first adds Eddystone EID into the Sensoro Config App and cloud offering while the second reconfigures the beacon firmware completely to implement full Eddystone as per the Eddystone GATT spec.

For the Sensoro compatible EID mode, as of the time of writing this, you will only be able to configure EID using the Android version of the Config app.

For the fully Eddystone mode, once converted to the Eddystone GATT firmware the beacon doesn’t support any Sensoro features and the beacon becomes a generic Eddystone beacon, with no iBeacon support, that has to be managed using generic Service/Characteristic editing apps. It’s a one way process that can’t be undone.

For either method, the beacon needs to be running firmware 4.3 or later. Update tips, access to the upgrade app and .hex firmware files are available to our customers via the BeaconZone Sensoro technical area.

If you enable the switch to Eddystone GATT firmware, you will then need to configure using a generic Service/Characteristic editing app such as LightBlue on iOS and Nordic nRF Connect on Android. The Nordic nRF Connect app is especially useful as it knows about Eddystone GATT and displays useful information against the respective Eddystone GATT Service Characteristics.

 

Eddystone-EID and Eddystone Configuration GATT Service Practicalities

Yesterday, Google announced Eddystone-EID, a more secure advertising frame (data) that provides for beacons that can’t be spoofed and hence can exchange information more securely and privately.

While beacon spoofing isn’t yet a problem, it’s great that Google is pre-empting a problem that’s bound to become more prevalent as beacons are used as IoT devices. Eddystone-EID is an alternative to UUID rolling as provided by a few platform providers such as Estimote.

From what we understand, Eddystone-EID relies on a “resolution service such as Proximity Beacon API” that implies it currently needs a working network connection and http – that many indoor scenarios lack. It will be interesting to see how reliable and quick this will be. A key metric for many of our clients is beacon detection time and anything that slows this down or makes it less reliable will be impractical. Let’s hope Google has had thoughts on how to make the ‘resolution service’ local to the phone. At the moment, the implementation seems to require cloud resolution of ephemeral ids. However, the research paper, on which Eddystone-EID is based, does mention an Extension: Offline Resolution by Non-Owners.

Google also announced a new Eddystone Configuration GATT Service . At the moment, each beacon manufacturer needs to write an app that allows their beacons to be configured. A common Configuration GATT Service means one app could be used to configure all beacons. However, things won’t be so simple.

It’s our expectation that it will take a long time before Eddystone-EID and the Eddystone Configuration GATT Service become commonly available. As with Eddystone itself, many beacon manufacturers will probably delay implementation until they see there’s a market demand for these new capabilities. Google tellingly mentioned 15 manufacturers, ‘will’ rather than ‘do’ support these new features. Even now, most beacons don’t support Eddystone-TLM yet.

Meanwhile (and even into the future), there will be a mix of old and new beacons that will complicate comprehension thus further. Also, all this only covers Eddystone. iBeacon beacons will still need their own individual manufacturer configuration apps and as beacons supporting Eddystone tend to be a subset of those supporting iBeacon (rather than the other way around) it’s likely we will still have many different configuration apps.

Looking top-down, most rollouts still use iBeacon rather than Eddystone so these new initiatives are likely to have little short-term affect. However, with Eddystone gaining features faster than iBeacon, given time, it might tip the balance and help it become more popular.

New Google Beacon Tools App

Google has just published a new Beacon Tools App. It allows you to register Bluetooth Low Energy (BLE) beacons (Eddystone and iBeacon) with the Google Beacon Registry and create small attachments for them.
This then makes them available to be seen via APIs such as Google Nearby or the Proximity Beacon API that are both readable via iOS and Android. Beacons need to be registered against a Google API project.

BeaconToolsApp

The new app provides an easy way for developers to associate data with their beacons without doing this programatically. However, you still currently need a different app, server, web UI or something to read this data back.

One of the attributes you can set in the Beacon Registry is a Place Id that allows you to associate a beacon with a Google Places API place. It remains to be seen if Google will make beacon data publicly accessible via the Google Places API as this would open up a new set of without-app usecases (and potential privacy problems for projects not wanting their data visible).

How To Configure Eddystone on the iB003N?

The iB003N can transmit up to three channels at one time. The first is the normal iBeacon channel, the second contains values from the accelerometer and the third is a custom channel that can transmit anything. This third channel is what you need to use for Eddystone.

Some of our customers seem to be trying to configure this via Service 0xFFD0 and rewriting characteristics 0xFFD1 (20-bytes), 0xFFD2 (8-bytes) and 0xFFD3 (1-byte length). You can configure these but there’s an easier way.

The first thing to know is that only the iOS configuration app, not Android, has an easy configure screen to set up Eddystone-UID or Eddystone-URL data. Hence, we recommend you use the iOS app.

Tap the beacon on a hard surface and it will ring. Run the iOS eBeacon app and you will see the beacon. Tap on the beacon in the app and it will ask for a password which is “666666”. You will now see a list of Services. The Eddystone configuration screen is slightly hidden. Tap on the Service FFD0 and you will see the screen below:

serviceFFD0

Tap on ‘Configure’ in the top right and you will get to the Eddystone configuration screen:

eddystoneurl
If you only have an Android device and/or you wish to take the more manual approach, the Eddystone spec defines what to set as the advertising data. Note that 0xFFD3 is read only and doesn’t need to be set. It sets itself based on the data you place into 0xFFD1 and 0xFFD2.

How Do I Manage Physical Web Beacon URLs?

We have had some enquires how to manage Physical Web beacon URLs remotely, without physical access to the beacon. The answer lies in a previous post on Physical Web Getting Started Tips where we referenced a paper advocating the use of a URL shortener for web addresses over 18 characters. However, there’s a bit more to it than that.

First of all, the URL doesn’t strictly have to have 18 characters or less. Longer URLs can sometimes still fit in the beacon advertising data because the scheme (http part) and domain ending are encoded. See the Eddystone specification for more details. In most cases you don’t have to worry about the encoding as it’s the beacon management app that puts the URL in the beacon for you. In any case, you should be putting a shortener-generated URL into the beacon to allow it to be remotely changed in the future without re-configuring the beacon.

The next thing to know is that you shouldn’t use just any shortener. Commonly used URL shorteners such as goo.gl and bitly.com don’t allow you to change the URL. Instead, use a shortener such as tiny.cc or bit.do (the login versions of these services) that allow you to change the URL in the future.

For less dependence on a third party, more privacy of visitor stats and a better service level, you might consider a self-hosted URL shortener. Take a look at yourls.org that provides pretty stats and polr that provides an API that, if you are an app developer, you might use to allow users to manage URLs from within your app or other (web) interface.

We have used yourls.org for some of our test Eddystone beacons and it works well with Chrome/the Physical Web app including changing URLs.

One final thing to know is that, as mentioned previously, Eddystone URL only triggers on secure Physical Web URLs (https rather than http). However, it’s only the final redirected-to URL that needs to be secure and you can use tiny.cc or your own self-hosted URL shortener on a non-secure domain.

Why Doesn’t Chrome Detect My Physical Web/Eddystone Beacon?

We have a lot of enquiries asking why Chrome on Android doesn’t pick up some beacons. This is often despite enabling the Physical web in Chrome.
Even mobiforge had problems.

The reason is almost always because the pointed to URL doesn’t use https. For some reason, probably as a defence against Man in the Middle attacks, Chrome on Android needs the URL to be secure otherwise it won’t be triggered. Note that the Android Physical Web app and also Chrome on iOS don’t have this limitation.

The fact that so many people are confused and it’s inconsistent with Chrome on iOS suggests that the Google hasn’t thought through or communicated this aspect well enough.

UPDATE: As of October 2017, Google removed Eddystone detection from Chrome on iOS and Android. Only Android can provide notifications.

Sky Forecum 201 Longer Range Than Expected

In our beacon testing, we occasionally come across a beacon that behaves better than the manufacturer’s specification. The Forecum 201 is one such beacon that while having a specified range of up to 100m, actually achieved a range of 108m at normal power (0dBm) and 190m at full power (+4dBm). This is unusual because we have found that most manufacturers tend under-deliver rather than over-deliver when it comes to matching the quoted range in real-life situations

We were curious as to whether this was at the expense of battery use and were pleasantly surprised when our battery power tests showed that a new battery will last 1.8 years at 1s transmission and 0db power.

201_photo_smaller

The Forecum 201 supports both iBeacon and Eddystone (URL and UID) and is available in both sensor (humidity, temperature, acceleration) and non-sensor versions.

iB004 PLUS Sensor Beacon Available

We now have a limited number of iB004 PLUS beacons in stock with an additional SHT20 temperature/humidity sensor. The iB004 is one of the most commonly used (and re-branded) beacons and the ‘PLUS’ part means it has a larger CR2477 battery rather than the CR2450 in the original iB004. The larger battery means there’s a longer 100m (vs 70m) range and longer battery life.

ib004plus-temp_smaller

The temperature/humidity version has a small hole in the top to allow the environment, external to the case, to be sensed.