Setpoint and schedule data, without the comfort-learning model
Smart thermostats already log temperature, setpoint and occupancy history to the vendor's cloud, distinct from the heat pump or furnace they control. The Data Act gives homeowners a standing right to that data — and to route it to a smart-home platform or energy app they choose.
The device's data is the homeowner's. The learning model isn't.
The central scoping question for a thermostat is straightforward once stated under the Data Act: sensor readings, schedules and occupancy events are the homeowner's data. The proprietary model that turns that data into automatic schedule suggestions is the vendor's.
Usually in scope
- Temperature and setpoint history
- Occupancy/presence sensing events, where fitted
- Schedule and automation configuration the homeowner set
- Energy-use estimates tied to the thermostat's own runtime signal
Usually outside Chapter II
- The vendor's proprietary comfort-learning/auto-schedule algorithm
- Cross-household aggregate analytics
- Firmware and embedded control logic
- Data never captured or retained by the thermostat cloud
| Field group | Typical source | Delivery format |
|---|---|---|
| Temperature & setpoint history | Thermostat sensor via app sync | Time-series export, CSV/JSON |
| Occupancy/presence events | Motion or presence sensor | Structured export, minimized and shorter retention |
| Schedule configuration | Homeowner-set automation rules | Structured export of active and historical schedules |
| Energy-use estimate | Runtime-derived consumption model | Interval export tied to the thermostat's own signal |
From a one-app silo to a homeowner-directed export
The vendor's app already shows the homeowner their own schedule and sensor history. The access layer is what makes that same data exportable and shareable on the homeowner's terms, not just viewable in one app.
Today: a closed loop
Product
Smart thermostat
Backend
Thermostat vendor cloud
- Temperature & setpoint history
- Occupancy/presence events
- Schedule configuration
- Energy-use estimate
Only exit
Manufacturer's own app
- No user-facing export or API
- No route for the user to authorize a third party
- No permissions model, so every request is a one-off exception
- No audit trail if a user or regulator asks what was shared
With a Data Act access layer
Product
Smart thermostat
Backend
Thermostat vendor cloud
- Temperature & setpoint history
- Occupancy/presence events
- Schedule configuration
- Energy-use estimate
New layer
Data Act access layer
- Field catalog
- User & device entitlements
- Consent & grant registry
Customer export & portal
CSV/JSON, self-service, same quality as the manufacturer sees
Third-party API (OAuth)
Purpose-bound grant to a repairer, analytics or energy provider
Audit & compliance log
Request, decision, recipient and delivery evidence for review
What we implement, concretely
A customer data export API, CSV/JSON download, third-party sharing and an audit/permissions layer.
| Capability | What it does |
|---|---|
| Customer data export API | Authenticated access to setpoint, occupancy, schedule and energy-estimate history |
| CSV/JSON download | Self-service export for the homeowner's own records |
| Third-party sharing | Purpose-bound, revocable access for a smart-home platform or energy-advisory app the homeowner picks |
| Entitlement & audit layer | Tenant/landlord-aware access control with a reviewable decision log |
Separate occupancy data
Give presence/occupancy events their own minimization and retention rules, distinct from schedule and temperature history.
Model tenant/landlord entitlements
Decide who holds the access right in rented properties, and how it transfers at move-out.
Design the homeowner API
Define catalog, request, third-party grant and delivery endpoints separate from the vendor's internal app API.
Build the decision engine
Turn catalog, entitlement and privacy checks into explainable allow, partial and refuse outcomes.
Ship export and sharing
Deliver a homeowner export and a smart-home-platform sharing flow with revocable credentials.
Test the edge cases
Run through tenant move-out, rival-platform sharing requests and disputed comfort-learning-model requests.
Smart thermostat Data Act FAQ
Does occupancy/presence data deserve extra privacy care?
Yes, more than most other thermostat fields. A record of when a home is occupied or empty is a meaningful privacy signal on its own, independent of whether it's tied to a name. Treat occupancy and presence events as a higher-sensitivity field group, with tighter minimization, shorter default retention, and clearer purpose limitation than plain temperature or setpoint history.
Does the access right apply from the moment of purchase, or only from the 2025 deadline?
The access-on-request duty has applied generally since 12 September 2025, which covers thermostats already installed before that date, not just new ones. The forward-looking Article 3(1) by-design duty is separate and reaches thermostats placed on the market after 12 September 2026.
In a rented apartment, who holds the access right — tenant or landlord?
Typically whoever has the operative relationship with the thermostat as a user during the tenancy, most often the tenant living in the property day to day, with the landlord's interest usually limited to the property itself rather than the tenant's specific comfort settings and occupancy patterns. Build an explicit tenant/landlord entitlement model rather than defaulting to whichever party set up the account.
Can the vendor refuse to share data with a rival smart-home platform?
Not as a blanket policy. If the homeowner directs their own data to a smart-home platform or energy-advisory app of their choosing, Article 5 requires that sharing to proceed on the agreed terms, with the same DMA-gatekeeper exception that applies elsewhere. A vendor can apply proportionate security and trade-secret safeguards, but competitive preference for its own ecosystem isn't a valid ground for refusal.
Is the schedule/automation configuration itself in scope, not just sensor readings?
Yes. The schedule a homeowner has set — when the thermostat should heat or cool, and to what setpoint — is data the homeowner created and should be able to access and export, on the same footing as the sensor readings the device records. It's meaningfully different from the comfort-learning algorithm that suggests schedule changes, which sits closer to the vendor's own proprietary logic.
How does this differ from the HVAC/heat-pump page it commonly pairs with?
The thermostat and the heat pump or furnace it controls are usually separate connected products, often from different manufacturers, each generating their own data. This page covers the thermostat's own setpoint, occupancy and schedule data; our dedicated HVAC & heat pump page covers the unit's own temperature, runtime and fault data. A real installation often needs both access layers, cross-linked but not merged into one dataset.
Primary sources and status
Reviewed 9 September 2026. The Data Act and GDPR are binding EU regulations. The Commission explainer is non-binding implementation guidance. Yarify's API contract, entitlement model and delivery sequence are engineering recommendations, not legal advice.
- Regulation (EU) 2023/2854 — the EU Data ActBinding legal text covering connected-product data access, third-party sharing, fair terms and transitional dates
- Regulation (EU) 2016/679 — the General Data Protection RegulationBinding data-protection rules of particular importance here, since occupancy/presence data can reveal when a home is empty
- European Commission — Data Act explainedNon-binding overview of in-scope IoT data, user and third-party flows, and safeguards