Supervision

Monitoring des appareils : RSSI, uptime, reboots, rapport SLA

Elark collecte automatiquement des métriques de santé sur chacun de vos appareils ESP et permet de générer un rapport CSV de disponibilité pour vos clients en un clic.

Lecture 5 min

1. Pourquoi monitorer vos appareils ?

Un appareil connecté qui « décroche » de temps en temps est presque toujours victime d’un signal Wi-Fi trop faible, d’un voisin sur le même canal, ou d’un firmware qui redémarre tout seul. Sans données objectives, impossible de trancher : on tâtonne, on déplace l’appareil, on accuse la box.

Elark capture en continu quatre métriques de santé sur chaque appareil ESP. Cela sert deux publics :

Particuliers : déboguer un appareil capricieux, identifier une pièce mal couverte par le Wi-Fi, détecter un module qui « vieillit » et redémarre tout seul.
Intégrateurs : produire un rapport mensuel de SLA (« 99,8 % de disponibilité ») à fournir au client, prouver chiffres à l’appui que l’installation tourne correctement, et facturer en conséquence.

2. Métriques capturées automatiquement

Les ESP publient ces valeurs en MQTT (depuis ESPHome) ou en HTTP local (web_server v3). Elark les stocke dans une table dédiée device_telemetry avec un index temporel.

Métrique	Champ JSON	Plage typique	À quoi ça sert
RSSI Wi-Fi	`rssi_dbm`	-60 à -90 dBm (négatif)	Qualité du signal Wi-Fi vu par l’ESP. Plus la valeur est proche de 0, mieux c’est. En dessous de -80 dBm, les déconnexions deviennent fréquentes.
Uptime	`uptime_seconds`	0 à plusieurs millions	Temps écoulé depuis le dernier boot. Un graphe en dents de scie révèle un appareil qui redémarre régulièrement.
Reboots	`reboot_count`	Entier ≥ 0	Compteur incrémental de redémarrages. Une hausse brutale signale un problème d’alimentation ou un firmware instable.
Free heap	`free_heap_bytes` (optionnel)	10 000 à 200 000 octets	Mémoire RAM libre. Une chute progressive trahit une fuite mémoire dans un composant custom.

Anti-flood : pour éviter de saturer la base de données, Elark agrège au maximum un point toutes les 5 minutes par appareil. Les valeurs intermédiaires sont fusionnées sur la ligne la plus récente plutôt que créer une nouvelle entrée — c’est suffisant pour diagnostiquer une instabilité et garde le stockage léger.

3. Endpoint API `/devices/<id>/telemetry/`

Les utilisateurs du plan Intégrateur (API publique) peuvent récupérer ces données directement en HTTP, par exemple pour les pousser dans Grafana ou un dashboard maison :

GET /devices/<device_id>/telemetry/?range=24h

Le paramètre range accepte 24h, 7d ou 30d. La réponse est un JSON structuré :

{
  "range": "24h",
  "device_id": "8a7f3c2e-...",
  "rssi":      [{ "ts": "2026-05-22T08:00:00Z", "value": -72 }, ...],
  "uptime":    [{ "ts": "2026-05-22T08:00:00Z", "value": 318420 }, ...],
  "reboots":   [{ "ts": "2026-05-22T08:00:00Z", "value": 3 }, ...],
  "free_heap": [{ "ts": "2026-05-22T08:00:00Z", "value": 142336 }, ...]
}

Sécurité OWASP A01 : l’endpoint renvoie un 404 Not Found (et pas 403) si l’utilisateur authentifié n’est pas membre du workspace propriétaire de l’appareil. Cela évite de révéler l’existence d’un appareil à un attaquant qui devinerait des UUID.

4. Visualisation dans le dashboard

Depuis l’app, la page de détail d’un appareil (/dashboard/devices/<id>) affiche désormais trois graphiques superposés (RSSI, uptime, reboots) générés avec fl_chart côté mobile et Recharts côté web. La fenêtre par défaut est de 24 h, modifiable via un sélecteur (24 h / 7 j / 30 j).

Une sparkline compacte du RSSI dans la liste des appareils est prévue pour la fin du Sprint 4 — elle permettra de repérer en un coup d’œil les appareils qui décrochent sans même ouvrir la page de détail.

5. Rapport SLA uptime au format CSV

Pour les intégrateurs, Elark expose depuis le Sprint 5 un endpoint dédié qui calcule le pourcentage de disponibilité de chaque appareil d’un workspace sur une période donnée :

GET /workspaces/<workspace_id>/uptime-report.csv?since=2026-04-01&until=2026-04-30

Le serveur renvoie un fichier CSV directement téléchargeable (Content-Type: text/csv) avec les colonnes suivantes :

Colonne	Description
`device_id`	UUID interne de l’appareil
`device_name`	Nom donné par l’utilisateur
`uptime_percent`	Pourcentage de disponibilité sur la période (`total_online / (total_online + total_offline) × 100`)
`total_seconds_online`	Durée cumulée en ligne sur la période, en secondes
`total_seconds_offline`	Durée cumulée hors ligne, en secondes
`events_count`	Nombre de bascules online/offline détectées
`since`	Date de début (ISO 8601)
`until`	Date de fin (ISO 8601)

Cas d’usage : en fin de mois, l’intégrateur sélectionne le workspace de son client, clique sur Exporter le rapport SLA, et obtient un CSV directement utilisable dans Excel ou LibreOffice pour produire la facture mensuelle accompagnée de la preuve de disponibilité.

Rôle requis : Technicien minimum (cf. matrice des rôles workspace). Un visiteur ne peut pas générer le rapport — ce qui évite qu’un compte invité divulgue les chiffres de disponibilité.

6. Configuration côté firmware ESPHome

Si vous écrivez votre propre firmware ESPHome, ajoutez ces deux sensors pour qu’ils soient automatiquement remontés à Elark :

sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: 60s
  - platform: uptime
    name: "Uptime"
    update_interval: 60s

Le compteur de reboots est géré côté backend à partir des transitions online → offline → online détectées via les messages LWT MQTT — il n’y a rien à ajouter dans le YAML pour cela.

Bonne nouvelle : tous les templates du Marketplace Elark intègrent déjà ces deux sensors avec les bons intervalles. Si vous partez d’un template (voir Déployer un scénario), vous n’avez rien à faire.

7. Cas d’usage typiques

« Mon appareil décroche tous les soirs vers 19 h »

Ouvrir la fiche de l’appareil → vue 24 h. Si le RSSI plonge à -85 dBm chaque soir et qu’un reboot l’accompagne, c’est probablement un voisin qui allume son micro-ondes ou son four (le 2,4 GHz est saturé). Solution : rapprocher l’appareil de la box, ou ajouter un répéteur.

« Le client trouve que le système plante »

Exporter le rapport SLA du mois écoulé. Si le résultat est 99,8 % sur tous les appareils, vous avez une preuve écrite et chiffrée à opposer à la perception subjective du client. Si au contraire un appareil est à 87 %, vous savez exactement lequel cibler.

« Détecter un appareil en fin de vie »

Un reboot_count qui augmente anormalement vite (plusieurs redémarrages par jour) sur un appareil stable depuis des mois : c’est souvent le signe d’une alimentation USB fatiguée, d’un module Wi-Fi qui chauffe, ou d’une carte mémoire qui commence à corrompre la flash. Action préventive : remplacer l’appareil avant la panne définitive.