Kevin a raison, et la connexion « preconfigured » est celle que l’imageur a créée à partir de ton WiFi domestique. Ajoute le point d’accès comme seconde connexion NetworkManager et donne une priorité à chacune. Je transporte un Pi entre deux usines exactement avec ce montage.

sudo nmcli con add type wifi ifname wlan0 con-name allotment 
     ssid "Aisha-phone" wifi-sec.key-mgmt wpa-psk wifi-sec.psk "********"
sudo nmcli con modify allotment connection.autoconnect yes connection.autoconnect-priority 10
sudo nmcli con modify preconfigured connection.autoconnect-priority 20
nmcli -f NAME,AUTOCONNECT,AUTOCONNECT-PRIORITY con show

Quand les deux sont à portée, la priorité la plus élevée l’emporte, donc le réseau domestique d’abord. Active le point d’accès avant d’alimenter le Pi ; s’il démarre en premier, patiente une minute, NetworkManager relance la recherche.Pour la mise en mémoire tampon : conserve les relevés dans une petite table SQLite, voire dans un fichier JSONL, et quand la connexion revient, envoie-les avec leurs propres horodatages, par lots :

[{"ts": 1762668000000, "values": {"soil.bed3": 31.5, "air.temp": 12.1}},
 {"ts": 1762668300000, "values": {"soil.bed3": 31.2, "air.temp": 12.6}}]

ts est exprimé en millisecondes UTC. Ne supprime une ligne qu’après confirmation de la publication (QoS 1, attends le PUBACK dans paho avec wait_for_publish()).Un piège avec un Pi : il n’a pas d’horloge sauvegardée par batterie. S’il démarre au jardin partagé et ne reçoit aucun réseau pendant un moment, l’horloge est fausse jusqu’à la synchronisation NTP ; les relevés horodatés avec cette horloge se retrouvent à la mauvaise heure ou sont rejetés (plus de 10 minutes dans le futur, c’est refusé). N’horodate les relevés qu’après que timedatectl show -p NTPSynchronized indique yes ; sinon, envoie-les sans ts et laisse Hermetry utiliser l’heure d’arrivée.