Реалізація діагностики IoT-пристрою через мобільний додаток
Діагностика IoT-пристрою — це відповідь на питання «що зараз відбувається з залізом» без фізичного доступу до пристрою. Температура процесора, навантаження CPU/RAM, стан мережевого інтерфейсу, uptime, версія прошивки, останні помилки в системному логе.
Що збирати та як
На пристрої (Linux, OpenWRT, ESP-IDF) збираємо метрики та надаємо через MQTT JSON або REST:
{
"device_id": "gw-warehouse-03",
"timestamp": 1711449600,
"cpu_load": 12.5,
"ram_used_mb": 87,
"ram_total_mb": 512,
"cpu_temp_c": 52.3,
"uptime_sec": 864000,
"firmware": "2.4.1-stable",
"wifi_rssi": -67,
"mqtt_reconnects": 2,
"last_error": "2024-03-25T08:12:01Z: sensor read timeout on /dev/ttyUSB0"
}
На мобільному клієнті — дашборд діагностики з gauge-індикаторами для CPU/RAM, історичним графіком температури процесора (перегрів у погано вентильованому корпусі — частої причини нестабільності) та списком останніх помилок.
Інтерпретація RSSI
WiFi RSSI в dBm — не абстрактне число. Відображаємо з зрозумілими порогами:
String rssiDescription(int dbm) {
if (dbm >= -50) return 'Відмінний сигнал';
if (dbm >= -60) return 'Хороший сигнал';
if (dbm >= -70) return 'Задовільний';
if (dbm >= -80) return 'Слабий — можливі втрати пакетів';
return 'Критично слабий';
}
RSSI -80 dBm та нижче — надійна причина періодичних втрат MQTT-повідомлень і кажучихся «зависань» пристрою.
Розробка екрану діагностики IoT-пристрою з системними метриками, історією помилок та станом мережі: 1–2 тижні. Вартість розраховується індивідуально.







