Reference · built on requestConnectorSensors, meters & gateways

Disruptive Technologies

Temperature, humidity, CO2, motion, contact, and water events from Disruptive Technologies sensors via Data Connectors or REST.

About

Disruptive Technologies makes small wireless sensors for temperature, humidity, CO2, proximity, touch, water, motion, desk occupancy, and door contact. A Cloud Connector relays their events to DT Cloud, where DT Studio and a v2 REST API expose projects, devices, and Service Accounts. Data Connectors forward each event to your endpoint as an HTTPS POST, with retries for up to 12 hours.

Through Fibric, an operator subscribes to the events that matter, such as a fridge temperature or a waterPresent state change, and proposes a label change or a connector adjustment. You approve. The change is made once and recorded with the reason.

This is a reference listing. It documents what Fibric would read from Disruptive Technologies and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • temperature, humidity, co2, pressure, motion, contact, deskOccupancy, and waterPresent events, each with eventId, targetName, eventType, data, and timestamp
  • objectPresent and touch events, plus objectPresentCount and touchCount counters that keep incrementing across heartbeats
  • networkStatus on every heartbeat and batteryStatus about once a day per sensor
  • Cloud Connector connectionStatus, ethernetStatus, and cellularStatus changes
  • Data Connector deliveries with the event, chosen labels, and metadata of deviceId, projectId, deviceType, and productNumber
  • Live events through GET /v2/projects/{project}/devices:stream as Server-Sent Events or line-separated JSON
  • Projects and devices listed through the v2 REST API, paged 100 at a time with pageToken

Proposed actions

  • Target capability: propose a device label through POST /v2/projects/{project}/devices/{device}/labels
  • Target capability: propose a Data Connector through POST /v2/projects/{project}/dataconnectors with type HTTP_PUSH, an events filter, and labels to include
  • Target capability: propose pausing a Data Connector by setting its status to USER_DISABLED, or resuming it to ACTIVE
  • Target capability: propose moving a device between projects, which REST and DT Studio both allow

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Catch a cold room drifting warm

    Temperature events from a probe sensor arrive through a Data Connector. The operator compares them with the range you set and proposes the alert and the work order, with the eventId chain as evidence.

    With Cold Room Watch

  • Respond to water where it should not be

    A waterPresent change to PRESENT arrives within seconds. The operator proposes a dispatch to the room named in the device labels and records when the state returns to NOT_PRESENT.

    With Leak Response

  • Know which sensors have gone quiet

    networkStatus heartbeats and batteryStatus events feed a health list. The operator proposes a replacement for any sensor whose heartbeat has stopped or whose battery is reported low.

    With Sensor Health

  • Ventilate on CO2, not on a schedule

    co2 events from the CO2 sensor show which rooms climb during the day. The operator proposes a ventilation change for your approval and notes what the reading did afterwards.

    With CO2 Ventilation

Requirements

  • A DT Cloud project with sensors reporting through a Cloud Connector
  • A Service Account with the project.developer role to create Data Connectors, or project.admin to manage Service Accounts
  • An HTTPS endpoint that returns a 2XX within 10 seconds for Data Connector events
  • For signed deliveries, a Signature Secret on the connector or a check against DT's public JWKS
Authentication
A Service Account key ID, secret, and email, signed into an HS256 JWT and exchanged at https://identity.disruptive-technologies.com/oauth2/token for a bearer token valid one hour; Basic Auth is also accepted.

Limits

  • Events are stored for 30 days by default; longer history needs Extended Data Storage or your own store fed by a Data Connector
  • Data Connector retries use exponential backoff from 8 seconds, capped at 3600 seconds, and stop after 12 hours
  • A stream connection ends after one hour when the token expires, or with a 408 if no events arrive
  • Rate limits are not stated in the developer documentation

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Disruptive Technologies ↗

Questions and answers

How does a Data Connector prove an event came from DT Cloud?
Each POST carries a DT-Asymmetric-Signature header, a JWT signed with ES256 that you check against DT's public JWKS. The legacy X-Dt-Signature header is an HS256 JWT signed with your Signature Secret. Either way, the JWT holds a checksum_sha256 claim to compare with the SHA256 of the raw body.
What happens if my endpoint is down?
DT Cloud retries with exponential backoff, starting at 8 seconds and doubling up to 3600 seconds, for 12 hours. Events that still fail are discarded. If only non-2XX responses come back for a long time, the Data Connector is disabled automatically. Use eventId to drop duplicates.
How long does an access token last?
One hour. You build a JWT with iat, an exp at most 3600 seconds later, aud set to the token endpoint, and iss set to the Service Account email, then post it with grant_type urn:ietf:params:oauth:grant-type:jwt-bearer. Cache the token and reuse it until it expires.
Ask about Disruptive Technologies

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.