Developing Mobile App for Smart Home Management
Smart home market fragmented like no other: Zigbee lamp from one vendor, Z-Wave lock from another, Wi-Fi camera from third, proprietary thermostat — in one apartment. Mobile app unifying them into single interface — not just UI task. It's multi-protocol integration with asynchronous state, push notifications, and mandatory offline fallback.
Protocols and SDKs: What Works With What
Zigbee and Z-Wave don't work directly from phone — no hardware module. All commands go through hub: Philips Hue Bridge (REST API), SmartThings Hub (REST + WebSocket), Home Assistant (REST + WebSocket + MQTT). Protocol choice yours. Home Assistant preferable for openness: WebSocket API with state_changed event subscription, Long-Lived Access Token for auth.
Matter — current standard since 2022, supported by Apple (HomeKit), Google (Google Home), Amazon (Alexa). SDK for Android: com.google.home:home-sdk (beta, requires Google account). iOS — HomeKit framework, HMHomeManager, HMAccessory. Matter works over Wi-Fi and Thread, but Thread needs border router (Apple HomePod, Google Nest Hub).
Direct Wi-Fi control — for open API devices (Shelly, Sonoff in DIY mode, Tuya). Shelly gives local HTTP API and MQTT without cloud — good for privacy. Tuya IoT Platform SDK for Android: TuyaSmartDevice with publishDps() methods for commands.
// Tuya: send turn-on command
val dps = hashMapOf<String, Any>("1" to true)
TuyaHomeSdk.newDeviceInstance(deviceId).publishDps(
JSONObject(dps as Map<*, *>).toString(),
object : IResultCallback {
override fun onError(code: String, error: String) { /* handle */ }
override fun onSuccess() { /* update UI */ }
}
)
Bluetooth Low Energy — for near field: smart locks (August, Nuki), sensors. CoreBluetooth on iOS, Android BLE API + RxAndroidBle on Android. Nuance: BLE connection must stay active for locks, else door open latency — 2–3 seconds on reconnect, unacceptable.
Real Challenge: State Consistency
Hardest part in smart home app — showing actual device state. Lamp manually turned off from wall switch? Push via Matter subscription or MQTT should update UI before next screen open.
Architecture for Android: ViewModel holds StateFlow<Map<DeviceId, DeviceState>>. Hub event subscription — separate coroutineScope at Application level to not bind to screen lifecycle. On state_changed from Home Assistant WebSocket — update via MutableStateFlow.
iOS similarly: HomeKit gives delegate callbacks home(_:didUpdate:) — route to @Published properties of ObservableObject or via Combine pipeline.
Dead events. If hub unavailable — app shouldn't hang on last known state without warning. WebSocket heartbeat timeout: if no pong in 30 seconds — show "device unavailable", not stale turn-on button.
Automation and Scenarios
Users expect not just button control — they expect automation. "When door opens after 11 PM — turn hallway light 50%." Scenarios implemented at hub level (Home Assistant automations, Apple Shortcuts, Google Home routines), app just provides UI for creation.
Automation builder — most labor-intensive part. Drag-and-drop conditions and actions, device selection, time triggers, geofences. Ready node-based editor hard to implement — simpler tabbed flow "trigger → condition → action" with limited logic.
iOS HomeKit vs Android: Practical Gap
HomeKit on iOS stricter: all devices must pass MFi certification or use Matter. But Siri Shortcuts integration — free user feature. INIntent for scene control — few lines.
Android more flexible: work with any API directly, no certification. But no single standard — each vendor has own SDK.
Timeline
MVP with one protocol (e.g., Home Assistant + WebSocket): 6–8 weeks. Multi-protocol app with Matter, MQTT, BLE and automation builder: 4–6 months. Cost depends on protocol count and platforms.