How a Local-First Smart Care Ecosystem That Works Even When the Internet Doesn't

There's a real-world problem hiding inside most smart healthcare systems, and it's one that doesn't get talked about enough.

A frail 79-year-old falls in her kitchen at 2 AM. Her smart hub detects the event, but the internet is down. The emergency alert never goes out. Her daughter, two miles away, doesn't get the call. And by the time someone checks on her the next morning, hours have passed.

This isn't a hypothetical. It's the failure mode that cloud-dependent smart care systems carry by design. When the internet drops, so does the safety net.

This platform was built to solve exactly this. And the way it was solved, through local-first architecture, edge processing, and secure device communication, offers a blueprint for how healthcare IoT should work.

The Context: Why Elder Care Technology Needs a Rethink

The numbers make the problem impossible to ignore.

As of 2025, more than 61 million Americans are aged 65 and older, like nearly 18% of the whole population. Around 28% of seniors live on their own, and most years it’s still a lot. Every year, 3 million older adults go to the emergency room because of fall related injuries and one in four adults over 65 has a fall each year.

At the same time, the global smart home healthcare market, worth USD 27.97 billion in 2025, is climbing fast, with a 26.6% CAGR, mostly pushed by families who want technology that helps people stay independent, without needing care that’s in person, 24/7.

But here's the gap: most platforms in this space are cloud-dependent. They work beautifully when the connection holds. When it doesn't, during a power cut, a router failure, an ISP outage, or simply spotty connectivity in a rural or older home, they stop working. And in a healthcare context, "stopped working" can mean something very serious.

Research published in 2026 confirmed what many in the field already suspected: cloud-dependent elder care monitoring systems consistently introduce alert latency exceeding ten seconds in emergency scenarios, a window that is medically unacceptable for events like falls or cardiac episodes. Edge-processed systems brought that latency under three seconds.

The platform was designed with that gap as its starting point.

The Brief: What the Platform Had to Do

The requirements weren't complicated to state, but were genuinely hard to build.

The platform needed to:

• Operate continuously, including during internet outages
• Deliver emergency response, SOS alerts, fall detection, with minimal latency
• Support secure onboarding so that only authorised devices could join the network
• Handle multiple IoT communication protocols without breaking down
• Keep healthcare data private, with minimal exposure to external cloud systems
• Be usable by caregivers and residents, not just technical staff

Every one of these requirements is, individually, solvable. The challenge was delivering all of them together, in a system that a non-technical caregiver could actually operate.

The Architecture: Local First, Cloud Optional

The core design decision that drives the platform’s reliability is the local-first approach. Rather than treating the internet as infrastructure and the local network as a fallback, the platform inverts that entirely. The home network is the infrastructure. The internet is an optional extension.

The Smart Hub

At the heart of the system is a Debian Linux-based smart hub that lives inside the home. This isn't a thin client passing data to a server somewhere, it's the brains of the operation. It runs automation logic locally, processes sensor data locally, and triggers emergency responses locally.

Three technologies do the heavy lifting:

• Zigbee2MQTT connects and manages the IoT sensors, fall detection devices, motion sensors, and other smart home hardware
• Mosquitto Broker handles the message passing between devices and the hub using MQTT, one of the most reliable protocols for IoT communication
• Node-RED manages the automation workflows, the logic layer that decides what happens when a sensor fires, when a threshold is crossed, or when an SOS button is pressed

Systemd services wrap all of this, configured to automatically restart any critical background process that fails. In a system where availability is non-negotiable, automated recovery matters as much as correct initial operation.

Secure Onboarding

One of the less-discussed risks in home IoT is unauthorised device access. The platform addressed this with a QR-code-based onboarding process. The QR code contains encrypted pairing information. Initial device discovery uses Bluetooth Low Energy, which limits range and reduces attack surface. Once paired, the hub generates secure authentication tokens for ongoing communication and actively blocks further unauthorised pairing attempts.

Ownership verification is baked in from the first interaction, not treated as a configuration step someone might skip.

High-Speed Local Communication

The mobile app starts on Bluetooth during setup, then automatically upgrades to local WiFi for day-to-day operation. The speed difference is significant and immediately perceptible to users.

mDNS discovery  (via Avahi) basically means the app can find the hub even when the router decides to reassign its IP address again. This is a common reason for connectivity issues on home networks, and a lot of platforms deal with it poorly or not at all. Server Sent Events then deliver real time updates from the hub to the app , without the user needing to refresh anything or keep polling, you know.

The Features: What Happens in Practice

Fall Detection Without Cloud Dependency

Zigbee-connected sensors monitor accelerometer data. When the hub detects a fall signature, the alert fires immediately, processed entirely on the local device. There's no round-trip to a cloud server and back. For a 79-year-old on the kitchen floor at 2 AM, that local processing is the difference between a fast response and a delayed one.

Emergency Response That Survives Internet Outages

When an SOS gets triggered, either automatically via fall detection or manually through a device, the hub wakes up local sirens and kicks off SIP emergency calling to the pre-configured caregivers, or in some cases the emergency contacts. SIP, Session Initiation Protocol, calling is processed by Baresip, which runs locally.

This is the system's most critical design decision: emergency workflows don't check whether the internet is available. They run regardless.

Secure Caregiver Audio Communication

The platform includes peer-to-peer encrypted audio calls between residents and caregivers, built on LiveKit integration. Calls are encrypted and routed to avoid recording on public servers. For elderly residents who may be disoriented or distressed during a health event, direct voice contact with a familiar caregiver is both practically useful and genuinely reassuring.

Mobile Application

The Flutter-based app runs consistently across iOS and Android. The architecture, Bloc state management with a Repository pattern, Dio and Retrofit for networking, was chosen to handle real-time state changes cleanly without the interface becoming unresponsive during a fast-moving emergency situation.

One specific integration stands out: the app is connected directly to native OS notification systems, meaning critical SOS alerts bypass silent mode and Do Not Disturb settings on the caregiver's phone. A caregiver who has put their phone on silent at midnight will still hear a fall alert.

The Security and Privacy Architecture

Healthcare data is among the most sensitive category of personal information, and the platform's architecture treats it that way.

• No open internet ports are exposed externally, which substantially reduces the attack surface for the system
• All local API communication between the app and hub requires authentication tokens
• Local processing keeps sensitive health data off external cloud systems by default
• The architecture supports compliance-aligned deployment for healthcare and data privacy frameworks, important for any organisation considering this for clinical or regulated care settings

The privacy-first design isn't a policy document, it's enforced structurally. Data that never leaves the local network can't be breached remotely.

What This Solves, and for Whom

The platform is relevant across a broader range of deployment contexts than might be immediately obvious:

Residential elder care - the primary use case. Older adults living alone or with occasional caregiver visits, where reliable fall detection and emergency response genuinely matter.

Home-based healthcare - people recovering at home after a surgery or managing chronic diseases, with a nurse or a caregiver needing a reliable monitoring and communication system.

Assisted living facilities - where a few caregivers monitor several residents and manual response speed is a limitation.

Places with poor connectivity - places where broadband infrastructure is very patchy or where internet outages are so frequent that they make the use of cloud-dependent systems for healthcare unreliable.

Healthcare situations requiring high privacy - places where transmitting health data to external cloud servers is against regulations or patients' wishes.

Key Outcomes

What the the platform build delivered:

• Real-time emergency response through local edge processing, independent of internet availability
• Continuous operation during internet outages, the platform doesn't degrade, it just keeps running
• Secure device onboarding that prevents unauthorised access from the first pairing interaction
• Noticeably faster app responsiveness through local WiFi API versus cloud-dependent alternatives
• Automated service recovery via Systemd, reducing manual intervention requirements
• Minimised external exposure of sensitive healthcare data through local processing architecture
• A scalable IoT foundation, the modular hub architecture allows additional sensors, devices, and workflows to be added without restructuring the core system

The Bigger Picture

The global edge computing in healthcare market reached USD 8.21 billion in 2025 and is projected to grow to USD 47.23 billion by 2035. The direction of travel is clear: healthcare data processing is moving closer to where patients are, not further away into centralised cloud infrastructure.

The platform is a working example of what that shift looks like in practice, not as a proof of concept, but as a deployed platform delivering real outcomes for real care scenarios.

For development teams, healthcare organisations, and technology providers thinking about smart care infrastructure, the lesson from the platform is straightforward: reliability in healthcare isn't achieved by adding redundancy to a cloud-dependent system. It's achieved by designing the local network as the primary layer and letting the cloud be an addition, not a dependency.

Built By Dotsquares

So the platform was designed, and then developed by the engineering team at Dotsquares, sort of mixing their experience in embedded Linux systems, IoT protocols, mobile application development, and also healthcare centered security architecture. If you are building a smart healthcare, or elder care, or any kind of IoT platform, and you want to discuss the technical architecture, get in touch.