Reference · built on requestConnectorSensors, meters & gateways

Ruuvi Cloud

Temperature, humidity, pressure, and movement from RuuviTag sensors through Ruuvi Gateway and the Ruuvi Cloud User API.

About

Ruuvi Cloud stores measurements from RuuviTag Bluetooth sensors relayed by a Ruuvi Gateway. The User API at network.ruuvi.com lists your claimed and shared sensors, returns history in dense, sparse, or mixed mode, and holds alert settings per sensor. Each measurement carries the raw hex advertisement, the gateway MAC, and RSSI. The gateway can also forward to your own HTTP server or MQTT broker.

Through Fibric, an operator reads each sensor's latest values and history, watches the alerts you configured, and proposes new limits, calibration offsets, or a share to a colleague. You approve. Ruuvi Cloud applies it and the receipt shows the prior setting.

This is a reference listing. It documents what Fibric would read from Ruuvi Cloud and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Claimed and shared sensors through GET /sensors and GET /sensors-dense, with latest measurement, calibration offsets, alerts, and subscription
  • Measurements through GET /get with sensor, since, until, limit, sort, and mode dense, sparse, or mixed
  • Each data point's timestamp, rssi, gwmac, coordinates, and hex-encoded data in RuuviTag data format 3, 5, C5, 6, or E1
  • Alert settings and state through GET /alerts: type, min, max, enabled, triggered, and triggeredAt
  • Subscription limits through GET /subscription: maxHistoryDays, maxResolutionMinutes, maxClaims, maxShares, and which alert channels are allowed
  • Gateway posts to POST /record signed with Ruuvi-HMAC-SHA256, or the same data forwarded to your HTTP or MQTT endpoint

Proposed actions

  • Target capability: propose alert limits through POST /alerts with sensor, type, min, max, enabled, counter, description, and delay
  • Target capability: propose a sensor rename or calibration offsets through POST /update
  • Target capability: propose sharing a sensor with another user through POST /share, or removing it through POST /unshare
  • Target capability: propose claiming a new sensor by MAC address through POST /claim

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Keep a walk-in freezer inside its range

    Temperature history in dense mode shows the door-open spikes. The operator proposes a delay on the alert so a short spike does not page anyone, and the escalation when the reading stays high.

    With Cold Room Watch

  • Produce the temperature log an auditor asks for

    Mixed-mode history for each sensor is written to your log at the resolution your plan allows. The operator proposes a corrective-action entry for any excursion and flags gaps in the record.

    With Food Safety Log

  • Catch a sensor that stopped reporting

    Signal level and No data alerts, plus rssi per measurement, mark tags drifting out of gateway range. The operator proposes moving the gateway or replacing the battery.

    With Sensor Health

  • Protect pipes on a cold night

    When an unheated space trends toward freezing, the operator proposes lowering the min alert limit and a check visit, and records when the temperature recovers.

    With Freeze Protection

Requirements

  • A Ruuvi Cloud account that has claimed the sensors, and a Ruuvi Gateway online with them in Bluetooth range
  • A subscription whose maxHistoryDays and maxResolutionMinutes cover the window you need; the values are returned by the API
  • For email or push alerts, a plan that allows them: push from Basic, email from Pro
  • For direct forwarding, an HTTP(S) server or MQTT broker the gateway can reach, with Basic, Bearer, Token, or API key auth
Authentication
A bearer token issued after POST /register with your email and POST /verify with the code that arrives, sent as Authorization: Bearer on every User API call.

Limits

  • GET /get returns at most 5000 points per call; page with since and until
  • Dense data is pruned after a limited period; sparse data is downsampled but unlimited in range
  • Alerts trigger at most once per hour per user, alert, and sensor, with a 60 minute triggered and 5 minute resolved hysteresis
  • No data and Delayed trigger alerts need Pro or Business plans

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Ruuvi Cloud ↗

Questions and answers

How do I get an API token?
Call POST /register with your email. Ruuvi Cloud emails a verification code. Call POST /verify with that code and you receive a bearer token. Send it as Authorization: Bearer on every request. Sessions can be listed and revoked through GET and DELETE /sessions.
What do dense, sparse, and mixed modes mean?
Dense returns the highest data density but covers a limited time range before older points are pruned. Sparse returns downsampled data with no range limit. Mixed returns all available dense data and fills the remaining range with sparse data. Each call is capped at 5000 entries.
Which alerts and channels does each plan allow?
Temperature, humidity, air pressure, movement, and signal level alerts are on every plan, shown as a UI icon. Push notifications start at Basic, email at Pro. No data alerts need Pro or Business. Delayed trigger, a user-defined delay before an alert fires, is Business only.
Ask about Ruuvi Cloud

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.