Back to work

Project 03 of 08

Project 03

Cafey

ESP32 · MQTT/TLS · AWS IoT Core · Kotlin Multiplatform · Spring Boot · PostgreSQL · KiCad · FreeCAD

A physical IoT system, end to end: mechanical design, electronics, firmware, cloud, backend and applications for a product designed to be built.

Fig. 03 — Cafey system outline.
Role
IoT & Systems Engineer
Context
Sixth-semester integrator project · Fatec Itaquera
Period
Aug 2026 – Dec 2026
Status
Phase 1 · schematic validated

Problem

Make a coffee maker with a mechanical switch a connected appliance, without opening or altering it internally.

Context

Cafey is an external IoT module that turns a mechanical-switch coffee maker into a connected appliance with no internal modification. It is also the sixth-semester integrator project.

Objective

A physical product designed for fabrication, connecting mechanical engineering, electronics, firmware, software and cloud.

Architecture

The work runs in four layers. Physical hardware: the mechanical structure is modelled in FreeCAD and the circuits are designed in KiCad. Edge: an ESP32, its firmware and MQTT. Cloud: AWS IoT Core, a backend and PostgreSQL. Applications: Kotlin Multiplatform clients over a Kotlin and Spring Boot API. In detail, an ESP32 drives a relay that cuts mains power to the coffee maker. The firmware, C++ on ESP-IDF and structured as active objects over FreeRTOS, speaks MQTT over TLS with X.509 certificates to AWS IoT Core. A Kotlin and Spring Boot backend with PostgreSQL consumes MQTT and exposes a REST API for devices, commands and scheduling. Kotlin Multiplatform clients cover web, mobile and desktop.

Stack

  • KiCad
  • FreeCAD
  • ESP32
  • Firmware
  • MQTT/TLS
  • AWS IoT Core
  • BLE
  • Kotlin
  • Spring Boot
  • PostgreSQL
  • Kotlin Multiplatform

Decisions

  1. D1

    A relay outside, nothing inside

    Control is a relay on the mains line, so the coffee maker is never opened or modified.

  2. D2

    AWS IoT Core as the broker

    MQTT runs over TLS with X.509 certificates against a managed broker.

  3. D3

    Mains and low voltage on opposite sides

    The housing keeps the mains section and the low-voltage section apart, as electrical safety requires.

Implementation

Phase 1 validated the complete KiCad electrical schematic. Authored the active object C++ firmware architecture for ESP-IDF, designed the physical 3D enclosure in FreeCAD, and developed the Kotlin Spring Boot backend for MQTT message consumption.

Results

  • Electrical schematic validated.E-03.1
  • Backend service logic and unit test suite passing.

Limitations

  • Component procurement is blocking physical board validation and mains electrical load testing.L-03.1
  • The hardware handles mains voltage: assembly needs validation by an electrician before first use under load.L-03.2

Evidence

Each record backs a claim made above; the reference beside a result, a limitation or a decision points here.

ArchitectureFig. 03

Architecture · hardware, edge, cloud and applications

How the physical module, the edge device, the cloud and the applications relate, in one drawing.

CodeE-03.1

Hardware · electronics in KiCad

The circuit around the ESP32: the validated electrical schematic, kept in the repository with the board and component libraries.

View repositorygithub.com/Tavaressan/cafey

DecisionD1

A relay outside, nothing inside

The module is external; the appliance stays as it was built.

SourceREADME

Links