Suppose there are already sensors collecting data in the building and you want to include its data into the Workplace IOT platform. Spacewell provides a generic endpoint (using webhooks) for most of its sensor data types, to integrate, process and store sensor data from 3rd party platforms.
Webhooks
Webhooks provide a fast and secure way to reliably stream sensor data through from other systems.
The sensor provider is expected to post updates to the Spacewell endpoint.
The webhook endpoint expects a single HTTP request which represent a distinct message from the sensor.
The webhook URL:
HTTP method used: POST
HTTP headers:
Supported data types & payload
Space occupancy related data types:
Expand |
---|
title | PIR: space occupancy |
---|
|
Code Block |
---|
| {
"device": "<unique_device_id>", // string: unique id of the device
"type": "pir", // string: pir for occupancy
"timestamp": "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
"value": "1" // string: 0 or 1, 0 = not occupied, 1 = occupied
} |
|
Expand |
---|
title | Headcount: for measuring number of people |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "headcount", // string: headcount for measuring number of people
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "10" // string: value is unsigned integer
} |
|
Expand |
---|
title | Pulse: for door counters sending pulse values |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "pulse", // string: pulse for door counters sending pulse values
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "1" // string: count of pulses expressed as unsigned integer
} |
|
Expand |
---|
title | Count: for door counters sending accumulated values |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "count", // string: count for door counters sending accumulated values
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "10" // string: value is unsigned integer
} |
|
Expand |
---|
title | footfall-in pulse Expand |
---|
title | External Data Sources for beginners - an analogy |
---|
|
Since you’re on this page: looks like the sensors, that are in scope of sending data to the Workplace platform, are sending data to a platform or database that is not connected to Workplace. Working your way down this page, we’ll make sure that there is a connection set up between the platforms, that the data is send is a format that Workplace can work with and knows how to identify. Setting up External Data Sources and sending data from an external database to the Workplace platform can be compared to “A car arrives at a gate. The car is known to the gate keeper, and the person in the car has a badge, because he told his contact person up front that he was coming.” Image Added
We want the external platform to send data to Workplace, which is why we use webhook with HTTP method “post”. This means the data gets pushed by the other system, and Workplace will not have to pull it from somewhere. By creating an External Data Source in the tenant, you create a door or gate towards the Workplace platform: the Webhook URL. You’ll also receive the code to open the gate: the Authorization Token. Providing this information to the owners of the database, they are now able to reach the door. But they need to present us the data in a way that we can consume! So they need to adhere to some rules: the data they send us must be meaningful: Workplace needs to be able to do something with that data (for example present them on a live floor plan or in a dashboard). So the External Data Source needs to provide the data in any of the 10+ supported data types. it’s not enough that they would just throw some data at us. In order to correctly interpret that data, it needs to adhere to a specific (payload) format. In this way, we know which part of the information to interpret as the device ID, which part as the value we need to store in the Workplace database etc.
For Spacewell to know where we need to store the data in our database, the sensor needs to be known on our end, and linked to a location. This is why the device needs to be registered in Studio. To register the device in Workplace Platform, you need: Device Type, which actually contains a preset of data types (per chosen DeviceType, a default set of channels is enabled). Device ID, which needs to be unique. In order to make this ID unique across all tenants, the device ID format includes the tenant ID In order to make this ID unique within the tenant, the device ID format includes the External Data Source ID
Location information. If a sensor is not linked to a location, data is not stored in the Spacewell database.
Image Added | the fact that the car is arriving at the gate without Spacewell needing to do anything is the webhook the supported data type was the instruction to present at a specific gate the brand and model of the car is the payload, the vehicle that is used to present the data the data is in the trunk of the car the sensor ID is the badge used for identification the device type is the gate number the gate is open thanks to the authorization token
|
Spacewell consultants that want to learn more about how Spacewell treats data that comes in, can check out /wiki/spaces/WM/pages/492237 |
The sensor vendor needs to comply with the Spacewell webhook, supported data types & payload.
Info |
---|
Within 1 vendor ID, sensor IDs need to be unique and prepended with the vendor ID. Combining device IDs from multiple third parties in 1 External Data Source, raises the potential risk of conflicts. |
How to set up this connection?
Steps described on this page:
In the external (customer or 3rd party) database: Configure data payload
Configure the connection between External Data Source and Workplace
Go to database and fill in URL and token, make sure to test the connection
Configure devices on Workplace platform
Devices send data to Workplace platform
Webhooks
Webhooks provide a fast and secure way to reliably stream sensor data through from other systems.
The sensor provider is expected to post updates to the Spacewell endpoint.
The webhook endpoint expects a single HTTP request which represent a distinct message from the sensor.
The webhook URL:
HTTP method used: POST
HTTP headers:
Supported data types & payload
For all data types, it makes sense to verify if data will be send regularly or not; see https://spacewell.atlassian.net/wiki/spaces/KB/pages/5242896/External+Data+Sources#FAQ
Space occupancy related data types:
Expand |
---|
title | PIR*: space occupancy |
---|
|
Code Block |
---|
| {
“device”"device": "<unique_device_id>", // string: unique id of the device
“type”"type": "footfall-in-pulsepir", // string: footfallpir infor pulse sensor
“timestamp”occupancy
"timestamp": "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "5"value": "1" // string: count of in pulses expressed as unsigned integer 0 or 1, 0 = not occupied, 1 = occupied
} |
|
Expand |
---|
title | Footfall-out pulseHeadcount*: for measuring number of people |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device or count area
“type”: "footfall-out-pulseheadcount", // string: footfallheadcount outfor pulsemeasuring sensor
“timestamp”number of people
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "310" // string: count of out pulses expressed asvalue is unsigned integer
} |
|
Expand |
---|
|
Code Block |
---|
|
|
{
“device”: If your headcount device is able to track multiple count areas, you can send us the data of the individual count areas by replacing "<unique_device_id>"
, through "<unique_area_id>".
Expand |
---|
title | Pulse: for door counters sending pulse values |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "pirpulse", // string: pirpulse for occupancy door counters sending pulse values
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "1" // string: 0count orof 1,pulses 0expressed =as not occupied, 1 = occupied
} |
|
Comfort related data types: Expand |
---|
title | TemperatureCounter: for door counters sending accumulated values |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "temperaturecounter", // string: temperature sensor count for door counters sending accumulated values
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "25.510" // string: value inis Celsiusunsigned expressed as double with dot as decimal separator
} |
|
Expand |
---|
title | Humidity |
---|
Expand |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "humidityfootfall-in-pulse", // string: footfall in humiditypulse sensor
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "75.5" // string: count valueof in percentagepulses 0-100expressed as unsigned // expressed as double with dot as decimal separator
} |
|
Indoor Air Quality related data types:
Expand |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "co2footfall-out-pulse", // string: co2footfall forout carbonpulse dioxide sensor
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "555.53" // string: measured valuecount of CO2out inpulses theexpressed airas (partsunsigned per million)
// expressed as double with dot as decimal separator
} |
|
Expand |
---|
title | TVOC (Total volatile organic compounds) |
---|
|
Code Block |
---|
{
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "voc", // string: voc for volatile organic compounds
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "1.0" // string: measured value of VOC in the air (parts per billion)
// integer
} |
|
Expand |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "pir", // string: pir for occupancy
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "1" // string: 0 or 1, 0 = not occupied, 1 = occupied
} |
|
* Depending on the reliability of the sensor, space occupancy data may only contain data confirming “movement” (presence, headcount, footfall in one or the other direction etc), not the absence of movement… To tackle this in the Workplace platform, a decay feature has been introduced, which allows to visualize occupancy/headcount on the live (end user facing) floor plans for longer than what the data really tells us.
For an example on how Decay works, see https://spacewell.atlassian.net/wiki/spaces/KB/pages/491737/Motion+sensor#How-is-Motion-sensor-data-reflected-in-Workplace-Live-Views%3F
For a potential solution for data gaps in the dashboards (copy data in time slots), see https://spacewell.atlassian.net/wiki/spaces/KB/pages/5242896/External+Data+Sources#FAQ
Comfort related data types:
Expand |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "temperature", // string: temperature sensor
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "25.5" // string: value in Celsius expressed as double with dot as decimal separator
} |
|
Expand |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "radonhumidity", // string: radonhumidity sensor
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "1975.05" // string: radonvalue levelin measured is Becquerels per cubic meter, Bq/m3percentage 0-100
// expressed as double with dot as decimal separator
} |
|
How it works
The sensor vendor needs to comply with the Spacewell webhook, which means a joint project between Spacewell, the customer and the 3rd party sensor provider.
Spacewell will first create a vendor ID, which is descriptive and unique, as a Generic Endpoint. Usually, it refers to a tenant ID, or it can refer to the name of a sensor platform.
Within 1 vendor ID, sensor IDs need to be unique and prepended with the vendor ID.
So if you're thinking of combining device IDs from multiple third parties in 1 Generic Endpoint, there could be a potential risk of conflicts.
Copy Data in time slots
Depending on the kind of sensor, they might not send heartbeats or data regularly. If they send data and then only send a message upon value change, you might find yourself with bits and pieces of data (eg 1 time slot of 15 minutes with data about temperature, and nothing the rest of the day), which would cause confusion when you try to read the dashboards.
To work around this, you can opt to have us copy the data, per generic endpoint / device type level for any desired amount of time.
For example for the sensor type "Generic PIR" we could set a "copy in further time slots" and this value would be valid for all Generic PIR sensor values, which come to us for your tenant. Of course, the data is only copied until new data comes in again. So if a value comes in on Monday at 9am, and the configuration says "copy for 7 days", and on Wednesday at 8am a new value comes in, then from Wednesday at 8am the new value is taken for 7 days, or until a new value comes in.
This also means that we will only see in Workplace if a sensor is NOT transmitting data after the configured time has expired (in previous example: after 7 days).
Project steps
The following chapter describes step by step how to set up a generic endpoint and sensor data stream.
Prerequisites: We assume that this is part of an existing collaboration, where a tenant and locations are already set up.
Step 1 - Project start-up
Expand |
---|
title | 1.1 Launch the Generic Endpoint API mini project |
---|
|
Reach out to your Spacewell Account Manager to inform us about this new API-project. Include following information: Indicate which tenant is involved Indicate which type of sensors are targeted (PIR, Headcount, Doorcount, ...) Request an end-point: you will receive a vendor ID and authentication token (needed for step 1.4) Request a "Device ID" prefix (needed for step 6.1)
|
Expand |
---|
title | 1.2 Schedule the Kickoff meeting |
---|
|
In a Kickoff meeting with the stakeholders from all 3 parties, the goal of the project and next steps are discussed. |
Expand |
---|
title | 1.3 Setup the location master data |
---|
|
Make sure the master data (buildings, floors, locations) are already uploaded. |
Expand |
---|
title | 1.4 Share the Integration Documentation |
---|
|
Send the API documentation to the sensor provider. In the document, you'll see that there is a placeholder for the <sensor vendor> URL and for the bearer <token>. Let the 3rd party know what their specific URL and token are based on the information you receive from the Spacewell team. View file |
---|
name | Generic endpoint_Technical Documentation.docx |
---|
|
Info |
---|
To make life easier, you can remove from the document all sensor types that are not in scope of the project. If you’re targeting another type of sensor, please ask Workplace Product Management to look into the possibilities and create the API documentation. |
|
Step 2 - Make sure all questions are resolved
Expand |
---|
title | 2.1 Info session between Spacewell and 3rd party |
---|
|
Any questions regarding the API document should be addressed to the Spacewell Implementation Consultant, who will take them up with Workplace Product Management. The Workplace Team might also have questions for the sensor provider and needs to provide the bearer token. |
Expand |
---|
title | 2.2 Handshake on what to do |
---|
|
Agreement from both parties on the tasks ahead. |
Step 3 - Development & testing
Expand |
---|
|
The sensor provider develops the link between their sensors and the Spacewell API using the provided documentation. The Customer stays involved by providing location master data if necessary. |
Expand |
---|
|
Activate some sensors and configure them in Studio to see if data is reaching the webhook. In case request is not successful, the endpoint returns 4xx-5xx status codes depending on the occurred issue. The requestor may want to store failed requests and try re-sending them later. In case of successful request, the endpoint returns 200 status code with an empty body. |
Step 4 - Sensor Installation & configuration
Expand |
---|
title | Sensor installation (optional) |
---|
|
If not yet installed, sensors need to be installed according to 3rd party installation instructions. |
Expand |
---|
title | Sensor configuration |
---|
|
Make sure you have sensor IDs, Location master data, sensor plan (if available), and mapping between rooms and sensor IDs. From this step, you follow the normal setup process in Spacewell back-end Studio for configuring sensors. |
Expand |
---|
title | Configuration in Studio |
---|
|
Please be aware that only after the next data package is send, data for this sensor will be visible in your tenant. (This means that depending on time of upload to Studio and activity at the customer site, this can take a while.) You can manually add a record via "Add New Device" Go to your environment (https://studio.cobundu.com ) and log in Select the location, where you can manually add a sensor via "Add New Device" Select the (most relevant) Device Type "Generic …” (eg for PIR: "Generic PIR") from the drop-down list. As per the chosen DeviceType, a default set of channels is enabled If a device is able to gather data on a channel, that is not part of the DeviceTypes' default set of channels : it’s possible to manually add these in Advanced
Fill in the device ID: a "Device ID" prefix will be given by the Spacewell development team Give a meaningful name (eg customer_floor number_area) in Device Name. Location will be filled in based on your pre-selection in the location tree
For more information on how to add multiple new devices to Studio, check out Configure devices (add, remove, import/export). |
Expand |
---|
|
Go to your environment and change the location ID for each Sensor in Sensor Management. |
Step 5 - Validation & acceptance
Expand |
---|
|
High level sub-steps: Sensor sanity check Before rolling out the entire floor or adding additional floors, plan a sanity check to make sure every installed sensor is alive Once the sanity check is OK, continue the installation Reporting sanity check After 1 day, you should see the data coming in the Workplace dashboard
|
Expand |
---|
title | Acceptance & Project Closure |
---|
|
Once the Project is implemented, make sure to finalize the project in an Acceptance Document. View file |
---|
name | Acceptance document-Project.docx |
---|
| A successful project delivery is celebrated with a glass of Belgian beer, after we received the delivery sign-off. |
Indoor Air Quality related data types:
Expand |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "co2", // string: co2 for carbon dioxide sensor
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "555.5" // string: measured value of CO2 in the air (parts per million)
// expressed as double with dot as decimal separator
} |
|
Expand |
---|
title | TVOC (Total volatile organic compounds) |
---|
|
Code Block |
---|
{
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "voc", // string: voc for volatile organic compounds
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "1.0" // string: measured value of VOC in the air (parts per billion)
// expressed as double with dot as decimal separator
} |
|
Expand |
---|
|
Code Block |
---|
| {
“device”: "<unique_device_id>", // string: unique id of the device
“type”: "radon", // string: radon sensor
“timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
“value”: "19.0" // string: radon level measured is Becquerels per cubic meter, Bq/m3
// expressed as double with dot as decimal separator
} |
|
Info |
---|
Best practice is to test this in a sandbox environment locally first |
How to access
Select “Add New”
Tenant ID will be filled in based on the environment that you logged in to
Fill in Source ID with a unique name, referring to your external data source
Note |
---|
In Source ID field, only use alphanumeric values. The Source ID will later be used as a component of the device IDs. |
(Optional) Fill in a description, detailing what kind of data will come through the external data source
Copy the provided webhook URL + Authorization token to create the webhook in the external data source towards Spacewell Workplace
Make sure to enable your setup in Workplace
Image Added Info |
---|
It’s possible to refresh the Authorization Token in Studio. Remember that this new token now also needs to be updated in the 3rd party platform. |
Test your setup
Once the webhook is created in the 3rd party database with above provided URL and token, make sure to test the connection.
This step is to be performed by the party that wants to send data to Spacewell Workplace.
Verify in a tool like Postman if your setup works:
In case request is not successful, the endpoint returns 4xx-5xx status codes depending on the occurred issue.
In case of successful request, the endpoint returns 200 status code with an empty body.
Image AddedCheck below chapter “Troubleshooting” in case of doubts.
Next steps
To create custom Device Types and configure your third party sensors in Workplace, see Custom Device Types
FAQ
Expand |
---|
title | What if the sensor does not regularly send data? Is it possible to copy data in timeslots? |
---|
|
Depending on the kind of sensor, they might not send heartbeats or data regularly. If they send data and then only send a message upon value change, you might find yourself with bits and pieces of data (eg 1 time slot of 15 minutes with data about temperature, and nothing the rest of the day), which would cause confusion when you try to read the dashboards. To work around this, you can opt to have Spacewell copy the data, per generic endpoint / device type level for any desired amount of time. For example for the sensor type "Generic PIR" we could set a "copy in further time slots" and this value would be valid for all Generic PIR sensor values, which come to us for your tenant. Of course, the data is only copied until new data comes in again. So if a value comes in on Monday at 9am, and the configuration says "copy for 7 days", and on Wednesday at 8am a new value comes in, then from Wednesday at 8am the new value is taken for 7 days, or until a new value comes in. Info |
---|
Consequently, Workplace will only visualize or report if a sensor is NOT transmitting data after the configured time has expired (in previous example: after 7 days). |
Reach out to your Account Manager to set this up. |
Expand |
---|
title | Is it possible to connect multiple external data sources through the same endpoint in Workplace? |
---|
|
It's possible to re-use the external data source information (Authentication token + URL). So if devices have the same behavior, but are linked to different external data sources, it’s possible to only set up 1 endpoint in Studio, and have the 2 external data source send data to that same Workplace endpoint. Info |
---|
Within 1 vendor ID, sensor IDs need to be unique and prepended with the vendor ID. Combining device IDs from multiple third parties in 1 External Data Source, raises the potential risk of conflicts. |
|
Expand |
---|
title | Is it possible to send data with a timestamp that deviates from today's date? |
---|
|
Technically, Workplace can accept data with timestamps from 5 years in the past and 1 year in the future. But of course this data will not be included in any calculations or live data view. Only time slots for the previous day are calculated. So, even we store the data, it will not be visible anywhere. So best practice is to just send data with a (near) real time timestamp. |
Expand |
---|
title | Is it possible to delete an External Data Source? |
---|
|
In Workplace, it’s possible to disable an External Data Source, but you can’t delete. Deletion would impact devices that have a link with this External Data Source. |
Troubleshooting
Expand |
---|
title | Not getting a 200 status code (indicating succesful connection)? |
---|
|
Make sure the following configuration is in place: the connection details used in the external data source are the ones provided by Spacewell verify the authorization code has not been updated / changed in Workplace adhere to the required supported data types & payload
|
Expand |
---|
title | Successfull connection message, but sensor is not loading any data |
---|
|
Make sure the following configuration is in place: |
Expand |
---|
title | Seeing "Created by Spacewell" and not able to refresh the token or enable/disable the external data source? |
---|
|
See “Legacy Generic End-Point Set-up” chapter below |
Expand |
---|
title | Not able to refresh the token or enable/disable the external data source? |
---|
|
For security reasons: If a user logs in with a multi-tenant account, they are not able to make any changes to any external data sources. |
Legacy Generic End-Point Set-up
In the past, some external data sources were connected to Spacewell through a slightly different format. Because of that, there is a limitation only for the legacy / old generic endpoints:
The old / legacy Generic Endpoints will be shown in Studio with the label 'Created by Spacewell'
User will not be take actions (Refresh Authorization token, Enable / Disable will all be greyed out)
User can only View, and Copy URL / Authorization token.
To Enable / Disable or Refresh authorization token, reach out to your Account Manager.
Image Added
Search