ESP8266 Web配网+MQTT+STM32串口上云+免AT指令

        本文详细讲解 ESP8266/ESP12F Web 配网MQTT 通信、STM32/Arduino 串口透传一体化实现方案WiFi强制入户,连接自动打开网页配置,核心亮点是单片机免 ESP8266 AT 指令串口直接上云,通过串口向 ESP8266 发送数据即可自动上传至 MQTT 服务器,固件开源可直接用于学习调试。

固件下载:

通过网盘分享的文件:mqtt_usart_wifi.ino.bin
链接: https://pan.baidu.com/s/1mZt5diatyYvnSZ-N1eF75w?pwd=e8we 提取码: e8we

免AT指令全网首发!数据直接上传MQTT、秒下发指令,无需复杂配置!下载固件即可使用

一、项目背景与开发初衷

        在物联网设备开发过程中,配网和远程通信是两个核心痛点:传统的 AT 指令配网操作复杂,且多数方案在更换 WiFi 时会丢失 MQTT 配置;串口调试和 MQTT 远程控制无法兼顾;设备配置管理缺乏可视化界面。针对这些问题,我基于 ESP8266 / ESP12F 开发了一套集 Web 配网、串口调试、MQTT 远程控制于一体的智能设备管理系统,核心亮点是Web端支持只更改 WiFi 且保留 MQTT 配置、STM32串口与MQTT调试及控制一体,直接配网、直接发送数据使用,没有复杂指令,大幅提升设备运维效率。

二、功能亮点

1. 差异化核心特性

  • WiFi/MQTT 配置分离:更换 WiFi 时自动保留 MQTT 服务器、主题等配置,无需重复设置、WiFi自动连接、断连重启。
  • 多端控制体系:Web 可视化配置 + 串口命令调试 + MQTT 远程控制三重操作方式;Web端保存WiFi配置,串口可与STM32、Arduino等单片机连接,MQTT与云端、APP等实现远程控制
  • 安全的配置管理:支持分维度重置(仅 WiFi / 仅 MQTT / 完全重置),操作前需确认,防止误操作
  • 状态可视化:Web 页面展示设备、WiFi、MQTT 连接状态,信号强度等关键信息;串口和MQTT通信实时打印显示信息及help帮助

2. 完整功能清单

功能模块具体能力
Web 配网扫描 WiFi 列表、手动输入 SSID、MQTT 配置(开发者模式)、设备状态展示、配置重置
串口通信基础命令(help/status/test 等)、存储管理(eeprom/clear 等)、STM32 数据解析
MQTT 通信文本 / JSON 格式指令、状态上报、遗嘱消息、定时心跳、远程配置 WiFi
存储管理EEPROM 分字段读写、配置备份、出厂设置恢复

三、核心功能演示

1.Web 配网及功能介绍

        本人专注嵌入式方向,对 Web 开发涉猎不多,界面设计较为朴素,但功能完整,可直接使用。

WiFi连接配置:

        连接 “ ESP8266设备配置 ” WiFi,自动打开页面(部分手机需要浏览器手动输入192.168.4.1),保存相关配置即可连接。

设备重置功能:
  • 完全重置(清除所有配置):清除WiFi和MQTT配置,恢复到出厂状态
  • 仅重置WIFI配置:只清除WiFi配置,保留MQTT设置
  • 仅重置MQTT配置:只清除MQTT配置,保留WiFi设置

2.串口通信及调试(可连接STM32 / Arduino等单片机)

        该交互界面支持串口指令快速调试:向 ESP8266 发送 help 指令即可打印完整的命令帮助手册,发送对应指令后设备会自动返回执行结果。核心优势在于:单片机无需依赖 AT 指令,只需通过串口向 ESP8266 发送标准化格式数据(如 <DATA,TEMP:25.5,HUMI:60>),即可自动上传至已配置的 MQTT 服务器,大幅简化了嵌入式设备的网络通信开发流程。

3.MQTT通信体系

(1)MQTT 通信体系:文本 + JSON 双格式指令,适配不同场景

本系统的 MQTT 通信模块做了深度优化,既支持轻量化的文本指令,也兼容标准化的 JSON 指令,兼顾调试效率与工程化应用:

  1. 核心通信机制
    • 设备默认订阅主题 device/sensor_01,响应主题 sensor_01/response,状态上报主题 sensor_01/status,三主题分离设计,避免指令与状态消息混叠;
    • 接入时自动配置遗嘱消息(Will Message),设备离线时会向状态主题推送 offline 状态,上线则推送 online 状态,保障服务端能实时感知设备在线状态;
    • 支持 60 秒定时心跳上报,包含设备 IP、WiFi 信号强度、剩余内存等核心状态,便于远程监控设备健康度。
  2. 双格式指令支持
    • 文本指令(快速调试):直接发送 status(查状态)、test(发测试数据)、clear_wifi(清 WiFi 配置)等指令,设备自动返回执行结果;
    • JSON 指令(工程化调用):支持结构化指令如 {"cmd":"reconfig_wifi"},可远程修改 WiFi 配置,且保留 MQTT 原有配置不丢失
    • 单片机数据上传:无需封装 MQTT 协议,只需按 <DATA,TEMP:25.5,HUMI:60> 格式通过串口发数据,ESP8266 会自动封装为 JSON 并上传至 MQTT 服务器。
  3. 高可用设计
    • MQTT 断开后自动重连(10 秒重试一次),重连成功后自动恢复订阅与状态上报;
    • 配置持久化存储,即使设备重启,MQTT 服务器地址、端口、主题等配置也不会丢失,无需重新配置。
(2)连接机制(含遗嘱消息)

手机端APP也可通信,此界面为手机调试软件

四、部署与使用说明

1. 硬件要求

  • ESP8266 开发板(ESP12F / ESP-01 等)
  • USB 数据线
  • 串口调试工具(可选)

2. 软件环境

  • Arduino IDE(安装 ESP8266 开发板支持)
  • 依赖库:ESP8266WiFi、ESP8266WebServer、PubSubClient、ArduinoJson

3. 使用流程

  1. 首次配置
    • 烧录代码后,设备启动 AP 模式
    • 手机连接该 AP,访问 http://192.168.4.1
    • 选择 WiFi 并输入密码
    • 输入MQTT服务配置(开发者选项),完成配置
  2. 更换 WiFi
    • 串口发送 clearwifi 命令(或 Web 页面重置 WiFi)
    • 设备自动进入 AP 模式,重新配置 WiFi 即可(MQTT 配置保留)
  3. 远程控制
    • MQTT 发送文本指令:status(查看状态)、test(测试数据)
    • MQTT 发送 JSON 指令:{"cmd":"set_wifi","ssid":"新WiFi","password":"密码"}

     4.常用命令,部分可自行探索:

五、项目总结与扩展方向

1. 项目价值

  • 解决实际痛点:WiFi/MQTT 配置分离,解决频繁配网的问题
  • 降低使用门槛:Web 可视化配置,非专业人员也能操作
  • 提升调试效率:串口 + MQTT+Web 三重调试方式,适配不同场景

2. 扩展方向

  • 增加 OTA 远程升级功能
  • 支持多个 MQTT 主题订阅 / 发布
  • 接入阿里云 / 腾讯云等物联网平台
  • 增加配置加密存储,提升安全性

固件下载:

通过网盘分享的文件:mqtt_usart_wifi.ino.bin
链接: https://pan.baidu.com/s/1mZt5diatyYvnSZ-N1eF75w?pwd=e8we 提取码: e8we

        这是我第一次完整开发并开源物联网设备配网系统,整个过程中踩了不少坑:从最初的配置丢失问题,到 MQTT 连接稳定性优化,再到 Web 界面的用户体验调整。核心的 "WiFi/MQTT 配置分离" 设计,是解决实际使用中频繁配网的关键。希望这篇文章能帮助到同样在做 ESP8266 物联网开发的小伙伴,也欢迎大家在评论区交流优化建议!

如果你觉得这篇文章有帮助,欢迎点赞、收藏、关注!后续会继续分享物联网开发的实战经验。

Read more

因为淋过雨,所以想给前端人说点真心话

我面过很多人,也被面过很多次。 从被问到“你连原型链都说不清”,到后来坐在桌子另一边面试别人。 今天这些话,是淋过雨之后,真想端给前端人的一碗汤。 一、关于面试:你以为考的是技术,其实考的是“能不能干活” 很多前端人准备面试,一头扎进: * 手写防抖节流 * 背Vue/React生命周期 * 刷LeetCode 这些当然要会,但面试官真正想确认的是三件事: 1. 把你丢进项目里,能不能独立负责一个模块 2. 遇到线上Bug,能不能快速定位 + 止损 3. 给你一个模糊需求,能不能拆解 + 落地 所以别再只背八股文了。 面试官一旦问“你做过什么”“怎么做的”“遇到什么困难”,就是在验证你能不能干活。 二、关于空白期:别怕Gap,怕的是“Gap但什么都没留下” 我面过一个女生,简历上写着“2024年3月至今:Gap Year”。 换作以前,我会犹豫。

Open-WebUI—开箱即用的AI对话可视化神器

Open-WebUI—开箱即用的AI对话可视化神器

你是否曾兴奋地在本地部署了Ollama,却很快被冰冷的命令行和繁琐的指令劝退?是否羡慕ChatGPT那样优雅的聊天界面,却又希望数据能牢牢掌握在自己手中?OpenWebUI。这个在GitHub上狂揽 110,000 Stars 的明星项目,完美地解决了所有痛点 github地址: https://github.com/open-webui/open-webui 1.什么是Open WebUI? Open WebUI 是一款专为大型语言模型(LLM)设计的 开源可视化交互框架,它通过简洁的Web界面,让用户无需编写代码即可与本地部署的AI模型/各大服务商提供大模型API(如DeepSeek、Llama、ChatGLM等)进行自然对话。其核心使命是 “让LLM私有化部署像打开浏览器一样简单” ,尤其适合需要快速搭建企业级AI平台或追求数据隐私的开发者。 2. 核心价值 * 开箱即用:无需复杂的前端开发,快速搭建 AI 交互界面。完全开源,可自由部署、修改和二次开发,无商业使用限制。 * 多模型支持:兼容 Ollama、

本地服务器用 OpenClaw + Open WebUI 搭建企业多部门 AI 平台(附 Docker 避坑指南)

本地服务器用 OpenClaw + Open WebUI 搭建企业多部门 AI 平台(附 Docker 避坑指南)

引言: 最近在尝试使用 OpenClaw,发现这个 AI 个人助理框架非常有意思。于是团队里就有人提出:能不能为公司的多个部门,分别搭建专属的 OpenClaw 服务器? 诚然,现在有钉钉、飞书等成熟的办公软件可以接入 AI,但对于一些尚未全面普及此类协作软件的企业(或者需要绝对私有化部署的团队)来说,独立搭建一套内部 AI 门户依然是刚需。 起初,我们考虑直接让大家通过 OpenClaw 自带的 Web 界面进行跨电脑访问。但实操后发现这存在致命缺陷: 1. 权限越界:自带的 Web 端拥有底层的配置编辑权限,暴露给普通员工极其不安全。 2. 无法溯源:多终端共用一个 Web 界面,根本无法追溯对话是由谁发起的。 3. 缺乏隔离:无法按部门精细化分配 API 额度或限制特定部门只能访问特定的 OpenClaw 节点,无法实现业务隔离。 为了解决这些痛点,我们最终确定了这套架构方案:

【前端实战】Axios 错误处理的设计与进阶封装,实现网络层面的数据与状态解耦

【前端实战】Axios 错误处理的设计与进阶封装,实现网络层面的数据与状态解耦

目录 【前端实战】Axios 错误处理的设计与进阶封装,实现网络层面的数据与状态解耦 一、为什么网络错误处理一定要下沉到 Axios 层 二、Axios 拦截器 interceptors 1、拦截器的基础应用 2、错误分级和策略映射的设计 3、错误对象标准化 三、结语         作者:watermelo37         ZEEKLOG优质创作者、华为云云享专家、阿里云专家博主、腾讯云“创作之星”特邀作者、火山KOL、支付宝合作作者,全平台博客昵称watermelo37。         一个假装是giser的coder,做不只专注于业务逻辑的前端工程师,Java、Docker、Python、LLM均有涉猎。 --------------------------------------------------------------------- 温柔地对待温柔的人,包容的三观就是最大的温柔。 --------------------------------------------------------------------- 【前