Building a Smart Aquarium App on Real Embedded Hardware: How We Built EHEIM Digital Connect

Most app development mistakes are recoverable. A slow query gets optimised, a confusing screen gets redesigned, a missed edge case gets patched in a hotfix. Building the control app for connected aquarium hardware doesn't offer that margin the same way — get the connectivity layer wrong and a filter, heater, or dosing system can be left in an unknown state for hours, with consequences for living animals that a software update can't undo after the fact. That's the environment we build in as the development partner behind EHEIM Digital Connect, the companion app for EHEIM's connected aquarium hardware ecosystem.

This is the honest story of what it takes to build an IoT control app for real embedded hardware — built in Android Studio, with device-side integration tested on Orange Pi and Raspberry Pi boards — for a client where reliability isn't a feature, it's the entire product.

EHEIM had the hardware. We built the software layer that ties it together

EHEIM has been building aquarium hardware since 1949 — filters, feeders, lighting, and water-control systems trusted by hobbyists and professionals in dozens of countries. Their Digital line turned that hardware into a genuine IoT ecosystem: pH controllers, smart feeders, connected filters, LED lighting, and CO2 systems, each capable of reporting its own status and accepting remote commands. The hardware engineering was EHEIM's core competency, built over 75 years. What was missing was the layer that makes a shelf of individually smart devices feel like one coherent system to the person who owns them — and that's the software we were brought in to build, as EHEIM's development partner on the app.

That distinction matters for how we approached the brief. We weren't asked to build a demo of what IoT could look like. We were asked to build the control surface for hardware that's already manufactured, already shipping, and already trusted by customers who've been buying EHEIM equipment for decades. The software had to earn that same trust immediately.

Designing for "this is a living ecosystem," not "this is a device list"

The single design principle that shaped every screen: users don't manage a filter, they manage the health of their aquatic ecosystem. A pH swing or a filter failure has consequences measured in hours, for animals that can't self-correct — so the interface has to carry that weight without ever feeling alarming, or worse, easy to ignore.

We translated that into five explicit UX values we designed every screen against: clarity — no guesswork, status reads as binary, "All Good" or "Action Required," nothing ambiguous in between. Control — granular override available for aquascaping experts, without intimidating a first-time smart-filter buyer. Visibility — data visualised through ambient colour and intuitive flow animations, so a glance at the phone tells you the tank's state without reading a paragraph. Consistency — a unified design language across hardware spanning three generations of EHEIM products, some considerably newer than others. And confidence — confirmations and guided setup throughout, because reducing technical anxiety was as much a design goal as reducing clicks.

The information architecture followed the same principle. Instead of a flat device inventory bolted onto a settings menu, we built the IA around Connected Devices, Configuration, and Account — with Device Details, Maintenance Hub, and Smart Scheduling as the working layers underneath. Smart Aquarium Networking — the screen showing every connected device across a household's network, from pH controllers to feeders, each tagged to its own local or cloud connection — became the app's home screen, because that's genuinely the first thing an owner wants to see when they open the app.

Why test on Orange Pi and Raspberry Pi instead of just simulators?

The core engineering risk in any IoT control app isn't the UI — it's the connectivity layer between the app and the physical device. A simulator will tell you your code compiles. It won't tell you what happens when a real embedded board drops a Wi-Fi connection mid-command, or how your pairing flow behaves against actual device firmware instead of a mocked response.

For device-side integration and testing, we built and validated against real embedded targets — Orange Pi and Raspberry Pi boards standing in for and bridging to EHEIM's Digital hardware — inside Android Studio. That let us test pairing, real-time status flows, and command reliability against actual embedded behaviour rather than an idealised mock. QR-code and network-search pairing — scan a code on the device, or search the network for EHEIM Digital devices — was built and hardened this way, because setup friction is the single biggest churn risk in any connected-hardware product: if pairing a new device is confusing or unreliable, the rest of the app's quality doesn't matter.

This is also where we'd point anyone evaluating a partner for embedded or IoT work: hire senior engineers who've actually shipped against real hardware, not just consumed a vendor SDK's documentation. The gap between "the API works in the demo" and "the connection survives a dropped network on someone's actual home router" is where most connected-hardware products fail, and it's only visible if you test against the real thing.

What happens when the connection drops mid-command?

Because the hardware being controlled includes filtration, heating, and dosing systems — equipment with real consequences if it's left in an undefined state — we designed the connectivity layer so a lost network connection degrades gracefully rather than leaving critical hardware uncertain. That's a deliberate architectural stance, not a fallback bolted on after a bug report: the app has to assume connectivity will fail sometimes, and design for what the hardware does in that gap, not just for the happy path where the network never drops.

Device communication is encrypted end to end, consistent with EHEIM's position as a premium, trusted brand in a market where cheap, insecure connected gadgets are the norm rather than the exception. In consumer IoT specifically, security isn't a checkbox for a compliance audit — it's part of what "premium hardware brand" has to mean once the product includes a network connection.

The visual system: built on EHEIM's own legacy, not a generic app template

We built the visual design system on EHEIM's existing legacy of industrial precision rather than reaching for a generic Material Design template — a palette anchored on EHEIM's brand red and a clear action blue against a near-black "EHEIM Dark" for headings and surfaces, with explicit success and warning states so the "no guesswork" principle is enforced by colour, not just copy. A control app for premium hardware should look like it belongs to that hardware, and that only happens if the design system starts from the brand's own visual language instead of a framework's defaults.

What building EHEIM Digital Connect taught us

Embedded and IoT app development is a different discipline from typical mobile development, and it shows up in testing methodology before it shows up in code. Simulators tell you the UI works. Real hardware — Orange Pi, Raspberry Pi, or the manufacturer's own boards — tells you the product works.

Reliability design has to include the failure case, not just the happy path. For hardware with real-world consequences, "what does the device do when the connection drops" is as important a design question as "what does the button do when you tap it."

A device list is not an information architecture. Structuring the app around how the user actually thinks about their system — an aquarium's health, not a shelf of gadgets — is what separates a control app people trust from one they tolerate.

A brand with decades of hardware trust deserves a software layer that looks like it belongs to that brand. Generic templates are faster to ship. They also don't extend 75 years of trust the way a bespoke design system, built from the brand's own visual language, actually does.

Thinking about building an IoT app or embedded software product?

If you're bringing connected hardware to market — consumer IoT, industrial monitoring, smart building systems — the software layer is where trust is won or lost, and it has to be tested against real embedded behaviour, not just simulators, before it ships. That's the standard we built to on EHEIM Digital Connect.

We're a development partner for hardware brands building the software layer on top of connected products — Android and embedded integration, tested on real hardware including Orange Pi and Raspberry Pi, not just SDK documentation. If you need senior engineers who've actually shipped against physical devices, we're happy to give you an honest read on your build before anyone quotes a number. Tell us what you're building.

EHEIM Digital Connect gives owners real-time control across filtration, lighting, temperature, CO2, feeding, and water quality, with a unified design system spanning three generations of EHEIM Digital hardware and more than 75 years of hardware trust behind it. Read the full case study →