Technical Brief: Integrating Third-Party Sensors — BLE, Cellular, Satellite, and 200+ Vendors

Overview

No IoT project uses sensors from a single vendor. Real deployments combine temperature sensors from one manufacturer, vibration sensors from another, and legacy industrial equipment communicating over protocols designed before IoT was a category. The platform that manages all of it needs to work with whatever communicates, not just the devices on an approved list.

VX-Olympus takes a protocol-first approach to sensor integration. Rather than maintaining integrations with specific device models, VX-Olympus integrates with the communication protocols — BLE, cellular, satellite, LoRaWAN, Modbus, OPC-UA, HTTP, MQTT, CoAP — and provides a device profile and payload decoder architecture that handles device-specific encoding at the application layer.

This brief covers the integration model for each major connectivity technology, the device profile and payload decoder system, and practical considerations for adding new sensors to a VX-Olympus deployment.

Integration Architecture

The core concept: VX-Olympus doesn’t care about the sensor hardware. It cares about the data arriving at its ingestion layer in a parseable format.

The ingestion layer receives raw payloads. The payload decoder — a JavaScript function stored in the device profile — transforms raw bytes or JSON into named fields with units. Everything downstream of the decoder (rule chains, dashboards, storage) works with the decoded, normalized data.

BLE (Bluetooth Low Energy) Sensors

How BLE Sensors Integrate

BLE sensors broadcast advertisements rather than making direct connections. A BLE gateway (also called a BLE scanner or BLE-to-IP bridge) continuously scans for BLE advertisements in range, collects the packets from all detected BLE devices, and forwards them to VX-Olympus via MQTT or HTTPS.

The BLE gateway acts as a concentrator: one gateway can receive advertisements from 50–200 BLE tags simultaneously. This makes BLE cost-effective for dense sensor deployments.

BLE Use Cases by Range and Environment

Asset tracking (RTLS): BLE tags emit a periodic advertisement containing the tag’s MAC address and optional sensor payload. Multiple BLE readers positioned throughout a facility triangulate or zone-locate the tag. VX-Olympus maps the MAC address to a registered asset.

Environmental sensors: Sensor-equipped BLE devices (temperature, humidity, CO2) broadcast their readings in the advertisement payload. No connection required — the sensor broadcasts continuously, the gateway collects.

Condition monitoring: BLE sensors attached to machinery broadcast vibration, temperature, or shock data. Gateway receives, forwards to VX-Olympus.

BLE Gateway Configuration in VX-Olympus

A BLE gateway registers as a device in VX-Olympus. The gateway’s MQTT topic or HTTPS endpoint is configured with the gateway’s credentials. When the gateway forwards BLE advertisements, VX-Olympus parses the advertisement format (manufacturer-specific data encoded per vendor spec) using a gateway-level payload decoder.

The result is one MQTT-connected gateway managing dozens of BLE sensors — all appearing as individual devices in VX-Olympus with their own telemetry records.

Compatible BLE Sensor Vendors

BLE sensor integration is broadly compatible with any sensor that broadcasts standard BLE advertisements. Vendors with documented device profiles in the VX-Olympus ecosystem include: Minew, Moko Smart, Quectel, Axioma, and others using the iBeacon or Eddystone advertisement formats, as well as sensors with custom manufacturer-specific advertisement data that can be decoded with a custom payload function.

Cellular IoT Devices

Cellular Connectivity Options

Cellular IoT devices connect directly to the internet via carrier networks. The primary cellular technologies used in IoT:

• LTE-M (Cat-M1): Low-power LTE designed for IoT. Supports mobility, moderate data rates (1 Mbps), and extended coverage. Best for asset trackers and mobile devices.
• NB-IoT: Narrowband IoT. Ultra-low power, lower data rate, better deep indoor penetration than LTE-M. Best for stationary sensors in challenging RF environments.
• LTE Cat 1: Standard LTE at reduced speed. Used when higher data rates are needed (video, frequent reporting).
• LTE Cat 4+: Full LTE. Used for data-intensive industrial applications (vibration waveforms, high-frequency sampling).

Cellular Device Integration Models

MQTT over cellular: The device opens a persistent MQTT connection to VX-Olympus’s broker. This is the preferred model for always-on devices with reliable cellular coverage — it provides low-latency bidirectional communication. See the MQTT vs HTTP vs CoAP technical brief for detailed protocol comparison.

HTTPS POST over cellular: The device wakes on a schedule, posts a JSON or binary payload to VX-Olympus’s ingestion endpoint, and returns to sleep. Better for battery-powered devices with infrequent reporting intervals. Higher per-message overhead than MQTT.

SMS-based fallback: Some cellular IoT devices support SMS as a fallback channel when data connectivity is unavailable. VX-Olympus can receive SMS-formatted telemetry through a SMS gateway integration — useful for devices in areas with voice coverage but no data coverage.

Cellular Device Vendors

Devices from Quectel, Geotab, Globalsat, Digital Matter, and other cellular IoT module vendors connect to VX-Olympus through standard MQTT or HTTPS integrations. Device profiles define the expected payload format; payload decoders handle binary or proprietary JSON formats.

SIM management: VX-Olympus does not directly manage SIM cards or carrier contracts. Cellular IoT SIM management (MVNO selection, data pooling, roaming) is handled by the cellular carrier or MVNO partner. Kore Wireless is one carrier-neutral MVNO used in VX-Olympus deployments for multi-country cellular IoT.

Satellite-Connected Devices

When Satellite Is Required

Satellite IoT connectivity covers locations where terrestrial networks (cellular, Wi-Fi, LoRaWAN) are absent or unreliable:

• Remote pipelines, wellheads, mining sites
• Ocean vessels and offshore platforms
• Agricultural operations in rural areas without cellular coverage
• Arctic or remote environmental monitoring stations

Satellite IoT Technologies

Low-orbit satellite networks (LEO): Networks like Iridium and Inmarsat provide global coverage with relatively low latency (seconds to minutes). Devices transmit short messages (typically 20–340 bytes) that the satellite network delivers to a ground station, which forwards to the customer’s endpoint via internet.

Emerging broadband satellite (e.g., Starlink): Provides full internet connectivity at remote locations. Devices connecting via a Starlink terminal can use MQTT or HTTPS just as they would over any internet connection. Latency is higher than cellular (20–100 ms) but data rates support full IoT applications.

Satellite Integration in VX-Olympus

Satellite messages arrive at VX-Olympus through the satellite network operator’s message forwarding service — typically an HTTPS webhook or MQTT broker operated by the satellite network provider. The message delivery path:

1. Device transmits satellite message
2. Satellite relays to ground station
3. Ground station delivers to network operator’s platform
4. Network operator forwards to VX-Olympus via configured HTTPS POST or MQTT
5. VX-Olympus payload decoder interprets the message (usually binary-encoded for bandwidth efficiency)

The integration model is the same as any HTTPS POST device — the satellite network is transparent to VX-Olympus’s ingestion layer.

Modbus and OPC-UA (Industrial Protocol Integration)

Polling-Based vs. Push-Based Integration

Modbus and OPC-UA are polling-based protocols — the client (VX-Olympus’s protocol connector) requests data from the device (PLC, industrial sensor, energy meter) rather than the device pushing data when it changes.

Effective data freshness is determined by the poll interval configured in the VX-Olympus Modbus/OPC-UA connector. A 30-second poll interval provides data refreshed every 30 seconds. For most industrial monitoring use cases, 30-second to 1-minute poll intervals are appropriate. For rapid event detection (machine fault signals), 5–10 second intervals may be needed.

Modbus Integration

VX-Olympus’s Modbus connector supports Modbus RTU (RS-485 serial) and Modbus TCP (Ethernet). Configuration per device:

• IP address / COM port and device address
• Register map: which Modbus registers contain which values, their data types (16-bit unsigned, 32-bit float, bit), and scaling factors
• Poll interval per register group

The register map is the device-specific configuration analogous to the payload decoder for wireless devices. Thousands of industrial device types have Modbus register maps documented in their manuals or available in community databases.

OPC-UA Integration

OPC-UA is a more capable protocol than Modbus — it provides self-describing data models, security, and subscription-based updates (no polling required for event-driven data). VX-Olympus’s OPC-UA connector supports:

• Browse mode: discover the OPC-UA server’s node hierarchy and select nodes to monitor
• Subscription mode: subscribe to OPC-UA nodes for change-based updates (lower network overhead than polling)
• Historical data access: retrieve historical data from OPC-UA servers that maintain it

OPC-UA is the standard for modern industrial equipment: CNC machining centers, robotics, modern PLCs. Older equipment uses Modbus; newer equipment increasingly uses OPC-UA.

Device Profiles and Payload Decoders

The Device Profile

Every device connected to VX-Olympus is associated with a device profile. The profile defines:

• Connectivity type: LoRaWAN, MQTT, HTTP, BLE-via-gateway, Modbus, OPC-UA, satellite
• Payload decoder: JavaScript function that transforms raw input to named fields
• Telemetry model: The expected output fields — name, data type, unit, min/max validation
• Default rule chain: Which rule chain processes telemetry from this device type
• Dashboard template: Which dashboard layout is auto-provisioned for this device type

Payload Decoder Architecture

A payload decoder is a JavaScript function that receives the raw payload (binary bytes, JSON string, or parsed JSON object depending on the protocol) and returns a JSON object with named fields.

Binary decoder example (LoRaWAN temperature + humidity sensor):

function decode(bytes) {
  return {
    temperature: ((bytes[0] << 8 | bytes[1]) - 400) * 0.1,
    humidity: (bytes[2] << 8 | bytes[3]) * 0.1,
    battery_percent: bytes[4]
  };
}

JSON transformer example (device sends JSON but with non-standard field names):

function decode(payload) {
  var data = JSON.parse(payload);
  return {
    temperature: data.tmp,
    humidity: data.hum,
    battery_mv: data.bat
  };
}

Decoder isolation: Payload decoders run in a sandboxed JavaScript environment within VX-Olympus. A decoder crash (syntax error, unhandled exception) logs an error and routes the message to a dead-letter queue — it does not crash the ingestion pipeline.

Device Profile Sharing

Device profiles are portable across tenants within a VX-Olympus instance and can be exported and imported across instances. This enables:

• MSPs who deploy the same sensor models across multiple customers to define the profile once and share it
• The VX-Olympus ecosystem library of pre-built device profiles for common sensors
• Sensor vendors who publish their VX-Olympus device profile as part of their product documentation

Practical Integration Guidance

Adding a New Sensor Type

When integrating a sensor that does not already have a VX-Olympus device profile:

1. Determine the connectivity protocol — what does the sensor use? LoRaWAN, MQTT, BLE, HTTP? This determines the integration path.

2. Obtain the payload specification — the sensor’s datasheet or documentation describes its payload format. For binary payloads, the byte map. For JSON, the field structure.

3. Write the payload decoder — implement the JavaScript decode function in VX-Olympus’s device profile editor. Test it against example payloads from the sensor’s documentation.

4. Define the telemetry model — specify the expected output fields: name, type, unit, expected range. VX-Olympus validates decoded telemetry against the model and flags out-of-range values.

5. Test with a live device — provision one device, transmit test data, confirm the decoded values appear correctly in the device’s telemetry view.

6. Create the rule chain and dashboard template — once the telemetry model is defined, rule chains and dashboards can be built against the named fields.

Multi-Protocol Deployments

For deployments with sensors on multiple connectivity technologies, VX-Olympus handles all protocol paths simultaneously. A factory deployment might have:

• OPC-UA data from modern CNC machines
• Modbus data from legacy PLCs
• LoRaWAN data from wireless temperature sensors
• BLE data from asset tags on tooling and fixtures
• MQTT data from a gateway aggregating multiple field sensors

All data arrives in VX-Olympus through different protocol paths, is decoded through device-specific decoders, and normalized to the same telemetry model. The rule engine and dashboard layer see consistent data regardless of the protocol it arrived on.

Conclusion

VX-Olympus’s approach to third-party sensor integration is protocol-first: support the communication protocol, handle the device-specific encoding at the payload decoder layer, and normalize everything to a consistent telemetry model. This architecture works with virtually any sensor that communicates digitally — the constraint is the protocol, not the sensor hardware brand.

For deployments with heterogeneous device ecosystems — which describes most production IoT environments — the platform fits the sensors the operation needs, not the other way around.

Talk to our team about integrating your specific sensor inventory with VX-Olympus.