ESP8266/ESP32 配置WIFI账密项目

背景介绍 在我将ESP8266采集代码灌入之后,它已经可以实现自动采集按钮信号了。核心逻辑实现之后,我需要能够连接网络,因为网络是连接MQTT的前置条件。 在连接之前,我需要将路由器的WIFI密码告知ESP8266芯片,这不同于Debug的时候,在代码内固定填写WIFI账号密码。我需要动态的获取并写入到ESP8266芯片。 网络配置有很多种方式,我选择了SoftAP配网,虽然配置有点繁琐,但这是一种很可靠的配网方案,兼容性极高,不依赖手机硬件的特殊协议。 准确来说,这不应该算是一个项目,但因为它具有通用性和一点实用性。我决定把它记录下来,可以方便地应用到我的其它项目中。 Soft配网原理 初始化模式:ESP8266 启动后进入 WIFI_AP_STA 模式。它会开启一个无密码(或已知密码)的热点(AP),并运行一个轻量级的 Web 服务器(HTTP Server)。 通道建立:手机通过小程序或系统设置连接到该热点。此时手机与 ESP8266 处于同一个局域网内。 数据交互:小程序通过 HTTP Post 请求将目标 WiFi 的 SSID 和 Password 发送给 ESP8266 的固定接口(如 /config)。 校验与切换:ESP8266 收到参数后,尝试作为客户端(STA)连接路由器。如果连接成功,则关闭 AP 热点,保存参数到 Flash;如果失败,则返回错误信息并维持 AP 状态。 ESP8266端核心代码(Arduino IDE) 在Arduino IDE打开项目后,需要安装ESP8266 WebServer库。这个库提供了Web服务,可以接收其它HTTP客户端的连接。 以下代码实现了一个非常简单的Web服务,它监听/config接口并能够接收WIFI信息,以及接收之后可以本地存储,实现动态配置的功能。 注意:当存储在本地之后,下次启动可以直接使用。而不需要重新配置。 #include <ESP8266WiFi.h> #include <ESP8266WebServer.h> // 定义AP热点的名称 const char* ap_ssid = "ESP8266_Config_Device"; ESP8266WebServer server(80); void handleConfig() { if (server.hasArg("ssid") && server.hasArg("pass")) { String target_ssid = server.arg("ssid"); String target_pass = server.arg("pass"); // 确保这里是 pass // 1. 先回复小程序,否则一旦开始连WiFi,AP就会失效,小程序收不到回复会报错 server.sendHeader("Access-Control-Allow-Origin", "*"); server.send(200, "text/plain", "SUCCESS"); Serial.println("配置信息已收到,准备连接..."); // 2. 延迟一下再连接,给 HTTP 响应留出传输时间 delay(1000); WiFi.begin(target_ssid.c_str(), target_pass.c_str()); int counter = 0; while (WiFi.status() != WL_CONNECTED && counter < 20) { // 等待10秒 delay(500); Serial.print("."); counter++; } if (WiFi.status() == WL_CONNECTED) { Serial.println("\nWiFi连接成功!"); WiFi.mode(WIFI_STA); // 关闭AP模式,切换为STA模式 WiFi.setAutoConnect(true); WiFi.persist(true); // 将账号密码永久保存到Flash } else { Serial.println("\n连接失败,请检查账号密码"); // 保持AP模式,等待下次尝试 } } else { server.send(400, "text/plain", "FAIL: Missing Params"); } } void setup() { Serial.begin(115200); // 设置为AP+STA模式 WiFi.mode(WIFI_AP_STA); WiFi.softAP(ap_ssid); Serial.println("AP热点已启动,IP地址: " + WiFi.softAPIP().toString()); // 注册接口 server.on("/config", HTTP_POST, handleConfig); server.begin(); Serial.println("HTTP服务器已启动"); } void loop() { server.handleClient(); // 如果连接成功,可以根据需要在这里处理业务逻辑 if (WiFi.status() == WL_CONNECTED) { static bool connected_msg = false; if (!connected_msg) { Serial.println("设备已联网,IP: " + WiFi.localIP().toString()); connected_msg = true; } } } 参考上面的原理,设备上电之后,启动AP模式,接收配置,这个时候可以通过指示灯来显示状态。接收完毕后,可以正常连接到WIFI,则将WIFI配置信息保存到本地并进入核心业务逻辑。 ...

2025-01-02 · 2 min · Eagle

用 Rust 编写的小程序码生成工具项目

在沉浸于 Wails 3 开发 Mole 客户端的过程中,我不禁想起了我在 2023 年 11 月完成的一个小项目——mp-qrcode-gen。 虽然现在微信小程序后台已经集成了生成小程序码的功能,但在 2023 年,开发者想要快速、批量或者自定义参数生成小程序码,往往需要自己写脚本。于是,我用 Rust 编写了这款极致轻量的桌面工具。 一、 为什么在 2023 年做这个工具? 当时,很多运营人员和开发者在准备线下物料(如海报)时,面临一个痛点: 接口调用门槛:微信官方提供的是 API 接口,非技术人员无法直接使用。 参数复杂:小程序码分为“受限”和“不受限”两种,参数限制各异,手动拼凑 URL 极易出错。 批量需求:线下场景往往需要针对不同页面、不同场景值生成大量图片,网页端操作效率低下。 为了解决这些问题,我选择了当时还算冷门的 Rust 语言进行开发,追求极致的性能与体积。 二、 技术选型:Rust + native-windows-gui 在那个时期,我并没有选择 Electron 这种庞然大物,而是选择了: Rust: 保证了极高的运行效率和内存安全。 native-windows-gui (NWG): 这是一个非常纯粹的 Windows 原生 GUI 库。它不包含浏览器内核,直接调用 Windows API,生成的 .exe 文件体积非常小。 三、 核心功能拆解 工具界面直观,配置完 AppID 和 AppSecret 后,主要提供两种模式: 1. 数量受限模式 (API A/B) 特点:支持输入完整的、带有超长 URL 参数的页面路径。 场景:适用于对码量要求不高(总计 10 万个以内),但需要精准携带复杂参数的场景。 2. 数量不受限模式 (API C) 特点:页面路径较短,但支持独立的 Scene(场景值)字段。 场景:这是线下物料最常用的模式,可以无限次生成,通过场景值来区分不同的线下投放点。 3. 本地化保存 点击生成后,工具会直接调用微信接口并处理返回的二进制流,将其保存为本地图片文件。无需打开浏览器,所见即所得。 ...

2021-11-02 · 1 min · Eagle

用 Rust 打造 APK 上传工具项目

在自学 Rust 的那段日子里,我除了开发开源项目,还为日常工作量身定制了一些不公开的内部工具。其中最令我印象深刻的,是一个看似简单的 APK 文件上传小工具。 虽然它只是一个 Rust + native-windows-gui (NWG) 编写的单一界面应用,但它解决的两个核心生产问题,至今仍对我有着深远的影响。 一、 工具画像:极简与高效 这个工具的界面极其克制: 交互区:一个醒目的文件拖拽控件,文案提示“请把 APK 文件拖拽到这里”。 表单区:版本号、Version Code、更新描述、是否强制升级(开关)。 执行区:一个大大的“上传”按钮。 它的核心逻辑非常纯粹:校验必填项 -> 调用内部上传 API -> 上传文件 -> 返回成功或失败的对话框。 二、 故事一:消失的 60 秒与隐藏的超时限制 工具上线初期,一切运行平稳。由于办公室带宽充足,APK 的上传时间通常维持在 40 秒左右。 事故发生: APK 在集成广告后,经常会发生失败的情况,客户端弹出“超时”的报错。 排查过程: 我首先检查了后端服务,发现后端接口完全没有超时限制,服务器日志显示连接是被客户端主动断开的。 多次重复上传文件使用有线和无线对比,经排查是文件变大,由于公司无线网络波动,上传速度时好时坏,就会偶尔出现失败的情况。对比排查,发现失败的情况上传时间都超过了 60 秒。 回到 Rust 代码中,我发现当时为了追求简洁,直接使用了 HTTP 客户端的默认配置。而这个默认配置的 Timeout 为 60 秒。 解决方案: 在那个瞬间我意识到,工具不能只考虑“理想状态”。我手动将本地超时时间放宽至 5 分钟,并增加了状态提示。上传时不会再出现超时的情况了。 教训:永远不要依赖默认的超时设置,尤其是在处理文件上传这类长耗时操作时,本地的容错范围必须根据业务场景精细化配置。 三、 故事二:包名校验——把人为失误挡在门外 这是这个工具最有价值的一次功能进化。 事故发生: 有一次,同事不小心将应用 A 的打包产物当作应用 B 上传到了官网,导致用户下载后发现软件张冠李戴。这属于严重的生产事故。 排查过程: 这个客户端软件调用内部API后,会自动将上传的文件名修改为固定的软件下载文件名,显示在网站上。经测试,如果将应用A的打包产物使用应用B上传,在官网就会出现相同的情况。解决这个方法也非常简单,就是上传的时候小心细致一点,应用A使用A客户端软件,应用B使用B客户端软件。但是人总会犯错,尤其是在面对多个长相相似的 .apk 文件时。通过肉眼观察文件名来区分应用,是极其不可靠的。 ...

2020-01-02 · 1 min · Eagle