Traducido del English por IA ·
No necesitas tokens por dispositivo en el firmware. Divide el problema en dos.Wi-Fi: mantén WiFiManager. Añade un campo personalizado en el portal si quieres un nombre de dispositivo amigable; si no, usa la MAC.Token: deja que el nodo pida el suyo. En el perfil del dispositivo abre la pestaña Provisioning, pon la estrategia en Allow creating new devices, guarda, luego pulsa Create key y copia el secreto (se muestra una sola vez). Esa clave y secreto son los mismos para las 12 compilaciones. En el primer arranque el nodo se conecta con el usuario provision y una contraseña vacía, se suscribe a v1/provision/res y publica su solicitud. La respuesta incluye su token de acceso; lo guardas en NVS y a partir de entonces inicia sesión normalmente.
// 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
Dos cosas nos dieron problemas en una planta farmacéutica. Los dispositivos nuevos creados así acaban en cuarentena: se conectan, pero sus datos se descartan hasta que un administrador los active, así que avisa al responsable de la organización para que los busque. Y el nombre debe ser único; una segunda solicitud con el mismo nombre recibe device_exists, porque nunca entrega una credencial dos veces. Por eso no borres la NVS a la ligera. Los detalles están en Adding and claiming devices.
You don’t need per-device tokens in the firmware at all. Split it in two problems.
Wi-Fi: keep WiFiManager. Add one custom field in the portal if you want a friendly device name, otherwise use the MAC.
Token: let the node ask for its own. On the device profile open the Provisioning tab, set the strategy to Allow creating new devices, save, then Create key and copy the secret (it’s shown once). That key + secret is the same for all 12 builds. On first boot the node connects with username provision and an empty password, subscribes to v1/provision/res and publishes its request. The answer carries its access token, you store that in NVS and from then on it logs in normally.
// 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
Two things bit us on a pharma site. New devices created this way land in quarantine, they connect but their data is dropped until an admin activates them, so tell whoever owns the org to look for them. And the name must be unique, a second request with the same name gets device_exists because it never hands out a credential twice. So never wipe NVS casually. Details are on Adding and claiming devices.