ok so this is for a uni project, sorry if it’s the wrong sub-forum. We’re building 12 little air quality nodes (ESP32-C3 SuperMini + SCD41 + a PMS5003) that go into different labs across campus and report to our Hermetry org over MQTT. They have no display and the only button is BOOT.
Right now the SSID, password and the device access token are all #defines in the sketch, so every node gets its own build. That was fine for 2 prototypes, it’s not fine for 12, and the lab techs who’ll move them around can’t run the IDE.
What I want: flash one identical firmware on all of them, then on site someone joins a phone to the node, types the lab Wi-Fi, and the node gets its own Hermetry credential somehow. I found WiFiManager and the captive portal part works on the bench. The token part I have no idea. Is there a normal way people do this, or does everyone just hardcode?
Possibly a dumb question but why not just put the Wi-Fi in the code once, if it’s all the same campus?
Not the same network everywhere sadly. Two buildings are on a separate IoT SSID, one lab has its own router, and the passwords get rotated each term. Plus the tokens have to be different per node anyway.
WPS? Hold BOOT for 3 s, press the button on the router, done. Did that on some warehouse scanners years ago.
WPS is switched off on pretty much every managed network I’ve seen, I wouldn’t count on it at a uni. Are you on the Arduino core or ESP-IDF? IDF has a provisioning component over SoftAP or BLE that’s nicer than a captive portal.
Arduino core 2.0.14 in PlatformIO. Happy to stay with WiFiManager for the Wi-Fi bit, it’s the Hermetry token I’m stuck on. I don’t want to open the console and create 12 devices and copy 12 tokens into 12 portals either if I can avoid it.
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.
That worked, all 12 are up. I did hit the device_exists thing straight away because I’d erased flash on node 3 while debugging, it had already registered as aq-3c84a1. Deleted that device in the console and it provisioned again fine. Activated them all from quarantine this morning. Also had to escape the quotes properly, my first version sent broken JSON and just got nothing back.
We do the same on our line sensors. One tip from the floor: print the setup AP name on a sticker on the case. Nobody remembers which node is “ESP-3C84A1” six months later.
+1 to the sticker. Also if any of those labs only has enterprise Wi-Fi with a per-user login, a plain captive portal can’t do it, you’d need identity/username fields and WPA2-Enterprise in the firmware. Ask IT for a PSK IoT network instead, much less pain.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.