ZoeCare / ZoeFall

The problem

Before ZoeCare, the record of a fall was a line entered after the fact, by hand, into a spreadsheet or a form. The goal was twofold: alert caregivers and the health manager the moment it happens, and turn it into data that can be tracked, facility by facility.

The constraint

No camera, and nothing for the resident to wear: ESP32s measure Wi-Fi signal variations in the room. It’s a very sensitive signal that offers few usable parameters — false positives are the real problem. Detection therefore combines several filtering stages, a presence threshold, and a trained model.

All of it under information security and GDPR requirements: secured data, every connection logged. And with no budget: open source only, on OVH instances.

The architecture

The diagram shows the path of an alert, from sensor to caregiver. I built this chain alone, with three exceptions: alert emission from the sensors, their update mechanism, and the detection model.

When several falls happen at the same time, alerts are held for five seconds then grouped into one: the caregiver gets a clear message, not a flood.

The server was optimized to absorb the telemetry volume. Cassandra takes the real-time stream; older data is backed up then extracted to a physical server at the office, which keeps a copy and frees up space online. The applications run on Supabase, under a Row-Level Security model.

The Raspberry Pi fleet updates remotely, over SHA-256-signed OTA, per information security requirements. A failed update rolls back to the previous version on its own: a gateway down means a zone that’s no longer monitored.

No SSH port is open inbound. Maintenance goes through a WireGuard VPN, services run under systemd behind an Nginx reverse proxy over SSL/TLS, on OVH.

The result

Deployed and in production in 2 care homes.

• Flutter
• Node.js
• TypeScript
• Supabase
• Cassandra
• PostgreSQL
• React
• Metabase
• Raspberry Pi
• ESP32
• MQTT
• Docker
• Nginx
• systemd
• WireGuard
• OVH