Ekran yok, tuş takımı yok: 12 ESP32-C3 laboratuvar düğümüne Wi-Fi ve token yüklemek
Yapay zekâ tarafından English dilinden çevrildi ·
Bu bir üniversite projesi için, yanlış alt forumda olabilirim, kusura bakmayın. Kampüsteki farklı laboratuvarlara yerleştirilecek ve MQTT üzerinden Hermetry organizasyonumuza veri gönderecek 12 küçük hava kalitesi düğümü yapıyoruz (ESP32-C3 SuperMini + SCD41 + bir PMS5003). Ekranları yok, tek düğmeleri BOOT.Şu anda SSID, şifre ve cihaz erişim token’ı sketch içinde #define olarak tanımlı, yani her düğüm için ayrı derleme yapılıyor. 2 prototip için sorun değildi ama 12 için uygun değil; düğümleri taşıyacak laboratuvar teknisyenleri de IDE çalıştıramıyor.İstediğim şey: hepsine aynı firmware’i yüklemek, sonra sahada biri telefonunu düğüme bağlayıp laboratuvarın Wi-Fi bilgisini girsin ve düğüm bir şekilde kendi Hermetry kimlik bilgisini alsın. WiFiManager’ı buldum ve captive portal kısmı masa başında çalışıyor. Token kısmı konusunda hiçbir fikrim yok. Bunu yapmanın yaygın bir yolu var mı, yoksa herkes değerleri kodun içine mi gömüyor?
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?
Yapay zekâ tarafından English dilinden çevrildi ·
Belki aptalca bir soru ama kampüs aynıysa Wi-Fi bilgisini neden koda bir kez yazmıyoruz?
Possibly a dumb question but why not just put the Wi-Fi in the code once, if it’s all the same campus?
Yapay zekâ tarafından English dilinden çevrildi ·
Maalesef her yerde aynı ağ yok. İki bina ayrı bir IoT SSID’sinde, bir laboratuvarın kendi yönlendiricisi var ve şifreler her dönem değiştiriliyor. Ayrıca token’ların zaten her düğüm için farklı olması gerekiyor.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
WPS mi? BOOT tuşunu 3 saniye basılı tutun, router üzerindeki düğmeye basın, tamam. Yıllar önce birkaç depo tarayıcısında bunu yapmıştım.
WPS? Hold BOOT for 3 s, press the button on the router, done. Did that on some warehouse scanners years ago.
Yapay zekâ tarafından English dilinden çevrildi ·
Gördüğüm hemen hemen her yönetilen ağda WPS kapalı, bir üniversitede buna güvenmezdim. Arduino core mu kullanıyorsunuz yoksa ESP-IDF mi? IDF, SoftAP veya BLE üzerinden bir provisioning bileşenine sahip ve bu, captive portal’dan daha kullanışlı.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
PlatformIO’da Arduino core 2.0.14. Wi-Fi kısmı için WiFiManager kullanmaya devam etmekten memnuniyet duyarım; takıldığım nokta ise Hermetry token’ı. Mümkünse konsolu açıp 12 cihaz oluşturmak ve 12 token’ı 12 portala kopyalamak istemiyorum.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Firmware içinde cihaz başına token’a hiç ihtiyacınız yok. Sorunu iki parçaya ayırın.Wi-Fi: WiFiManager’ı koruyun. Dostça bir cihaz adı istiyorsanız portala bir özel alan ekleyin; aksi halde MAC adresini kullanın.Token: Düğümün kendi token’ını talep etmesine izin verin. Cihaz profilinde Provisioning sekmesini açın, stratejiyi Allow creating new devices olarak ayarlayın, kaydedin, ardından Create key seçeneğine tıklayıp secret değerini kopyalayın (yalnızca bir kez gösterilir). Bu anahtar ve secret, 12 derlemenin hepsinde aynıdır. İlk açılışta düğüm, kullanıcı adı provision ve boş parola ile bağlanır, v1/provision/res konusuna abone olur ve isteğini yayınlar. Yanıt kendi erişim token’ını taşır; bunu NVS’e kaydedersiniz ve bundan sonra normal şekilde giriş yapar.
// 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
Bir eczane tesisinde iki sorunla karşılaştık. Bu yolla oluşturulan yeni cihazlar karantinaya düşer; bağlanırlar ama bir yönetici etkinleştirene kadar verileri atılır, bu yüzden kuruluşun sahibine onları aramasını söyleyin. Ayrıca ad benzersiz olmalıdır; aynı adla ikinci bir istek device_exists hatası alır, çünkü sistem aynı kimlik bilgisini iki kez vermez. Bu nedenle NVS’i gelişigüzel silmeyin. Ayrıntılar Adding and claiming devices sayfasında.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Bu işe yaradı, 12’si de çalışıyor. Hemen device_exists hatasıyla karşılaştım çünkü hata ayıklama sırasında 3 numaralı düğümün flash belleğini silmiştim; düğüm zaten aq-3c84a1 olarak kaydolmuştu. Konsoldan o cihazı sildim ve yeniden provizyon edildi, sorunsuz çalıştı. Bu sabah hepsini karantinadan etkinleştirdim. Ayrıca tırnak işaretlerini doğru şekilde kaçışlamam gerekti; ilk sürümüm bozuk JSON gönderiyordu ve hiçbir yanıt alamıyordum.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Biz de hat sensörlerimizde aynı şeyi yapıyoruz. Sahadan bir ipucu: kurulum AP adını kasanın üzerindeki bir etikete yazdırın. Altı ay sonra hangi düğümün “ESP-3C84A1” olduğunu kimse hatırlamıyor.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
Etikete +1. Ayrıca bu laboratuvarlardan herhangi birinde kullanıcı başına oturum açma gerektiren kurumsal Wi-Fi varsa, basit bir captive portal bunu yapamaz; firmware içinde kimlik/kullanıcı adı alanlarına ve WPA2-Enterprise desteğine ihtiyacınız olur. Bunun yerine BT departmanından bir PSK IoT ağı isteyin, çok daha az zahmetli olur.
+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.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.

