opensense
opensense

OpenSense documentation

Reference manual for operators and developers

OpenSense is a telemetry SaaS for small operations in the EU. One backend reads any combination of temperature, humidity, CO₂, leak, pressure, power and voltage sensors. Five verticals share the same pipeline: HACCP cold chain, Legionella in hot water, server-room monitoring, indoor climate, and energy.

This site is the technical reference. If you are evaluating the product, read the marketing site first.

01 · 5 minQuickstart

Pair your first Shelly H&T, see the chart, fire a fake alarm. Five minutes, no soldering, no cabling.

02 · modelConcepts

Sites, devices, sensors, channels, alerts, retention. The seven nouns that appear everywhere else in this manual.

03 · pipeHTTP & MQTT API

Send measurements from any source: cURL, ESPHome, Arduino, TTN, Shelly, MQTT broker. Idempotency, rate limits, error codes.

04 · rulesVerticals

Concrete thresholds, regulations and report templates for each of the five verticals we support out of the box.

What this is, what it isn't

OpenSense is:

  • A multi-tenant ingest pipeline that accepts sensor readings over HTTP, MQTT and LoRaWAN (TTN webhook).
  • A storage layer that retains raw measurements for 13 months and downsampled rollups (5 min / 1 h / 1 d) for five years.
  • A rule engine that triggers Telegram, email and webhook alerts when a channel leaves the configured operating range.
  • A reporting layer that generates one-click PDF reports per vertical: HACCP fridge logs, Legionella supply/return curves, server-room uptime, climate compliance, energy baselines.

OpenSense is not:

  • A SCADA replacement. We are honest about the budget: 1–10 sensors per site, not a full industrial plant.
  • A hardware vendor. We do not sell sensors. You buy them from Amazon, Shelly, Aqara, Efento or any other vendor, then point them at our ingest URL.
  • A general-purpose IoT platform. We pick five verticals and write the rule templates and report templates for them. If your use case is something else entirely, you can still use the API — but you are on your own for the templates.

Operator vs developer

This manual is split. If you are setting up sensors and reading reports, stay in Getting started, Hardware and Verticals. If you are integrating custom hardware or building your own dashboard, API is the section you want. Troubleshooting is shared.

Working assumptions

  • All data lives in the eu-central region. Account creation in any other region is not currently possible.
  • All times are stored in UTC. The dashboard renders in the browser's local timezone; PDF reports render in the site's timezone (configured per site).
  • All readings are stored with full sensor precision. Display rounding happens in the UI only.
  • Magic-link authentication is the only auth method for the web UI. API tokens are scoped per device for ingest and per user for management.