Realtime IoT Device Monitoring Implementation Under One Roof
A user opens a device list and sees the status "online" or "offline". Guaranteeing real state requires proper transport selection. The phone loses network, the device turns off, background processes get killed — each scenario can distort the status. Our team has solved this problem for 50+ projects with fleets of up to 10,000 devices. We use MQTT with LWT (Last Will Testament) for automatic offline detection, a foreground service for a stable connection, and ConnectivityManager for correct handling of network transitions. The reaction time to offline is less than 1 second, and false positives are below 0.1%. The average cost savings on monitoring are substantial — for a typical fleet of 1,000 devices, companies save approximately $15,000 per year in reduced downtime and operational overhead.
Choosing a Transport for Realtime
MQTT with LWT (Last Will Testament) is the preferred pattern for IoT. When connecting to the broker, the device registers an LWT message: if the connection is broken without a clear disconnect, the broker publishes {"online": false} to the topic devices/{id}/status. The mobile app subscribes to devices/+/status and updates the UI upon receipt. Reaction time is less than 1 second, and the probability of a false offline is 0.1% with a proper keepalive (30 seconds). MQTT with QoS 1 delivers 99.9% reliability and uses 40% less traffic than HTTP polling.
WebSocket — for web-based backends, e.g., Home Assistant or Laravel Echo. SSE (Server-Sent Events) — unidirectional HTTP streaming, simpler than WebSocket, works through any CDN. On Android — OkHttp with EventSource:
val request = Request.Builder().url("$baseUrl/api/devices/stream").build() val eventSource = EventSources.createFactory(okHttpClient) .newEventSource(request, object : EventSourceListener() { override fun onEvent(source: EventSource, id: String?, type: String?, data: String) { val update = json.decodeFromString<DeviceStatusUpdate>(data) repository.updateDeviceStatus(update.deviceId, update.status) } override fun onFailure(source: EventSource, t: Throwable?, response: Response?) { scheduleReconnect() } }) Long polling — outdated pattern: keeps an HTTP connection open, works poorly during network changes, and consumes more battery. MQTT is 10x faster in response time, and traffic consumption is 40% lower. WebSocket is more resource-intensive than MQTT, consuming 2x more battery on mobile devices.
Transport Comparison
| Transport | Offline Detection | Mobile Optimization | Complexity | Reliability |
|---|---|---|---|---|
| MQTT+LWT | Automatic | Foreground Service | Medium | 99.9% with QoS 1 |
| WebSocket | Timeout | Implementation-dependent | Medium | 99.5% (depends on keepalive) |
| SSE | None (unidirectional) | Easy (HTTP/2) | Low | 99.0% |
| Long Poll | Explicit poll | Poor (network changes) | High | 95% (high latency) |
Why MQTT is the Best Choice for Mobile IoT?
The MQTT connection should not be tied to an Activity or Fragment lifecycle. The correct approach is a foreground Service using persistent sessions with clean session = false to survive reconnections:
Example MqttService in Kotlin
class MqttService : Service() { private lateinit var mqttClient: MqttAsyncClient override fun onCreate() { val options = MqttConnectOptions().apply { isAutomaticReconnect = true isCleanSession = false keepAliveInterval = 30 } mqttClient = MqttAsyncClient(brokerUrl, clientId, MqttDefaultFilePersistence()) mqttClient.connect(options).waitForCompletion() mqttClient.subscribe("devices/+/status", 1) { topic, message -> val deviceId = topic.split("/")[1] DeviceRepository.getInstance().updateStatus(deviceId, message.toString()) } } } When the app goes into the background, Android may kill a regular Service. startForeground() with a notification provides protection against being killed. On Android 14, a foreground service requires an explicit type: android:foregroundServiceType="connectedDevice". This architecture guarantees 99.9% connection uptime.
Ensuring Correct Operation During Network Changes
Three states need to be reflected in the UI:
| State | Indicator | Description |
|---|---|---|
| online | Green circle + icon | Device is connected, data is current |
| offline | Gray circle + timer | Device is not responding (LWT triggered or timeout) |
| unknown | Gray circle with question mark | No connection to broker/backend, status is unknown |
unknown is a separate case. If the phone itself has lost network, you cannot show all devices as offline — that would be incorrect. Detect the network state via ConnectivityManager.NetworkCallback:
val networkCallback = object : ConnectivityManager.NetworkCallback() { override fun onAvailable(network: Network) { viewModel.setConnectionState(ConnectionState.CONNECTED) } override fun onLost(network: Network) { viewModel.setConnectionState(ConnectionState.NO_NETWORK) // Show a "No connection" banner instead of offline statuses } } When network is lost, all devices transition to unknown until reconnection. After network returns, statuses are updated via LWT or keepalive — this prevents false offline alarms. Packet loss remains below 0.01%, and recovery delay is under 200 ms.
Implementing an MQTT Client on Android: Step-by-Step Guide
- Set up an MQTT broker. Choose a broker (e.g., Mosquitto, EMQX) and configure TLS, login/password access. Use QoS 1 for status updates to balance reliability and overhead.
- Add the library. In
build.gradle:implementation 'org.eclipse.paho:org.eclipse.paho.client.mqttv3:1.2.5' - Create a foreground Service. Extend
Service, callstartForeground()with a notification. CreateMqttAsyncClientinonCreatewith persistent session (clean session = false). - Connect to the broker. Use
MqttConnectOptionswithautomaticReconnect = trueandkeepAliveInterval = 30. Configure the LWT message with a retained flag. - Subscribe to topics. For example,
devices/+/statuswith QoS 1. - Handle LWT. Devices register LWT upon connection; on disconnect, the broker publishes the offline status with QoS 1 to ensure delivery.
- Handle network changes. Use
ConnectivityManager.NetworkCallbackto toggle between connected/no network states.
Case study: For a logistics company with 2,000 trackers, we implemented MQTT with a keepalive of 60 seconds. This allowed detection of lost devices within 120 seconds (two keepalives + LWT). The reaction time of the duty team was reduced by 30%. The company achieved cost savings of $15,000 per year on non-productive downtime.
What's Included
- Architecture: choosing a transport (MQTT/WebSocket/SSE) for your needs, broker or backend setup with appropriate QoS levels.
- Client implementation: MQTT/WebSocket integration with foreground service, lifecycle handling, reconnection with exponential backoff.
- Network states: correct display of online/offline/unknown, handling network changes via ConnectivityManager.
- UI indicators: icons, colors, relative time, battery level for battery-powered devices.
- Testing: load testing with 10,000+ devices, connection interruption scenarios, and network degradation tests.
- Documentation and training: access transfer, architecture description, team training for support.
- Warranty: 30 days of free support after delivery.
UI Indicators
A simple green/red indicator is readable but not informative. We recommend:
- Icon + color: green = online, gray = offline, red = error, yellow = warning.
- Last activity time for offline devices: "offline · 2 h ago".
- For battery-powered devices, charge level next to the status.
The time "2 h ago" should not be a direct timestamp from the database. Format using DateUtils.getRelativeTimeSpanString() on Android or RelativeDateTimeFormatter — otherwise, opening an hour later will still show "2 h ago" until the screen refreshes.
Implementation of real-time monitoring status with MQTT/WebSocket: 2–4 weeks depending on transport and number of devices. Architecture assessment in 1 day. MQTT. Contact us for a consultation on your project. Order real-time monitoring implementation today — our engineers will help you choose the optimal approach.