At first glance, FilterIQ looks simple.
A device. Some configuration. A way to monitor what it is doing.
In reality, it is the result of hardware engineering, embedded software, cloud architecture, visualisation, and early work around ML and AI coming together in one industrial platform. That gap between perception and reality is what made FilterIQ such an important product to develop.
Built for sectors including cement, energy, aggregates, foundry and food processing, FilterIQ was designed to perform in demanding industrial environments where reliability, visibility and adaptability matter.
It Starts Simple. It Never Stays That Way.
The original idea was straightforward: control and monitor a device through two interfaces — UART locally and AWS remotely.
What appeared simple at the outset quickly became more complex in practice. Making those interfaces work reliably across development, production and real-world deployment required far more than basic connectivity.
As the product evolved, the challenge became creating a system that could connect device control, cloud communication and industrial conditions in a way that was scalable, robust and maintainable.
Interfaces Are Where Complexity Lives
From the beginning, FilterIQ had two control paths: UART and AWS.
Each worked independently, but together they created friction. UART used an AT-style protocol, while AWS used JSON, making development, testing and long-term support more complicated than they needed to be.
A key decision was to unify communications under a single JSON-based architecture. That created a more consistent foundation and made the system easier to understand, extend and support.
Tooling Isn’t a Nice-to-Have. It Becomes the System
What started as a simple UART interaction tool did not stay that way for long.
Over time, that tooling expanded to interface directly with AWS and became central to how the wider system operated. It also helped shape the cloud architecture, including the way AWS Lambda workflows communicated with devices and handled data.
One of the clearest lessons from FilterIQ was that tooling is not separate from the system. In connected industrial products, it often becomes part of the system itself.
Industrial Reality Changes Everything
Early development can often be shaped by assumptions from standard commercial product design.
Industrial environments change that completely. Creepage and clearance matter. Electrical noise is constant. Voltage spikes are expected rather than exceptional.
That meant FilterIQ had to be designed for real operating conditions, not ideal ones. This was especially important for sectors such as cement, energy, aggregates, foundry and food processing, where harsh environments are part of day-to-day operation.
The Field Will Break Your Assumptions
Field trials confirmed that no two deployments are ever exactly the same.
Each site presented different installation constraints, electrical conditions and operating behaviours. A solution that worked perfectly in one location could behave differently in another.
For that reason, FilterIQ could not be built as a fixed one-size-fits-all product. It had to be adaptable and robust by default.
The Bugs That Matter Don’t Show Up When You Want Them To
Some of the hardest issues did not appear during planned testing.
One of the most difficult faults appeared only intermittently, sometimes weeks apart, making it hard to reproduce and even harder to confirm when it had been resolved.
The answer was better observability. Remote debugging capability was introduced in the field using tooling built around a GDB server connected to deployed devices. That made it possible to inspect the system at the point of failure and played a key role in resolving the issue.
What I Took Away From It
What stood out most was not one single technical decision, but the process of bringing multiple technologies together into one working system.
That involved constant trade-offs between device and cloud, flexibility and performance, simplicity and robustness.
Those decisions do not have fixed answers. They depend on the environment, the constraints and how the product evolves over time. That is what made the development of FilterIQ both challenging and rewarding.
Final Thought
But beneath that simplicity is a product shaped by multiple systems, disciplines and lessons learned through real development and real deployment.
FilterIQ may look simple.
That is true of many industrial products that work well in the real world. What appears straightforward on the surface is often built on thoughtful engineering, strong architecture and the ability to make hardware, software and cloud systems work together effectively.
