feat(iot_mqtt): 快速上报增加 car_state 翻转沿触发
- Step2: 任一通道 |variation|>=阈值 或 car_state 翻转沿, 均进入 300ms 快速档 (高灵敏度档小车 variation 可能不过阈值, 但 Loop 已判翻转, 事件不应慢发) - 修复首版两坑: if(fast_mode=0) 单等号致沿检测死代码; 快照刷新移到间隔门控之后, 防止沿被门控吞掉后退化为空闲慢发 - gcc 隔离单测: buggy 沿后延迟 950ms vs fixed 250ms, 出车沿/负向variation回归通过 - devlog 补 2026-07-15 条目
This commit is contained in:
@@ -381,6 +381,7 @@ static void iot_process_recv(void) {
|
||||
* Step 3 — 间隔门控: 时间到了才从缓存发布
|
||||
*===========================================================================*/
|
||||
void iot_mqtt_publish_sensor(void) {
|
||||
static uint8_t _last_car_state[4] = {0};
|
||||
if (g_iot_state != IOT_STATE_READY) return;
|
||||
if (!g_report_cfg.enable) return;
|
||||
|
||||
@@ -405,7 +406,7 @@ void iot_mqtt_publish_sensor(void) {
|
||||
/* 尚无缓存数据 → 不发 */
|
||||
if (!_cached_sr_valid) return;
|
||||
|
||||
/*--- Step 2: 判断是否进入变化态 (任一通道 diff >= 10) ---*/
|
||||
/*--- Step 2: 判断是否进入变化态 (任一通道 |variation|>=阈值, 或 car_state 翻转沿) ---*/
|
||||
uint32_t interval_ms;
|
||||
uint8_t fast_mode = 0;
|
||||
|
||||
@@ -419,6 +420,12 @@ void iot_mqtt_publish_sensor(void) {
|
||||
fast_mode = 1;
|
||||
break;
|
||||
}
|
||||
/* car_state 翻转沿(进车/出车) 同样触发快速上报
|
||||
注: 能走到这里 fast_mode 必为 0 (置 1 即 break), 无需再判 */
|
||||
if (_last_car_state[i] != _cached_sr.coils[i].car_state) {
|
||||
fast_mode = 1;
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -436,11 +443,21 @@ void iot_mqtt_publish_sensor(void) {
|
||||
uint32_t now = mstick();
|
||||
if (_last_publish_ms != 0
|
||||
&& (now - _last_publish_ms) < interval_ms) {
|
||||
return; // 未到间隔
|
||||
return; // 未到间隔; _last_car_state 不刷新, 翻转沿保持"待发", 持续顶住 fast_mode
|
||||
}
|
||||
_last_publish_ms = now;
|
||||
}
|
||||
|
||||
/* 确定发布 → 刷新 car_state 快照。必须放在门控之后:
|
||||
若放门控前, 沿被门控吞掉时快照已刷新, 下一轮检测不到翻转,
|
||||
事件退化为空闲间隔上报, 快速上报失效 */
|
||||
{
|
||||
uint8_t i;
|
||||
for (i = 0; i < _cached_sr.coil_count; i++) {
|
||||
_last_car_state[i] = _cached_sr.coils[i].car_state;
|
||||
}
|
||||
}
|
||||
|
||||
/*--- Step 4: 构建 JSON → 发布 (字段与 V1.02 协议一致) ---*/
|
||||
static char data_json[1024];
|
||||
static char payload[1400];
|
||||
|
||||
@@ -6,6 +6,34 @@
|
||||
|
||||
---
|
||||
|
||||
## 2026-07-15 — MQTT 快速上报增加 car_state 翻转沿触发
|
||||
|
||||
### 背景
|
||||
|
||||
原 fast_mode 仅由 `|variation| >= 10` 触发。灵敏度设高档时小车信号弱,variation 可能不过阈值,但 Loop MCU 已判定 car_state 翻转——进/出车事件仍按空闲间隔(≥1s)慢发,后台看到的过车时刻误差大。故增加:**任一通道 car_state 翻转沿也触发 300ms 快速上报**。
|
||||
|
||||
### 实现要点(两个坑,首版都踩了)
|
||||
|
||||
1. **`if (fast_mode = 0)` 单等号** → 赋值恒假,沿检测死代码。修正为直接判断(循环内走到该行 fast_mode 必为 0,无需再判)。
|
||||
2. **快照刷新必须在间隔门控之后**。若在门控前无条件刷新 `_last_car_state`,沿被门控吞掉(如距上次发布 <300ms)时快照已同步,下一轮检测不到翻转 → 事件退化为空闲间隔上报。修正:`return`(未到间隔)时不刷快照,沿保持"待发"持续顶住 fast_mode,直到真正发布才同步。
|
||||
|
||||
```c
|
||||
/* Step 2 循环内: variation 阈值 与 car_state 沿, 任一命中即 fast */
|
||||
if (av >= IOT_MQTT_VARIATION_THRESHOLD) { fast_mode = 1; break; }
|
||||
if (_last_car_state[i] != coils[i].car_state) { fast_mode = 1; break; }
|
||||
|
||||
/* Step 3 门控通过后才刷新快照 */
|
||||
for (i = 0; i < coil_count; i++) _last_car_state[i] = coils[i].car_state;
|
||||
```
|
||||
|
||||
### 验证
|
||||
|
||||
本地 gcc 隔离单测(buggy vs fixed 对照):进车沿后 buggy 延迟 950ms(退化空闲间隔),fixed 250ms(≤300ms 快速档);出车沿、负向 variation 回归均通过。
|
||||
|
||||
⚠️ 上电首帧若已有车(`_last_car_state` 初值 0 vs car_state=1),会触发一次 fast_mode——属良性,首帧本就该尽快发。
|
||||
|
||||
---
|
||||
|
||||
## 2026-07-14 — Loop 上报 variation 解析升级 2B→3B 有符号 (协议 V1.05)
|
||||
|
||||
### 背景
|
||||
|
||||
Reference in New Issue
Block a user