Mamalarm
Motivation
This project is much more personal than most. In 2022, my mom was diagnosed with early-onset Alzheimer's and had moved into an assisted-living facility. While she had no problems answering phone calls, she'd lost the ability to make calls herself and it was causing an enormous amount of stress for both her and the family.
Hardware Design
The idea behind the device is simple: three big illuminated arcade-style buttons with the names of family members under them. When pressed, a text message is sent to the assigned family member notifying them that they need to call.
Aesthetic
Artistic design is not at all a talent of mine, but it was important to me that Mamalarm not look like a sterile, unfriendly medical device. I searched Google for images of vintage devices and found a 1960s record player with a cool mid-century modern aesthetic and ran with it.
Design inspiration: a mid-century modern record player from the 1960s
Finished Product
The parts were designed using Autodesk Fusion 360 and printed with an Elegoo resin printer.
Materials
- x1 - Adafruit ESP32-S3 Feather with STEMMA QT / Qwiic
- x3 - Arcade Button with LED - 30mm Translucent Clear
- x1 - Mono Enclosed Speaker - 3W 4 Ohm
3D Printed Parts
Build
Proof of Concept Prototype (front)
Proof of Concept Prototype (back)
Software
Device Firmware
The firmware is written in Rust and runs on an ESP32 microcontroller.
On boot, the device does some basic initialization of peripherals and then attempts to connect to a WiFi network. I would have loved to build out some interface for getting the device connected it connected to a WiFi network--via Bluetooth or self-served page for entering credentials--but I lacked the usual free time to mess around and experiment that I'd usually have with personal projects. So, the WiFi credentials are hard-coded into the device's firmware.
Through the course of booting up and running, the device flashes the arcade button LEDs in various patterns and makes different sounds to indicate different states.
Once connected to WiFi, the device grabs a configuration object from its companion web application. It grabs the config by a unique identifier flashed into its firmware so, theoretically, the system is already set up to scale to multiple devices.
It really only cares about two pieces of configuration data: the config's version and the ping interval.
The ping interval establishes how often the device needs to phone home. It also helps the Mamalarm web application determine if the device has gone offline. With each ping, the device also gets its configuration's latest version. If the version changes, it reboots and the process starts over.
During normal usage, the device just waits for button presses. When a button is pressed, it sends an event to the web application indicating which button was pressed. The actual text messaging is handled by the web application, so the device itself is completely decoupled from its underlying practical purpose.
Web Application
Mamalarm Web Application
The web application is a React + NodeJS + MikroORM + PostgreSQL application deployed to a GCP-hosted, Terraform-managed Kubernetes cluster. The NodeJS sends text messages via Twilio API.
Users configure each button individually, with the ability to add a custom message to each button. Any changes to the configuration are picked up by the device the next time it pings the web application.
A live stream of events sent by the device are shown on the right: ping events, button presses, and activation events, which are sent when the device has rebooted so that it's using the latest version of the configuration.