Connected Water Filter IoT Integration

Request

The assignment was deceptively narrow: connect a water filter to a mobile app.

In reality, the hard part was not drawing a Bluetooth or Wi-Fi line between two endpoints. The hard part was making an existing appliance behave like a trustworthy connected product without reopening the hardware program. The filter already had a device layer inside it. What it did not have yet was the firmware discipline and app communication model required for real customers using it in real kitchens.

That changed the delivery shape immediately. We were not inventing a concept for a future device. We were defining the software layer that would let an existing filter behave coherently across setup, control, maintenance, and recovery.

Context

Consumer IoT products are usually judged in the first few minutes.

If setup is confusing, users assume the whole product is unreliable. If the app says a command succeeded but the appliance behaves differently, trust collapses even faster. With a countertop appliance, this problem is even more visible because the device is part of a daily routine. The user is not “testing technology.” They are trying to get water and understand whether the product is healthy.

The client already had the physical product. The missing piece was the software handshake between the mobile experience and the filter itself. That handshake needed to cover configuration, state sync, maintenance information, and predictable recovery after disconnects or partial failures.

Strategy

We structured the work around three principles.

First, we preserved the existing hardware boundary. The project would succeed faster by stabilising the software around the installed controller than by reopening PCB decisions.

Second, we treated protocol design as product design. Commands, acknowledgements, errors, and maintenance counters were not low-level implementation details. They were the thing the customer would experience as “this device works” or “this device is flaky.”

Third, we separated first-time provisioning from everyday control. Those are different user moments with different failure patterns, and they should not share the same assumptions just because they happen on the same appliance.

Operational Insights

Several practical realities shaped the solution.

• The onboarding path had to be short enough for a household product, not a lab tool.
• Maintenance state mattered almost as much as command execution. Consumable life, resets, and fault signals are central to how a filter product is understood.
• The app could not be allowed to drift into optimistic fiction. Device acknowledgement had to be part of the control contract.
• Reconnect behavior mattered because home connectivity is not perfect, and appliance software has to recover quietly rather than forcing the user to start over.

These insights pushed us toward a runtime that was strict about state transitions and forgiving about transient connectivity problems.

Solution

We built the missing software bridge around the filter.

At the embedded layer, we developed the ESP32 firmware responsible for device setup, command handling, state reporting, and recovery behavior. At the product layer, we defined the communication contract used by the mobile app so that every meaningful action had a clear path from user intent to device acknowledgement.

That meant the system could support the moments that actually matter in a connected appliance:

• provisioning the filter into a usable state
• changing device behavior from the app
• reflecting live filter status back into the UI
• tracking maintenance and consumable state coherently
• recovering after dropped sessions without confusing the user

The important outcome is that the connected experience was not added as a thin wrapper. The firmware and app logic were designed together so the filter could act like one product, not like hardware and software stitched together after the fact.

Architecture

The architecture was intentionally narrow. We did not try to turn the filter into a generic IoT platform. We created a disciplined control loop between the app, the firmware, and the filter logic already in the appliance.

Three layers had to stay aligned:

• Provisioning, so the device could be claimed and configured once without creating a fragile setup ritual.
• Runtime control, so user actions in the app translated into confirmed behavior on the device rather than optimistic UI updates.
• Maintenance state, so filter-life information, alerts, and resets stayed coherent across the embedded runtime and the mobile experience.

This is where the ESP32 mattered most. It became the authority for device behavior, while the mobile app became a reliable interface to that authority instead of a disconnected dashboard.

Delivery Decisions

Several delivery choices kept the project commercially sensible.

We preserved the existing device platform instead of pushing the client back into a new hardware iteration. That shortened the path to a usable connected product and kept the work focused on the layer customers would actually feel.

We also treated acknowledgement and recovery as first-class behavior. In connected appliances, “mostly works” is not good enough, because intermittent state drift shows up as customer confusion and support overhead. The firmware therefore needed predictable retries, clear state ownership, and a clean path for surfacing failures rather than silently hiding them.

Finally, we made the maintenance model explicit. Water filters are not only about on and off states. They are about service intervals, consumable health, and understanding when the product needs attention. Building that into the device-app contract made the mobile experience materially more useful.

Tech Stack

Results

• The client gained a connected software layer without reopening hardware development, which kept delivery focused and commercially efficient.
• The app and filter could operate from a shared state model, reducing the ambiguity that usually makes consumer IoT products feel unreliable.
• Provisioning, everyday control, and maintenance behavior were shaped as one product loop, not as separate engineering tasks.
• The ESP32 controller became a stable foundation for the next stage of the product, including richer support tooling, OTA rollout discipline, and smarter maintenance workflows.