# 变更日志

## 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` 指令不再由后端主动发送而可能不再被主要流程调用，其定位和用途需要进一步明确或在未来重构中调整。
    - 前端界面和用户交互流程可能需要相应调整，以匹配后端"到达即充电"的逻辑（例如，可能不再需要用户在机器人到达后点击"开始充电"按钮）。 

## YYYY-MM-DD (自动填充日期)

### ESP32 固件与后端通信逻辑校准与文档更新

**主要变更点：**

1.  **MQTT ACK 消息格式校准 (关键)**:
    *   **问题分析**: 通过深入分析后端代码 (`MqttMessageHandlerImpl.java` 和 `CommandTypeEnum.java`)，发现后端期望的MQTT ACK消息格式与之前`README.md`及单片机固件发送的格式存在显著差异。
        *   后端期望ACK中包含 `command_ack` 字段，其值为指令的**中文描述** (例如 "移动到指定点")，用于 `CommandTypeEnum.fromAck()` 方法匹配。
        *   后端期望任务ID字段为 `task_id` (数字类型)。
        *   后端期望成功状态字段为 `success` (布尔类型)。
    *   **`README.md` 更新**: 已更新 `README.md` (4.2.1节) 中的ACK消息示例，以准确反映后端期望的格式。包括添加了 `command_ack`，并将 `taskId` 改为 `task_id`，`status` (String) 改为 `success` (Boolean)。
    *   **行动项 (开发者)**: **开发者需要修改 `esp32_robot_firmware/mqtt_handler.cpp` 中的 `mqtt_publish_ack` 函数，使其发送的ACK JSON符合后端 `MqttMessageHandlerImpl.java` 的实际解析逻辑 (即包含中文描述的 `command_ack`，数字类型的 `task_id`，和布尔类型的 `success`)。**

2.  **MQTT 下行 `MOVE_TO_SPOT` 指令校准**:
    *   **问题分析**: 后端 `ChargingSessionServiceImpl.java` 在发送移动指令时，实际使用的payload是 `{"command":"MOVE", ...}`，而 `README.md` 先前示例为 `{"commandType":"MOVE_TO_SPOT", ...}`。
    *   **`README.md` 更新**: 已更新 `README.md` (4.2.2节) 中移动指令的示例，以反映后端实际发送的 `command: "MOVE"`格式，并添加了说明指出单片机固件已做兼容处理。
    *   **行动项 (开发者, 可选)**: 为保持一致性，可考虑更新后端 `ChargingSessionServiceImpl.java`，使其发送移动指令时使用 `commandType: "MOVE_TO_SPOT"`。

3.  **文档整体一致性提升**:
    *   `README.md` 中关于单片机处理逻辑 (4.3节) 和示例流程 (4.4节) 的部分也相应作了调整，以强调新的ACK格式要求和指令细节。

**代码分析涉及文件：**

*   `springboot-init-main/src/main/java/com/yupi/project/service/impl/ChargingSessionServiceImpl.java` (下行指令发送)
*   `springboot-init-main/src/main/java/com/yupi/project/service/impl/MqttServiceImpl.java` (下行指令封装与 `taskId` 注入)
*   `springboot-init-main/src/main/java/com/yupi/project/mqtt/handler/MqttMessageHandlerImpl.java` (上行消息及ACK处理核心逻辑)
*   `springboot-init-main/src/main/java/com/yupi/project/model/enums/CommandTypeEnum.java` (ACK中`command_ack`的解析方式)
*   `esp32_robot_firmware/mqtt_handler.cpp` (单片机ACK发送逻辑 - **需修改**)
*   `esp32_robot_firmware/esp32_robot_firmware.ino` (单片机指令回调处理)

**后续影响与建议**:

*   **首要任务是修正单片机固件的ACK发送逻辑**，确保与后端正确对接。
*   在完成固件修改后，建议进行完整的MQTT通信测试，覆盖所有指令类型及其ACK流程。