System of a Daun

Why this project exists

Much of the systems work I do professionally is proprietary and cannot be shown publicly. I built System of a Daun to demonstrate that the underlying capability is not tied to one company, one machine type, or one existing product.

The domain is different, but the systems problem is familiar: identify the physical entities, determine what should be observed, define device and data relationships, and build the software required to operate the resulting system.

This project is evidence that I can reproduce that capability independently from first principles.

Live plant line

The feed below is pulled from the production public API — the same operational surface the platform exposes for tenant status.

What I built

Physical observation

ESP32 probes collect calibrated soil-moisture readings on configured intervals.

Repurposed Android phones act as edge monitoring devices, capturing scheduled plant images, optional illuminance readings, and device heartbeats.

Multiple probes and phones can be provisioned and assigned without custom development.

Operational context

The platform models tenants, areas, plants, devices, assignments, observations, images, and assessments.

Devices are managed independently from the plants they monitor, allowing hardware to be replaced, reassigned, or scoped to one or several plants.

The system distinguishes current readings, stale telemetry, last device contact, and devices that have not yet reported.

Historical record

Telemetry and image observations are stored over time and presented together at the plant level.

The web application exposes current state, historical trends, photographic history, and scheduled day-over-day or week-over-week comparisons.

Bounded interpretation

Optional visual assessments compare plant images over defined intervals and describe observable changes.

They are framed as observational comparisons rather than diagnoses and are withheld when suitable comparison frames are unavailable.

Turning the physical domain into an operating model

The core task was not collecting a moisture value. It was defining the relationships required to operate a physical monitoring system repeatedly.

Tenant
└── Area
    ├── Plants
    │   ├── Telemetry
    │   ├── Photo frames
    │   ├── Assessments
    │   └── Device assignments
    └── Devices
        ├── Probe
        ├── Phone monitor
        └── Area sensor

A plant is the monitored asset, but it does not own its hardware.

Devices are provisioned independently and assigned by scope. A probe may monitor one plant. A phone may capture several plants in an area. An area sensor may provide context without belonging to a specific plant.

This separation keeps device lifecycle, asset lifecycle, and observation history distinct.

The complete operating loop

Each device authenticates using a provisioned credential. Tenant ownership and scope are derived from that credential rather than trusted from client-submitted identifiers.

Numeric observations use a flexible metric model, allowing additional sensor types to enter the same ingestion path without requiring a new storage schema for every metric.

Designed for physical-system behavior

Intermittent connectivity

Devices report their own last contact separately from the timestamp of their most recent observation. The interface distinguishes online state, stale telemetry, and never-reported devices.

Capture time versus upload time

Measurements and photos retain the time they were observed, even when uploads are delayed.

Independent lifecycles

Plants, probes, and phones are separate managed entities. Hardware can be replaced or reassigned without destroying the monitored asset’s history.

Repeatable provisioning

Phones pair through temporary codes. Probes receive scoped credentials. Devices are assigned through the web application rather than hard-coded to a single deployment.

Variable visual evidence

Image comparisons operate across changing light, framing, obstruction, and plant movement. Assessments remain observational and may decline to produce a result when the evidence is insufficient.

What this project demonstrates

System of a Daun was not primarily a learning exercise. It was an independent proof of execution.

I selected a domain unrelated to the proprietary systems I work on professionally and applied the same broad capability: define the domain, design the operating model, connect physical devices to software, and deliver the complete system as a coherent product.

Guided views

System architecture

Edge sensing

ESP32 DevKit V1 with a capacitive soil-moisture sensor, calibration support, scheduled readings, and provisioned device credentials.

Edge imaging

Native Android application for one-time pairing, plant assignment, scheduled photography, optional illuminance capture, and heartbeat reporting.

Platform services

FastAPI, Alembic, and TimescaleDB for authenticated ingestion, tenant isolation, device management, time-series observations, media metadata, and assessment scheduling.

Operator application

Next.js interface for areas, plants, devices, historical telemetry, image frames, assessments, and configuration.

Deployment

Docker Compose and nginx.

Stack: ESP32 / PlatformIO · Android · FastAPI · Alembic · TimescaleDB · Next.js · Docker Compose · nginx

The implementation is maintained privately. This case study focuses on system design, operating behavior, and complete execution.