How KODE OS collects sensor and non-sensor data from your connected systemsData collection is the continuous process of gathering data from connected external systems. Once devices and points are discovered and registered, KODE OS begins collecting their data according to configured schedules and protocols.
Collection methods
KODE OS supports two primary collection methods. The method depends on the integration’s communication protocol and the external system’s capabilities.Scheduled pull (polling)
KODE OS periodically connects to the external system to request the latest data. The polling interval is configurable per connector and per entity type. Protocols used: REST, SOAP, SDK, OpenSSL/TCP, SFTP/FTP, Modbus/BACnet Each integration defines default, minimum, and maximum polling intervals for its entity types. You can adjust the interval within the allowed range from the connector’s entity configuration.Real-time push
The external system sends data to KODE OS when events occur, without KODE OS asking for it. Protocols used: Webhooks, MQTT, WebSocket Push-based integrations receive data as soon as it is available, which lowers latency compared to polling. The external system must send data to the correct KODE OS endpoint.Hybrid
Some integrations support both pull and push. For example, an integration might use webhooks for real-time point history and polling for periodic alarm collection.Collection modes
The collection mode determines how KODE OS interprets the data it receives. Each integration entity uses one of three modes:Snapshot
A single view of the current state at a specific moment. Each collection cycle captures the full current value of all points. Use case: Occupancy counts, current temperature readings, door statusDelta
Only changes since the last collection are reported. KODE OS stores the differences between polls. Use case: Controller data from BMS systems such as Niagara, where only changed values need to transferHistorical
A complete log of past values over a time range. The external system provides timestamped historical data, which KODE OS ingests in bulk. Use case: Historical backfill, energy meter readings, audit logsData types
Sensor data
Time-series data from physical sensors on devices. These are measurable, often timestamped values from device points.Non-sensor data
Structured data from external systems that is not generated by a physical sensor but matters for building operations.Polling intervals
Each integration defines its polling schedule with three parameters:
Polling intervals are configured per entity type within a connector. For example, a Niagara connector might poll point history every 30 seconds but alarms every five minutes.
Collection status
You can monitor collection status for each connector from theData Sources page. Status indicators show:
- Up / Active: Data is collecting successfully on schedule
- Down / Error: The last collection attempt failed — check the connector logs
- Paused: Collection has been manually paused
- Disconnected: The connector cannot reach the external system
Troubleshooting
Data is not being collected
Data is not being collected
First, verify the connector shows a successful test connection. Then check that the entities are enabled and the polling interval is configured. If the external system requires re-authentication (for example, expired OAuth tokens), update the connector credentials.
Data appears delayed
Data appears delayed
For pull-based integrations, data freshness depends on the polling interval. If you need more frequent updates, reduce the polling interval within the allowed minimum. For push-based integrations, verify that the external system’s webhook or MQTT configuration points to the correct KODE OS endpoint.
Duplicate data points
Duplicate data points
Some integrations may deliver the same data across overlapping collection cycles. KODE OS deduplicates data based on the point identifier and timestamp. If you see duplicates, check whether the connector’s collection mode matches the external system’s behavior (snapshot vs. delta).