When we started building Cohera, we made a deliberate choice: the platform would work with any sensor, from any manufacturer. This decision shaped everything that followed, and the lessons we learned along the way have implications for anyone building industrial IoT solutions.

Why Sensor-Agnostic Matters

Industrial environments are messy. Walk into any manufacturing facility, and you'll find equipment from different eras, different vendors, and different technological generations. Some machines have modern IoT capabilities. Others were built before the internet existed and have been retrofitted with sensors over the years.

A platform that only works with specific sensors forces customers into difficult choices: replace working equipment, maintain multiple parallel systems, or forego monitoring entirely. None of these options serve the customer well.

Sensor-agnostic design flips this dynamic. Instead of the platform dictating what sensors you can use, you choose the best sensor for each application, and the platform adapts.

The Technical Challenge

Building a sensor-agnostic platform is harder than building one for specific sensors. When you control the sensor, you control the data format, the sampling rate, the calibration, and the communication protocol. Everything is predictable.

With arbitrary sensors, you face a combinatorial explosion of possibilities:

  • Physical interfaces: Analog signals, digital protocols (I2C, SPI, UART), industrial standards (4-20mA, Modbus, OPC-UA)
  • Data types: Temperature, pressure, vibration, flow, humidity, chemical composition, and hundreds of others
  • Sampling requirements: Some sensors need millisecond precision; others are fine with hourly readings
  • Calibration needs: Every sensor type has different calibration requirements and drift characteristics

Our Architectural Approach

After considerable iteration, we converged on an architecture with three key principles:

1. Abstraction at the Edge

The complexity of sensor diversity is handled at the edge node, not in the cloud. Each edge device runs a sensor abstraction layer that normalizes data before it leaves the device. This means:

  • The central platform sees a consistent data model regardless of sensor type
  • New sensor types can be added without changing the core platform
  • Data processing and analytics work the same way across all sensors

2. Configuration, Not Code

Adding a new sensor type shouldn't require writing code. We built a configuration system where sensor characteristics are described declaratively: what physical interface it uses, what data type it produces, how to interpret its output, what calibration it needs.

This means customers can add new sensors without waiting for us to ship a software update. It also means we can rapidly expand sensor support based on customer needs.

3. Graceful Degradation

Not every sensor supports every feature. Some provide raw analog values; others have sophisticated on-board processing. Some support remote configuration; others are completely passive.

The platform is designed to work with whatever the sensor provides. If a sensor doesn't support a feature, that feature gracefully degrades rather than breaking the entire integration.

Lessons Learned

Several years into this journey, here's what we know now that we wish we'd known at the start:

Standards Help, But Aren't Enough

Industrial communication standards like OPC-UA and MQTT are valuable, but they solve only part of the problem. They standardize how data moves, not what the data means. You still need a semantic layer that understands that this temperature reading is from a bearing and that one is from ambient air.

Calibration Is Critical

The difference between a sensor reading and a meaningful measurement is calibration. This turned out to be more complex than we initially anticipated. Different sensors drift differently. Environmental factors affect calibration. In regulated industries, calibration itself needs to be documented and auditable.

Edge Computing Is Non-Negotiable

We initially considered a cloud-first architecture where edge devices were simple data collectors. Real-world deployments quickly showed this wouldn't work. Network reliability in industrial environments is imperfect. Latency for real-time applications is unacceptable. Data volumes for high-frequency sensors are unsustainable.

Edge computing isn't just an optimization; it's a requirement for a platform that works in real industrial conditions.

The Payoff

The investment in sensor-agnostic architecture has paid dividends we didn't fully anticipate:

  • Faster deployments: Customers don't wait for sensor-specific development; they configure and deploy
  • Better economics: Customers choose sensors based on price and performance, not platform compatibility
  • Future flexibility: As better sensors come to market, customers can adopt them without platform changes
  • Unified analytics: All sensor data flows through a common model, enabling cross-sensor analytics that siloed systems can't match

Implications for the Industry

The sensor-agnostic approach isn't just a product decision; it's a bet on where the industry is heading. The proliferation of sensor types is accelerating. New sensing modalities are emerging. Industrial environments are becoming more, not less, heterogeneous.

Platforms built around specific sensors will struggle to keep up. Those designed for interoperability from the start will have a structural advantage as the market evolves.

If you're evaluating industrial IoT platforms or building your own, I'd encourage you to think carefully about how sensor diversity is handled. The architecture decisions you make today will determine your flexibility for years to come.