J’ai exactement essayé le truc uMQTTBroker chez moi l’an dernier et j’ai abandonné, puis j’ai fait ceci, qui tourne sans problème depuis 8 mois. Je ne suis pas expert, donc prenez-le comme « ce qui a marché pour moi ».Un Pi Zero 2 W faisant tourner Mosquitto sert de broker local. Les nœuds ESP8266 publient dessus sur le LAN ; le port 1883 non chiffré convient ici, car rien ne sort de la maison. La logique du buzzer est un petit script Python sur le Pi qui s’abonne localement, il fonctionne donc sans aucune connexion Internet.Pour Hermetry, le Pi est un seul appareil marqué comme passerelle (l’interrupteur « Cet appareil est une passerelle » lors de l’ajout). Un second script s’abonne à tout sur le broker local, horodate chaque mesure avec l’heure du Pi (synchronisée par NTP, à vérifier avec timedatectl), les conserve dans un fichier SQLite et les envoie vers le cloud avec paho-mqtt sur TLS :

topic: v1/gw/telemetry
{
  "freezer-1": [{"ts": 1762941600000, "values": {"temp": -18.6, "amps": 1.92}}],
  "gate":      [{"ts": 1762941605000, "values": {"open": 0}}]
}

Chaque nœud devient un appareil enfant portant son nom. Il ne supprime une ligne de SQLite qu’après le PUBACK. Quand Internet revient, il envoie l’arriéré du plus ancien au plus récent, par lots, et les mesures se placent à leurs heures réelles dans l’historique.Deux choses que j’ai apprises à mes dépens. Hermetry ignore le flag retain et ne fait pas de pont vers votre broker, donc ne vous appuyez sur aucun des deux. Et un gros arriéré se résorbe au rythme « Replay messages per second » du profil, donc après une longue coupure il faut un certain temps pour rattraper le retard, c’est normal.La page que j’ai suivie : Devices behind a gateway.