# 变更日志 ## YYYY-MM-DD - 初始化项目变更日志。 - 确认采用 Gitea Webhook + Shell 脚本的 CI/CD 方案。 - 部署脚本 (`deploy.sh`) 和相关配置已准备。 ## YYYY-MM-DD (请替换为实际日期) - 详细分析了项目整体结构,特别是单片机 (`mqtt_esp32_client.ino`) 与后端 (`springboot-init-main`) 之间基于 `README.md` 的 MQTT 通信流程和协议。 - **核心理解**: - **主题**: - 上行 (设备 -> 后端): `yupi_mqtt_power_project/robot/status/{spotUid}` (状态/心跳/ACK) - 下行 (后端 -> 设备): `yupi_mqtt_power_project/robot/command/{spotUid}` (指令) - **消息格式**: JSON。上行消息结构对应后端 `com.yupi.project.model.dto.mqtt.RobotStatusMessage`。 - **关键上行消息字段**: `robotUid`, `actualRobotStatus`, `taskId` (for ACK), `status` (for ACK), `activeTaskId` (通常为 `sessionId`)。 - **关键下行消息字段**: `commandType` ("START_CHARGE", "STOP_CHARGE", 等), `taskId`, `sessionId` (for "START_CHARGE")。 - **通信流程**: 设备连接后订阅指令主题并上报初始状态。周期性上报状态和心跳。后端下发指令,设备执行后通过ACK响应,并更新状态。 - **`activeTaskId` 的作用**: 该字段在单片机的状态上报和ACK中被用来传递当前有效的 `sessionId`,对于后端跟踪会话状态至关重要。 - 单片机代码中包含对 `MOVE_TO_SPOT` 指令的处理,`README.md` 未明确列出,后端可能需同步支持。 - 后续 Debug 将基于此理解进行。 ## YYYY-MM-DD (请替换为今天的实际日期) - **核心逻辑变更:"到达即充电"** - 移除了原先设想的由后端发送 `START_CHARGE` MQTT 指令来启动充电的流程。 - 新流程:机器人(单片机)在执行 `MOVE_TO_SPOT` 指令并成功到达车位后,立即将自身状态更新为 `CHARGING` 并上报。后端在收到 `MOVE_TO_SPOT` 任务的 ACK (其中应包含机器人已是 `CHARGING` 状态) 后,将机器人DB状态更新为 `CHARGING`,并将充电会话状态更新为 `CHARGING_STARTED`。 - **代码修改**: - `mqtt_esp32_client.ino`: - `MOVE_TO_SPOT` 指令处理逻辑修改: - 收到指令后,状态变为 `MOVING` 并上报。 - 模拟移动到达后,状态变为 `CHARGING`。 - 发送的 ACK 消息中 `actualRobotStatus` 反映为 `CHARGING`。 - 再次上报 `CHARGING` 状态。 - `ChargingSessionServiceImpl.java`: - `handleRobotArrival` 方法修改: - 当 `MOVE_TO_SPOT` 任务完成后,将充电会话状态 (`ChargingSession.status`) 直接更新为 `CHARGING_STARTED`。 - 记录 `robotArrivalTime` 和 `chargeStartTime`。 - 将数据库中机器人状态 (`ChargingRobot.status`) 更新为 `CHARGING`。 - 确保关联的 `RobotTask` (移动任务) 被正确处理和完成。 - `README.md`: - 更新了MQTT通信约定、消息示例、单片机开发关键逻辑以及示例充电流程,以反映"到达即充电"的新业务规则。 - **待考虑/后续**: - `ChargingSessionServiceImpl.handleChargingStart` 方法目前因 `START_CHARGE` 指令不再由后端主动发送而可能不再被主要流程调用,其定位和用途需要进一步明确或在未来重构中调整。 - 前端界面和用户交互流程可能需要相应调整,以匹配后端"到达即充电"的逻辑(例如,可能不再需要用户在机器人到达后点击"开始充电"按钮)。