BUILT ON WIDELY AVAILABLE TECHNOLOGY
The Technology
Behind Domesis
Designed to evolve with the people who use it.
Domesis aims to coordinate proven commercial equipment through software integrations, so a residence can evolve without replacing its entire system. Supplier choice and replaceable components can improve maintainability; compatibility, installation and total ownership cost still need careful evaluation.
Device observations→ Domesis rules and permissions→ Controls and activity
What is verified?
This page describes source-code capabilities reviewed on October 8, 2026. Finding an adapter is evidence of implementation; it is not confirmation of current installation, certification or deployment. The functional exploration uses fictional data and synthetic adapters. Manufacturer links explain product facts and do not imply endorsement.
Implemented in code · deployment not verified in this audit
Lutron lighting controls
Domesis has a Caséta Pro bridge adapter using LEAP for lights, dimming, shades, fans and Pico inputs. Its lighting workflows can respond to occupancy and automation rules.
Dependencies, replacement, and limits
A compatible Lutron bridge/controller, pairing certificates, a reachable local network and suitable electrical installation are required. Lutron’s product families differ; this adapter does not establish compatibility with every Lutron product.
Replacing a switch, shade or bridge requires compatible hardware, pairing and configuration. Electrical work may require a qualified installer.
Lutron Smart Hub documentation
Network and Protect adapters implemented · deployment not verified
Ubiquiti networks and cameras
Separate adapters read UniFi Network equipment/client state and UniFi Protect camera state. The application includes camera views and event processing. Networking infrastructure and camera analytics are different capabilities.
Dependencies, replacement, and limits
A compatible UniFi controller/Protect installation, authorized local API access and camera streaming infrastructure are required. Product capabilities vary; the demo uses static illustrations, not camera analytics.
New networking or camera hardware needs adoption, permissions, addresses and stream configuration. Storage, power and network requirements must be checked.
Ubiquiti camera platform
ESPHome adapter implemented · exact installed board and radar not verified
ESP controllers and radar presence
Domesis receives ESPHome native-API observations and distinguishes motion/IR from occupancy/radar. Its occupancy fusion uses configurable rules and bounded presence evidence. Repository migration records reference Apollo MSR-1 devices; those records do not confirm current deployment.
Dependencies, replacement, and limits
The ESP controller runs firmware and communicates over the network; the radar is a separate sensing component. Manufacturer MSR-1 documentation describes ESP32-C3 and LD2410B hardware. We have not inspected the installed boards or firmware, so those are product facts, not claims about this household.
Configure compatible firmware, network access, API authorization, area mapping and sensor thresholds. Radar can remain asserted or miss conditions; presence logic is an observation model.
Apollo MSR-1 documentation
Selected endpoint classes implemented · commissioning requires validation
Matter-enabled devices
The controller mapper handles selected lights/on-off endpoints, contacts, occupancy, temperature/humidity and window coverings. The iOS companion contains a MatterSupport commissioning flow. A separate bridge also exposes supported Domesis entities to Matter ecosystems.
Dependencies, replacement, and limits
Controller/fabric setup and the correct network transport are required. Thread devices need suitable Thread networking; BLE-assisted onboarding and MatterSupport require a compatible phone and platform entitlements.
A device must support the mapped clusters and attributes, then be commissioned and assigned to the relevant room. Matter branding alone does not guarantee that every function is available in Domesis.
Connectivity Standards Alliance: Matter
Capacitor kiosk and Device Owner controls implemented · device validation required
Commercial Android tablets
The resident interface can use a normal Android tablet. Domesis has a Capacitor wrapper, native kiosk controls, heartbeat/enrollment and signed APK update infrastructure.
Dependencies, replacement, and limits
True managed lock-task operation requires Device Owner provisioning. It differs from ordinary screen pinning, which a user can leave. Vendor power management, OS versions and WebView updates affect behavior.
A replacement tablet requires installation, enrollment and lockdown setup; it is not a zero-setup swap. Device-owner provisioning normally requires an unprovisioned device without user accounts.
Android lock task documentation
Workflows you can inspect
In the fictional exploration, an occupancy observation drives a lighting automation. Changing that rule changes the next result. A resident request appears for the caregiver; acknowledgment requires an actual explorer click. A switched appliance outlet can cross a configured duration threshold and generate an observation with an execution history. These demonstrate software workflows rather than live hardware or staffed support.
Explore Michael’s fictional home →Cost effectiveness includes the whole system
Consider devices, bridges/controllers, installation, networking, storage, subscriptions, AI usage and maintenance. Commercial availability does not by itself mean open source, cloud independence, universal interchangeability or indefinite support. Some replacements require adapters, migration, professional installation or reconfiguration.
Domesis supports broader household automation as well as supported-living experiences. It does not claim medical-device status, guaranteed safety or replacement of human support.
Source audit and public documentation checked October 8, 2026. Exact compatibility requires validation for the chosen equipment and firmware.