Product Data Disclosure
Binding version 1.1. Version: 2026-08-01. The German version is the legally binding one; this English text is a courtesy translation.
1. What this document is — and is not
This document discharges the pre-contractual information duty under Article 3 of the EU Data Act (Regulation (EU) 2023/2854). That duty runs to you as a prospective buyer, before the purchase contract is concluded: before buying, you should know in particular what data the product generates, in what volume, whether continuously and in real time, where and for how long it is stored, how you can access it, and whether the seller uses it themselves — so you can factor that into your purchase decision. How we process personal data is set out in the privacy policy (https://air-node.net/de/datenschutz).
Scope: the AirNode consists of the controller (with Wi-Fi and optional cloud connectivity) and an externally connected sensor satellite that measures outdoor temperature and humidity and reports its values only internally, over a wired bus, to the controller. The data described below is what the controller generates and what is accessible to you; the satellite itself generates no independently accessible data beyond what the controller makes of its readings.
2.1 Measurements (telemetry)
Indoor temperature, indoor humidity, outdoor temperature, and outdoor humidity, each with its own availability flag (a sensor can be temporarily unreachable), together with the time of measurement. Format: floating-point number for temperature/humidity, boolean for availability, timestamp as ISO-8601 with a UTC offset.
2.2 Device state
Whether the fan is running and in which operating mode (automatic, permanently on, permanently off) — part of the same telemetry row as 2.1. In addition, the cloud platform keeps, per device, status, online state, time of last contact, and the reported firmware version.
On top of that come technical operating values of the device — among others memory and uptime values, radio signal strength, reset reason, and counters for open network connections — as numeric values per field with the timestamp of the last update.
2.3 Configuration and schedule
The weekly fan-override schedule you configure (start/end time and state per interval, as JSON), a running version number, and the time the platform last ingested this schedule from the device.
2.4 Events (alerts)
Device offline, indoor or outdoor sensor failed, OTA update failed — each with the time it was raised and, once resolved, the time it cleared.
2.5 Device commands you issue
Every control instruction you send to a device through the cloud — e.g. a fan override, a change to control parameters or the schedule, or a restart — is stored with its command type, full payload (JSON), status, and timestamp.
All categories, except the raw-telemetry CSV in the export (section 6.2), are held and delivered as structured JSON — a common, machine-readable format within the meaning of Article 3(1)/4(1).
3. How often and how much
The device measures on a scale of seconds: the indoor sensor is read every 5 seconds; these readings are first processed only on the device (section 5.1). To the cloud, the device transmits every 60 seconds by default, configurable in the range 60–300 seconds — so not every reading reaches the cloud.
Estimated volume: at the default setting, around 1,500 measurement rows per device per day arise in the cloud, which over the raw-data retention period from section 5.2 is on the order of 100,000 rows per device; at the slowest permitted setting, roughly a fifth of that. A measurement row comprises the timestamp, the four measured values with their availability indicators, plus fan state and operating mode. Once the raw-data retention period expires, the aggregates from section 5.2 cover the remainder of the retention period, at coarser time resolution.
4. Continuous and in real time?
Yes, with a difference by access route. On the local network, the device’s own web interface always shows the most recently measured value; freshness there matches the measurement cadence from section 3 and does not depend on an internet or cloud connection. Through the cloud service the values are available continuously, but only at the rhythm of the transmission cadence you configure (section 3), not at the measurement cadence. The generated data is therefore accessible continuously, and via the local access route in near real time.
What follows from this, and it binds us: the device’s own local web interface is the only access route offering the freshness of the measurement cadence. It may therefore not be removed outright, materially restricted, or made dependent on a cloud connection. A functionally equivalent local real-time access route may take its place — the specific technical implementation is not immutable, but the access route as such is.
5.1 On the device
The device itself holds condensed history values covering the last few hours up to seven days. Older values are continuously overwritten by new ones, not removed in a separate deletion step.
5.2 In the cloud
Measurements at raw resolution: 90 days. Hourly averages: 1 year. Daily averages: 10 years. Device commands you issue (section 2.5): 90 days after creation — with one exception: the latest acknowledged command per device and command type is kept indefinitely, because it represents the device’s current settings state. Device state (section 2.2) and schedule (section 2.3): no time-based deletion — they persist for as long as the device remains paired to the account. Events/alerts (section 2.4): no time-based deletion.
Not part of this list: internal operations and security data of our platform that does not arise from your use of the product. It is described in the privacy policy.
6. How you access it
There are three paths; two require the cloud service, one does not.
6.1 The device’s own local web interface (LAN, no cloud)
On the same local network, the device’s web interface shows the current measured value and a condensed history of the last few hours to days — without raw resolution and without a downloadable file. It requires signing in to the device; an internet connection and a cloud account are not needed.
6.2 Self-service export in your account
You trigger the export in your account and then download the archive there; one export can run at a time. The export is free of charge for you.
It covers all the data categories named in section 2 — measurements at raw and at condensed resolution, device state including the technical operating values, the schedule, events, the commands you issued, the device’s update history, and your account data including the metadata recording when, and which version of, the privacy policy and the terms of use you accepted. What is delivered is an archive with structured JSON per data category and CSV per device for the measurements; it comes with a bilingual description of every file, field, unit (°C, % RH) and the timestamp format (ISO-8601 with UTC offset). The export reaches as far back as the retention periods in section 5.2 hold data.
Once the raw data has been deleted at the end of the period stated in section 5.2, the export covers the hourly and daily averages still held.
6.3 Programming interface with a personal access key
Through a documented programming interface you can use, machine-to-machine, the same data and functions the app itself uses — including a continuous stream of incoming measurements — in the same machine-readable format. You create the personal access key in your account.
Important for assessing what a key opens up: it acts like your own sign-in — there is no restriction to read access and no restriction to specific data categories. Whoever receives the key can also write to your account, for instance setting a fan override; treat it like a password and do not pass it on.
7. Whether and how AirNode itself uses the data
AirNode uses the data generated by the product solely to provide you with the functions described in this document: displaying current state, showing history, executing your control commands, and alerting. There is no automated decision-making, no profiling and no tracking; we do not use analytics or advertising technology. Product data is not handed over for third parties’ own purposes: the recipients named in the privacy policy are processors, and none of them gets access to use your product data for their own purposes.
Details of every processing activity and of the processors engaged are set out in the privacy policy.
8. What works without the cloud
Measurement, control, the weekly schedule and the local web interface run entirely on the device and work without an internet connection. Which functions require an existing cloud service is set out in our support and security-update policy (https://air-node.net/de/support).
9. Version history
Version 1.0, 2026-07-31: first binding version.
Version 1.1, 2026-08-01: scope of the self-service export extended.
2026-08-08: section 4 — binding undertaking added that the local real-time access route is only ever replaced by an equivalent one.
2026-08-11: presentation shortened and made implementation-neutral; data categories, frequency, retention periods and access routes unchanged.