LogoLogo
  • Ruuvi Developer Documentation
  • Ruuvi Hardware
    • RuuviTag B
    • RuuviTag Pro
    • Ruuvi Gateway
    • Ruuvi DevShield
    • Ruuvi Connector Kit
    • TMP 117 External Sensor
  • Ruuvi Connector System
    • Introduction
    • Expansion boards
    • Cables
    • Connectors
  • Ruuvi Sensor Firmware
    • 1.2.12
    • 2.5.9
    • 3.X
      • 3.x Sensors
      • 3.x Heartbeat
    • Device Firmware Update (DFU)
  • Ruuvi Gateway Firmware
    • GW Getting Started
    • GW Web-UI
      • Greeting window
      • Internet connection settings
        • Connection via Wi-Fi
        • Connection via Ethernet
      • Software update
      • Automatic configuration download
      • Automatic updates
      • Access Settings from LAN
      • Cloud Options
        • Backend: HTTP(s)
        • Backend: MQTT(s)
        • Backend: Statistics
      • Time Synchronisation Options
      • Bluetooth Scanning Settings
      • Configuration completion
      • Authentication when accessing from LAN
    • GW Install custom firmware
    • GW nRF52811 Firmware
      • GW nRF52811 selftest
      • GW nRF52811 scanning
      • GW nRF52811 repeating
      • GW nRF52811 UART communication
  • GW ESP32 Firmware
    • GW ESP32 WiFi Hotspot
    • GW ESP32 Button
    • GW ESP32 LED
    • GW ESP32 HTTP Client
    • GW ESP32 MQTT client
  • GW Data formats
    • HTTP: Time-stamped data from Bluetooth-sensors
    • HTTP: Data from Bluetooth-sensors without timestamps
    • MQTT: Time-stamped data from Bluetooth-sensors
    • MQTT: Data from Bluetooth-sensors without timestamps
    • HTTP GET /history (with timestamps) and decoding
    • HTTP: Gateway status
    • Gateway configuration
  • GW Examples
    • Polling mode
    • Poll endpoint "/metrics"
    • Configuration update via API
    • Firmware update via API
    • Configuration download from a remote server via API
    • MQTT examples
    • Home Assistant
    • MQTT+AWS IoT Core
  • Communicate with RuuviTag devices via Bluetooth
    • Bluetooth advertisements
      • Data format 3 (RAWv1)
      • Data format 4 (URL)
      • Data format 5 (RAWv2)
      • Data format C5 (Cut-RAWv2)
      • Data format 8 (Encrypted environmental)
    • Bluetooth connection
      • DIS (Device Information Service)
      • NUS (Nordic UART Service)
        • Heartbeat transmissions
        • Read logged history
    • Real Time Transfer (RTT)
  • Communicate with Ruuvi Cloud
    • Ruuvi Cloud
      • User API
      • Gateway API
      • Internal API
      • Alerts
      • Cloud stored app settings
  • Ruuvi Community projects
    • Integrations
Powered by GitBook
On this page
Edit on GitHub
  1. Communicate with RuuviTag devices via Bluetooth

Bluetooth advertisements

Lifecycle: In production

PreviousMQTT+AWS IoT CoreNextData format 3 (RAWv1)

Last updated 1 year ago

Introduction

If you're not already familiar with Bluetooth Low-Energy (BLE) advertisements in general, please read the .

The default way of getting data from RuuviTags is to listen to Bluetooth Low-Energy advertisement packets. The data is in manufacturer specific format.

Additionally, connectable Ruuvi devices have a scan responce which contains device name "Ruuvi XXXX" and UUID of the Nordic UART Service. However if you're looking to only read the advertised data, you can ignore the scan responses.

Advertisement intervals

The data is broadcast and not acknowledged by the listeners, therefore there is no guarantee that any single data packet will be heard by a nearby phone or gateway. The chance to receive the data depends on the signal strength and noise on the 2.4 GHz band, typically 25 ... 90 % of advertisements can be received in good conditions.

The delay between updates is random, a gateway may miss 10 advertisements in a row even in good conditions. This latency is dependend on the broadcast interval, faster broadcasting means more chances to catch the data. On the other hand faster broadcasting will drain the battery faster, so there is a performance / battery runtime tradeoff.

As of Ruuvi Firmware version 3.28.13 the default advertisement rate is 1285 ms + random delay of 0 ... 10 ms per advertisement. Test versions of firmware advertise at a rate of 211 ms + 0 ... 10 ms and long life versions at a rate of 8995 ms + 0 ... 10 ms. Default and test intervals match Apple guidelines for bluetooth accessories, long life version might not be discovered by Apple devices at all. Android doesn't similar guidelines.

Advertisement data

The advertisement begins with mandatory flags highlighted in blue. The the actual manufacturer specific data begins with a header highlighted in dark green which contains:

  • Length (not counting length byte): 0x1B = 27 bytes

  • Type: 0xFF = Manufacturer specific data

  • Manufacturer ID, least significant byte first: 0x0499 = Ruuvi Innovations Ltd

  • Payload data: 0x050F274035C454005000C8FC20A456F030E5C9445429E38D

Grayed out data is the scan response. Scan response is relevent when establishing the Bluetooth Connection to Ruuvi devices, but we can ignore it here.

Interpretation of different payloads is described in the sub-sections of this page.

Argenox primer
Advertised data and scan response