Mises à jour firmware (OTA) et reflashage

1. Comment fonctionne l'OTA

L'OTA (« Over-The-Air ») met à jour le firmware d'un appareil à distance, sans câble. Le déroulé :

1. Vous déclenchez la mise à jour : Elark envoie à l'appareil (via MQTT) un message contenant l'URL de l'image, son sha256, sa signature et la version.
2. L'appareil télécharge l'image en HTTPS depuis ota.elark.cloud.
3. Il vérifie la signature Ed25519 et le hash, écrit la nouvelle image en mémoire flash, puis redémarre.
4. Il renvoie le résultat (succès / échec). En cas d'échec, il revient automatiquement à l'ancienne version (rollback).

2. Mettre à jour un appareil depuis sa fiche

Ouvrez un appareil (Mes appareils › …) puis l'onglet Firmware. Il est disponible pour les ESP Elark (les modules Shelly se mettent à jour par leur propre canal).

• État du firmware : version actuelle, précédente, et statut du dernier OTA.
• Mise à jour à distance (OTA) : choisissez une image publiée puis cliquez sur « Déclencher l'OTA ». L'appareil doit être en ligne. Un downgrade (version plus ancienne) est refusé, sauf pour un administrateur.
• Reflasher par USB : si l'appareil ne répond plus en OTA, branchez-le en USB et reflashez l'image de base depuis le navigateur (Chrome/Edge, via Web Serial). Le Wi-Fi est redemandé après le flash.

Pour déployer sur tout un parc d'un coup et par paliers, utilisez plutôt les Campagnes OTA.

3. Ajouter une nouvelle image firmware

La publication d'images est réservée aux administrateurs Elark (pas aux utilisateurs finaux — voir la section sécurité). La marche à suivre :

1. Compilez votre projet ESPHome → vous obtenez un binaire .bin (et la version, ex. 1.6.0).
2. Dans l'admin Django (/admin/firmwares/firmware/add/), créez une entrée :
   • device_type : le type d'appareil ciblé (ex. switch_1ch, base) ;
   • version : en SemVer (1.6.0) ;
   • file : le binaire .bin ;
   • min_supported_version et release_notes (optionnels).
3. À l'enregistrement, Elark calcule automatiquement le sha256 et la signature Ed25519 avec la clé privée de la plateforme — ces champs sont en lecture seule.
4. Cochez published pour la rendre visible (déclenchable). Une image non publiée reste invisible des appareils et des utilisateurs.

L'image apparaît alors dans Firmware OTA et dans l'onglet Firmware des appareils, prête à être déclenchée.

4. Sécurité : peut-on laisser des firmwares « custom » ?

Question légitime — et la réponse est rassurante : dans Elark, les utilisateurs ne stockent pas de firmwares custom sur le serveur. Le modèle repose sur trois garde-fous :

• Upload réservé aux admins : seul un compte staff peut publier une image (API protégée par IsAdminUser). Un utilisateur ne peut que déclencher une image déjà publiée, et uniquement sur ses propres appareils.
• Signature obligatoire : chaque image est signée côté serveur avec la clé privée Ed25519 de la plateforme (FIRMWARE_SIGNING_KEY, jamais exposée). Les appareils embarquent la clé publique et refusent toute image dont la signature n'est pas valide.
• Anti-downgrade : un appareil n'accepte pas une version antérieure à la sienne (sauf dérogation admin explicite).

Conséquence : même si un binaire arbitraire se retrouvait hébergé, un appareil ne le flasherait jamais sans signature valide de la plateforme. Le risque « un utilisateur pousse du code malveillant sur un device » est donc neutralisé par conception.

Si un jour vous souhaitiez ouvrir l'upload aux utilisateurs (firmwares communautaires), il faudrait ajouter : quotas de stockage, analyse antivirus, isolation du domaine de téléchargement, et surtout conserver la vérification de signature côté appareil — c'est elle qui protège le matériel, pas le stockage.

5. ESP32 ou ESP8266 ? Compatibilité cloud

Point important avant de choisir votre matériel : le cloud Elark impose une connexion MQTT chiffrée (TLS, port 8883). Or seul l'ESP32 sait faire du MQTT TLS avec ESPHome. Conséquence directe :

Vous avez un ESP32 et voulez le cloud

Rien de spécial à faire : le package de base Elark (firmware/esphome/base.yaml, inclus par les bundles Marketplace) embarque déjà la CA racine Elark (valable ~30 ans). Le certificat du broker peut être renouvelé côté serveur sans jamais reflasher vos ESP, tant qu'il reste signé par cette CA. Activez ensuite l'accès distant via l'interrupteur « Accès Cloud » sur la fiche de l'appareil.

Vous avez un ESP8266 : le garder en local

Un ESP8266 reste parfaitement utilisable : il est piloté sur votre réseau local via son web_server (et par l'app Elark en mode LAN). Il ne faut pas inclure base.yaml (qui est désormais ESP32-only) ni de bloc mqtt:. Exemple de configuration minimale qui fonctionne sur un Wemos D1 mini :

substitutions:
  device_id: "ventilo-ch-manon"
  device_name: "Ventilo ch. Manon"

esp8266:
  board: d1_mini

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "${device_id} fallback"
    password: !secret ws_password

captive_portal:

logger:
  level: INFO

# OTA local (push via `esphome run`, sur le LAN)
ota:
  - platform: esphome
    password: !secret ws_password

# web_server v3 -> accas local garanti (pilotable par l'app Elark en LAN)
web_server:
  port: 80
  version: 3
  auth:
    username: !secret ws_user
    password: !secret ws_password
  ota: false

# PAS de bloc `mqtt:` -- l'ESP8266 ne peut pas faire de MQTT TLS.

switch:
  - platform: gpio
    pin: GPIO5
    id: relay_ventilo
    name: "Relais ventilo"
    restore_mode: RESTORE_DEFAULT_OFF

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

Adaptez le pin à votre câblage réel. Si vous tenez au contrôle distant de cet appareil, la seule solution est de le remplacer par un ESP32.