Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Difficulty: expert

Content

Table of Contents
minLevel1
maxLevel1

Learning Objectives

After reading this article, you’ll be able to:

  • Identify which Generic Endpoints data types are supported by Spacewell WorkplaceManage a project to set up Generic Endpoints

  • Configure webhook & authorization token to connect your external data sources to Workplace


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:

  • EU: <https://bohemian.eu1.cloud.cobundu.com/generic/<sensor_vendor>/data>

  • US

    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.

    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.

    Supported data types & payload

    Space occupancy related data types:

    Expand
    titlePIR: space occupancy
    Code Block
    languagejson
    {
    "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
    titleHeadcount: for measuring number of people
    Code Block
    languagejson
    {
    “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
    titlePulse: for door counters sending pulse values
    Code Block
    languagejson
    {
    “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
    titleCount: for door counters sending accumulated values
    Code Block
    languagejson
    {
    “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
    titlefootfall-in pulse
    Code Block
    languagejson
    {
    “device”: "<unique_device_id>", // string: unique id of the device
    “type”: "footfall-in-pulse", // string: footfall in pulse sensor
    “timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
    “value”: "5" // string: count of in pulses expressed as unsigned integer
    }
    Expand
    titleFootfall-out pulse
    Code Block
    languagejson
    {
    “device”: "<unique_device_id>", // string: unique id of the device
    “type”: "footfall-out-pulse", // string: footfall out pulse sensor
    “timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
    “value”: "3" // string: count of out pulses expressed as unsigned integer
    }
    Expand
    titleParking
    Code Block
    languagejson
    {
    “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
    }

    Comfort related data types:

    Expand
    titleTemperature
    Code Block
    languagejson
    {
    “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
    titleHumidity
    Code Block
    languagejson
    {
    “device”: "<unique_device_id>", // string: unique id of the device
    “type”: "humidity", // string: humidity sensor
    “timestamp”: "2020-09-22T14:27:36Z", // string: ISO 8601 date and time
    “value”: "75.5" // string: value in percentage 0-100
                         // expressed as double with dot as decimal separator
    }

    Indoor Air Quality related data types:

    Expand
    titleCO2
    Code Block
    languagejson
    {
    “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
    titleTVOC (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
    titleRadon
    Code Block
    languagejson
    {
    “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
    
    }

    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
    title1.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
    title1.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
    title1.3 Setup the location master data

    Make sure the master data (buildings, floors, locations) are already uploaded.

    Expand
    title1.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
    nameGeneric 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
    title2.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
    title2.2 Handshake on what to do

    Agreement from both parties on the tasks ahead.

    Step 3 - Development & testing

    Expand
    titleDevelopment

    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
    titleTesting

    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
    titleSensor installation (optional)

    If not yet installed, sensors need to be installed according to 3rd party installation instructions.

    Expand
    titleSensor 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
    titleConfiguration 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"

    1. Go to your environment (https://studio.cobundu.com ) and log in

    2. Select the location, where you can manually add a sensor via "Add New Device"

    3. 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

      1. 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

    4. Fill in the device ID: a "Device ID" prefix will be given by the Spacewell development team

    5. Give a meaningful name (eg customer_floor number_area) in Device Name.

    6. 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
    titleSensor mapping

    Go to your environment and change the location ID for each Sensor in Sensor Management.

    Step 5 - Validation & acceptance

    Expand
    titleValidation checks

    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
    titleAcceptance & Project Closure

    Once the Project is implemented, make sure to finalize the project in an Acceptance Document.

    View file
    nameAcceptance document-Project.docx

    A successful project delivery is celebrated with a glass of Belgian beer, after we received the delivery sign-off

    Configure the connection between External Data Source and Workplace

    How to access

    1. Select “Add New”

    2. Tenant ID will be filled in based on the environment that you logged in to

    3. Fill in Source ID with a unique name, referring to your external data source

    4. (Optional) Fill in a description, detailing what kind of data will come through the external data source

    5. Copy the provided webhook URL + Authorization token to create the webhook in the external data source towards Spacewell Workplace

    6. Make sure to enable your setup in Workplace

    Image Added

    Test your setup

    • 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 Added

    Check below chapter “Troubleshooting” in case of doubts.

    Configure the sensors in Workplace

    Image Added

    1. Go to your environment (https://studio.cobundu.com ) and log in

    2. Select the location, where you can manually add a sensor via "Add New Device"

    3. 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

      1. 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

    4. Fill in the device ID: a "Device ID" prefix will be given by the Spacewell development team

    5. Give a meaningful name (eg customer_floor number_area) in Device Name.

    6. 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).

    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.

    Custom: 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).

    Reach out to your Account Manager to set this up.

    Troubleshooting

    Expand
    titleNot 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
    titleSuccessfull connection message, but sensor is not loading any data

    Make sure the following configuration is in place:

    • sensor ID created in Workplace adheres to the described logic

    • sensor data is send according to the required supported data types & payload

    • relevant sensor data channels are enabled for the device

    Expand
    titleSeeing "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

    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:

    1.  The old / legacy Generic Endpoints will be shown in Studio with the label 'Created by Spacewell'

    2. User will not be take actions (Refresh Authorization token, Enable / Disable will all be greyed out)

    3. User can only View, and Copy URL / Authorization token.

    To Enable / Disable or Refresh authorization token, reach out to your Account Manager.


    Search

    Live Search