Vous n’avez pas du tout besoin de tokens par appareil dans le firmware. Séparez le problème en deux.Wi-Fi : conservez WiFiManager. Ajoutez un champ personnalisé dans le portail si vous voulez un nom d’appareil convivial, sinon utilisez l’adresse MAC.Token : laissez le nœud demander le sien. Dans le profil de l’appareil, ouvrez l’onglet Provisioning, réglez la stratégie sur Allow creating new devices, enregistrez, puis cliquez sur Create key et copiez le secret (il n’est affiché qu’une seule fois). Cette clé et ce secret sont identiques pour les 12 builds. Au premier démarrage, le nœud se connecte avec le nom d’utilisateur provision et un mot de passe vide, s’abonne à v1/provision/res et publie sa demande. La réponse contient son token d’accès ; vous le stockez dans la NVS, et ensuite il se connecte normalement.

// first boot only, after Wi-Fi is up
mqtt.setServer(host, 8883);          // WiFiClientSecure, TLS
mqtt.connect(clientId, "provision", "");
mqtt.subscribe("v1/provision/res", 1);
String req = String("{"deviceName":"aq-") + mac6 +
  "","provisionDeviceKey":"pk_xxx","provisionDeviceSecret":"ps_xxx"}";
mqtt.publish("v1/provision/req", req.c_str());
// in the callback: parse credentialsValue when status == "SUCCESS",
// prefs.putString("tok", value); then reconnect with the token as username

Deux points nous ont posé problème sur un site pharmaceutique. Les nouveaux appareils créés de cette façon atterrissent en quarantaine : ils se connectent, mais leurs données sont rejetées tant qu’un administrateur ne les a pas activés. Prévenez donc le responsable de l’organisation de les chercher. Et le nom doit être unique : une seconde demande avec le même nom renvoie device_exists, car elle ne délivre jamais deux fois un identifiant. Ne effacez donc pas la NVS à la légère. Les détails figurent sur Adding and claiming devices.

Aoife, le Pi n’a malheureusement pas de veille profonde. C’est une machine Linux : elle tourne ou elle est éteinte. Donc tu coupes tout ce que tu peux et tu fais travailler la radio le moins possible.Ce que je ferais, par ordre de gain :

1. Pi : dtoverlay=disable-wifi et dtoverlay=disable-bt dans config.txt, HDMI désactivé (tvservice -o sur les anciennes images), LED d’activité éteinte. Sur un Zero, cela ramène à environ 80 mA.
2. GPS : couper le moteur GNSS entre deux positions (AT+CGPS=0, puis AT+CGPS=1). Un démarrage à chaud sur le SIM7600 prend quelques secondes.
3. Cadence : 30 s en mouvement, 15 à 60 min à l’arrêt. Décide selon la vitesse ou la distance depuis la dernière position.
4. Lots : mémoriser les positions et envoyer un message toutes les quelques minutes sous forme de tableau avec ts. Le GPS fournit une horloge correcte, donc les horodatages sont fiables. Un appel HTTPS au lieu de dix consomme moins de temps radio et ne coûte qu’un message du quota mensuel au lieu de dix.

[{"ts": 1757683200000, "values": {"lat": 52.95231, "lon": -1.14972, "speed_kmh": 31.5}},
 {"ts": 1757683230000, "values": {"lat": 52.95410, "lon": -1.14701, "speed_kmh": 33.0}}]

Comme l’appareil ne communique que toutes les quelques minutes, règle la règle de connexion de son profil sur Recent message avec un intervalle attendu correspondant à ta cadence à l’arrêt, sinon il apparaîtra hors ligne toute la nuit.Si une semaine est une exigence stricte, la réponse honnête est un microcontrôleur (ESP32 ou nRF) qui dort et réveille le modem, ou un circuit temporisateur comme le TPL5110 qui coupe l’alimentation de tout le Pi entre deux cycles. Une carte Linux qui tourne à vide à 80 mA n’y arrivera jamais avec 10 Ah.

J’ai examiné une conception similaire pour un sous-traitant l’an dernier, voici donc le raisonnement pour le rapport.Séparez les éléments publics des éléments secrets. Le bundle CA est public ; le certificat serveur est un certificat public que l’on vérifie avec un bundle CA normal, donc le conserver sur la carte ne pose pas de problème. Le mot de passe WiFi et le jeton de l’appareil sont des secrets, car ils identifient précisément cet appareil.Les secrets sur un support amovible échouent pour deux raisons : retirer la carte ne laisse aucune trace, et la carte est souvent copiée sur d’autres cartes (« clone simplement la carte »), ce qui fait que plusieurs appareils partagent un même identifiant. Hermetry n’autorise qu’une session par appareil ; deux cartes avec le même jeton se déconnectent donc sans cesse mutuellement, et vous verriez une prise de contrôle dans l’onglet Log de l’appareil.Concernant X.509 : pour vos propres cartes, ce n’est pas disponible. Les certificats clients doivent provenir de l’autorité de certification des appareils de Hermetry, et l’envoi de votre propre CA pour des appareils tiers n’est pas proposé ; cette voie concerne les appareils sous licence qui génèrent leur clé et envoient eux-mêmes une CSR. Votre ESP32 utilise un jeton d’accès ou MQTT basic.Ce que je ferais sur un ESP32 :1. Le même binaire pour chaque carte convient. Placez le jeton dans la NVS lors du provisionnement (une petite commande série au premier démarrage), et non sur la carte.2. Activez le chiffrement de la flash et le chiffrement de la NVS, afin qu’un dump de la flash ne révèle pas le jeton.3. La carte ne sert qu’à l’enregistrement des données et au bundle CA.4. Dans Hermetry, un appareil et un jeton par carte ; changez le secret si une carte disparaît. Cela met immédiatement fin à ses sessions.La limitation concernant les certificats est décrite dans la dernière section de Device certificates.