The primary goal of this format is to add support for custom data into an official data format. This is achieved by making the fields included in data format 5 optional by using a bitmask byte to indicate included measurements, and leaving all “unused” bytes for custom data.
The need for something like this has risen after the availability of RuuviTag related services have increased where custom format support can’t be reasonably achieved, for example I like using Ruuvi Station (backed by Ruuvi Gateway and Ruuvi Cloud), but I’d also like to add some custom sensors and/or measurements to some tags. If I were to create a custom data format for this purpose, I wouldn’t be able to view the standard data through Ruuvi Station. I could of course have the tag transmit in two data formats, but that’s really wasteful if all I need is a byte or two for the custom data/measurement.
In short, the data format would look like this:
- The first byte is the data format byte, like on all data formats
- The second byte is a bitmask, indicating the included measurements (see below)
- Measurement data starting from the 3rd byte, in same order as the bitmask bits (see below)
- Any data after the last measurement indicated by the bitmask is treated as custom data; length being anything between zero and what still fits into one advertisement
Bitmask bit, meaning and data size (same as in data format 5):
0: Temperature 2 bytes 1: Humidity 2 bytes 2: Pressure 2 bytes 3: Acceleration (all axes) 6 bytes 4: Power info 2 bytes 5: Movement counter 1 byte 6: Measurement sequence number 2 bytes 7: MAC address 6 bytes
Example payload with only temperature, humidity, measurement sequence number and 3 bytes of custom data:
offset: content 0: data format byte 1: binary 11000010 (bitmask with bits 0, 1 and 6 set) 2-3: temperature 4-5: humidity 6-7: measurement sequence number 8-10: custom data
Since one byte is used for the bitmask, all original data from data format 5 don’t fit simultaneously into one broadcast. A “standard tag” with all sensors could for example alternate between including either power info or humidity, as both change relatively slowly so doubling the effective interval for those is not a big deal. Tags with less-than-all-sensors, such as the pro tags, can fit everything into one broadcast.
- The bitmask could be two bytes to add more “standard measurements”, for example if some future RuuviTag models include some additional sensors (I’d still love to see a tag with a gyroscope!)
- Since the data length is not fixed, it can be adapted to fit in a more constrained space, such as an encrypted data format that requires a few bytes for the encryption itself
- The need for special “invalid values” is removed, since measurements that are not available can simply be omitted (such as pressure on the pro tag)
- Unnecessary measurements/data can be disabled to save a little bit of transmission time, and thus battery
- MAC is optional since it’s only needed for Apple devices, users who don’t need to support them can omit the MAC address from the payload to fit more custom data
- While iOS doesn’t let applications access the remote MAC address, they do give a non-permanent UUID, which could be used to map broadcasts to the correct tags once the application receives one payload that includes the MAC
One extra idea, which I’m not entirely sure is worth the extra complexity, is having a special bitmask for a completely separate payload or two. Since a bitmask with all bits set is an invalid combination due to space constraints, a bitmask with all bits set could indicate a special diagnostic/metadata payload. Also a bitmask with no bits set makes no sense as the broadcast would be all custom data for which a custom data format is a better fit so this could be used to indicate a different kind of special diagnostic/metadata payload as well.
These special payloads could include things like:
- Firmware version/variant (to enable tag firmware version tracking without a connection, ie. with the gateway)
- Tag “model” (ie. regular, pro 3in1, pro 2in1, etc, if this is “detectable” on the tag itself)
- Other details about the hardware, such as which temperatures sensor is present (ie. BME280 on the older tags and SHTC3 on the current ones)
- Some “configuration like” data, such as the configured broadcast interval
This “special payload” could be transmitted very infrequently since the data included in there very rarely changes. If the bitmask was 2 bytes, some of this data, such as the firmware version, could be included in a “normal payload” as well.
And just like last time, all comments and suggestions are more than welcome to improve this idea even further.