This view contains the raw sensor data, as captured by the Spacewell platform.
Here you will find the recorded values of all the installed sensors and devices with exact timestamps.
Data structure
Column | Meaning | Comment |
|---|---|---|
sensor_id | unique identifier of a device sensor | |
source | source of sensor data | |
device_id | unique identifier of the device that contains the sensor | |
timestamp | timestamp in UTC timezone | Can be different from the local time zone of the location where the device is installed |
value | value registered by the sensor | always unitless. The units depend on the sensor_class of the sensor (i.e. what is monitored, e.g. presence, headcount, temperature, humidity etc.) |
sensor_type | what data a sensor monitors (PRESENCE / HEADCOUNT / CO2 etc) |
Sensors, devices and locations
The relationships between locations, devices and sensors are:
- each location can have 0, 1 or more linked devices
- each device can have 1 or more sensors
- sensor data are recorded on a time line, per sensor
People install devices with sensors in various locations. Each location can have zero, one or multiple devices installed. For example, a meeting room may have a headcount sensor device and and air quality device at the same time.
Every device has 1 or more sensors. It depends on the brand model of the manufacturer. Some devices simply have one sensor, e.g. a motion device only records “presence”. Other devices can record data via multiple sensors, e.g. an air quality device that records temperature, humidity, CO2 level and air pressure.
From bottom up to top viewpoint, the Spacewell data platform always collects data per sensor. Each sensor belongs to exactly one device. And each device is installed in exactly one location.
Illustration:
This is an air quality device that contains 4 sensors (CO2, humidity, battery, temperature) and values are recorded per sensor:
(battery level is not shown here)
Why use raw sensor data?
The built-in Spacewell dashboards contain visualizations that most customers need for sensor data analysis:
- Space Monitor
- Space Simulator
- Comfort Monitor
- etc
These dashboards provide insights to curated sensor data using time slots per location. They take away the complexity of interpreting and aggregating sensor data into meaningful analytics.
Nevertheless, some customers may wish to work with raw sensor data for their own business purposes:
- building a specific internal data warehouse for own reporting needs
- developing own metrics and targets that are not defined in Spacewell’s standard dashboards
- sharing sensor data with third parties
- vendor independence
- etc
How to use raw sensor data
Because it contains millions of row, this view is partitioned by calendar date. It means that you must always specify a date range when querying the view, for example:
wide760.exposed_views.sensor_data_v1` where timestamp >= '2026-01-01']]>Additionally, this view should be joined with other views for meaningful data analysis:
- the view that contains more detail about the devices and sensors:
- the view that contains information about the locations where devices are installed
Timestamps and time zones
This view contains values with timestamps, as registered by sensors.
All the timestamps are in UTC time zone, which lets you build analysis correlations across the globe if needed.
However, most sensor data analysis is done locally, i.e. specific for 1 site or building in a specific time zone. To report in local time zone, you must apply the relevant time zone offsets in your own data platform!
This remark is only relevant when using this view with raw sensor data. When using Spacewell’s curated and aggregated timeslotmechanism, the conversion to local time zone is applied automatically.
Another remark is that timestamps in this view can be very irregular on the time line. Each sensor device has its own characteristics when recording data. For some, there may be regular timestamps (e.g. a sensor that records temperature every 5 minutes) while for others, the recorded timestamps are in function of people (e.g. a motion sensor that detects presence on a desk/workplace).
Massive data volume
When using this view, be aware of the massive data volume it contains!
As an example, a single sensor channel may sample every 5 minutes.
That means
- 12 times per hour
- 12 x 24 = 288 times per day
- 288 x 365 = 105.120 times per year, for only 1 sensor
- and if you have 1000 of these: 105 million rows per year
For some sensor devices, sampling rates are even higher!
Therefore, data analysts should have a clear strategy and mechanisms in place for incremental data loading, because this view on raw sensor data doesn’t get row updates, it just obtains additional rows while time progresses.
See also