学习笔记 · Obsidian
从 Wi-Fi 到 HTTPS：一步一步判断联网状态
协议层次先摆正
业务：采样上报、配置读取、设备命令
应用协议：HTTPS / MQTT / WebSocket（按场景选择）
安全与传输：TLS（需要时） / TCP（本路线所用方式）
网络：IP
接入：Wi-Fi这张图限定本课程常用的 TCP 通信方式，不描述所有 HTTP 或物联网传输变体。BLE 通常从广播、连接、GATT 服务和特征值学习，是独立分支；不能把 BLE 当成 MQTT 必须经过的一层。ESP32-S3 的蓝牙方向是 BLE，不能假定支持经典蓝牙 SPP。ESP32-S3 入门能力说明
“已联网”要拆成多个状态
| 状态 | 证据 | 此时不能推断什么 |
|---|---|---|
| 正在连 Wi-Fi | 发起连接 | 尚未与 AP 建链 |
| Wi-Fi 已连接 | WIFI_EVENT_STA_CONNECTED | 不代表已经拿到 IP |
| IP 就绪 | IP_EVENT_STA_GOT_IP | 不代表域名解析和服务可达 |
| HTTPS 交互成功 | TLS 校验、HTTP 状态与响应完整 | 不代表业务一定接受了请求 |
| 业务成功 | 校验业务响应字段 | 才可按约定更新设备业务状态 |
Wi-Fi 事件与获得 IP 的处理顺序见 ESP-IDF Wi-Fi Driver。表中的服务和业务状态是本学习项目进一步拆分的设计。
第一个 Java 接口只做一件事
先设计一个尚未实现的练习接口 POST /api/lab/devices/{deviceId}/telemetry，接收一条人工采样，返回是否接受及服务端接收时间。正式集成前再与实际后端契约对齐。
设备端工作顺序：等待网络就绪，构造有大小上限的 JSON，发请求，检查状态码，按长度读取响应，最后释放请求资源。TLS 校验应信任正确 CA 并校验主机名；证书有效期检查还依赖合理的设备时间。ESP HTTP Client
localhost 在设备上指设备自己。访问 Mac 上的服务，要使用设备能够路由到的地址，并检查服务监听地址、同网段/路由和防火墙。
错误恢复是应用状态机
本项目建议把错误分成：无网络、DNS/TLS 失败、超时、服务拒绝、响应不合法。每类给出可观察状态，避免统一显示“请求失败”。
临时连接失败可用带抖动和上限的退避重试；认证失败先修正凭据或配置，不能高速无限重连。断线后清理失效会话，拿到新 IP 后按状态重建连接。事件回调只推进状态或投递工作，不在其中等待长 HTTP 请求。
重复上报使用应用层唯一键去重，例如本课程草案中的 deviceId + bootId + sequence。网络超时只表示没有收到确定结果，不能推断服务器没处理。
数据字段先定义单位与有效性
练习 JSON 建议包含 schemaVersion、bootId、sequence、uptimeMs、value、valid。value 的测量单位由具体传感器契约定义；失败时允许缺省/空值，并保持 valid=false，不要虚构读数。
uptimeMs 是开机经过时长，不是世界时间。没有校准时钟时，服务端记录接收时间；不能把开机秒数当 Unix 时间写进数据库。
验收场景
- 正常请求：设备与服务端能对应同一次上报。
- Wi-Fi 断开、恢复：显示断线状态，恢复后再上报，UI 继续响应。
- 服务超时或返回 500：重试有上限/退避，内存没有持续下降。
- 返回 401、错误 JSON、超长响应：分类处理，不进入成功状态。
- 相同请求重发：服务端去重结果明确。
这些都是待执行实验；本文没有建立服务器或连接任何实际云服务。