nia500总结 - 技术栈

序列化的作用：

当需要将对象长期保存或临时缓存时，序列化是必经步骤：

你的场景中，DashboardService需要将List<AlarmRecordVO>存入 Redis 缓存，Redis 本质是键值存储系统，只能存储字符串、字节流等基础类型，无法直接存储 Java 对象；

若AlarmRecordVO未实现Serializable，Redis 的序列化工具（如GenericJackson2JsonRedisSerializer、JdkSerializatiorent-alarms），值为nil；

实现序列化后，工具可将对象转换为 JSON 字nRedisSerializer）无法解析该对象，导致写入失败，最终 Redis 中仅生成空键（dashboard:cur符串或二进制流存入 Redis，后续查询时再反序列化为AlarmRecordVO列表，支撑首页 "当前告警" 板块的快速展示。

逻辑删除的用处：

中央告警系统的 "主机" 是整个监控体系的核心节点 ------ 一台主机关联多台从机、多个栏舍的告警数据，若物理删除主机记录，会导致：

1）从机数据成 "孤儿数据"：device_slave 表中该主机下的从机（如你之前看到的 192.168.1.100#01）会失去关联，实时监控页面无法显示这些从机，告警记录也无法追溯到对应的主机；

2）告警历史断层：alarm_record 表中该主机的历史告警（如断电、离线告警）会无法关联到主机信息，用户查询历史告警时，"设备地址" 字段会变成无效值，失去故障溯源价值；

3）恢复成本极高：若误删主机，物理删除后只能通过数据库备份恢复，而备份可能存在时间差（如每日备份），期间新增的从机 / 告警数据会丢失。

====》

而逻辑删除通过 del_flag=1 标记 "已删除"，本质是假删除------ 主机记录仍在数据库中，只是查询时默认过滤（如 del_flag=0）。若误删，只需将 del_flag 改回 0，即可完整恢复主机及关联的从机、告警数据，避免业务中断。

参数选项明细中的 "正常" 和 "停用"

参数选项明细中的 "正常" 和 "停用"，是系统对参数选项的状态标记，核心作用是控制该选项是否能在业务场景中被使用

一、"正常" 状态：可在业务中正常使用

举例：参数编码CS0001（栏舍状态）的选项 "正常""空置"，状态均为 "正常"，在 "从机管理" 页面新增 / 修改从机时，"栏舍状态" 下拉框会显示这两个选项，管理员可直接选择；

二、"停用" 状态：业务中隐藏且不可使用

当参数选项的状态为 "停用" 时，该选项会被系统标记为 "无效选项"，不再参与业务流程：

举例：若参数编码CS0004（设备型号）的选项 "FAN12-M485" 状态改为 "停用"，则在 "从机管理" 的 "设备型号" 下拉框中不会显示该选项，管理员无法选择；

注意status，数据库，后端，前端要统一，用0/1表示还是字符串"正常/停用"

主机管理各个ip

设备地址，本地ip,网关ip

可以将设备地址和本地 IP 设置为同一 IP，但这是 "业务层面的约定" 而非 "技术强制要求"；网关 IP 必须设置为对应网段的网关（如192.168.1.1），这是技术强制要求

实时监控

中央告警系统的 "实时监控" 功能，核心是监控主机下所有从机的运行状态，且默认需要指定主机（或默认展示所有主机），具体说明如下:

1、实时监控页面展示的是某台主机下所有从机的核心状态，包含但不限于：

1）从机基础信息：设备地址（主机地址）、从机编码、栏舍名称；

2）运行状态：在线状态（在线 / 离线）、电源状态（正常 / 断电）、电池状态（正常 / 电量低）；

3）信号值：从机对应的主机信号值（自动获取）；

4）告警状态：是否存在生效中告警（标红展示异常状态）。
这些数据来自从机的 MQTT 实时上报（或主机的定时采集），并缓存到 Redis（如device:{deviceAddr}:{slaveCode}），实时监控页面直接从 Redis 读取，保证低延迟。

数据库字段讨论

结合中央告警系统需求说明书的参数设计规范、从机数据特性（如猪舍状态、设备型号等），以及行业通用实践，将 "猪舍状态" 等设为 "参数选项名称"（如 "正常 / 空置"）更合适，而非参数选项标号（如 "001/002"）。

中央告警系统的用户是 "办公室管理员"，需通过从机列表、实时监控页面快速识别设备状态，而非记忆抽象的标号：

示例 1：猪舍状态字段

若存储 "参数选项名称"（如 "正常 / 空置"），管理员在实时监控页面可直接判断栏舍是否在使用，无需额外对照 "001 = 正常、002 = 空置" 的映射表；

若存储 "参数选项标号"（如 "001/002"），管理员需频繁切换页面查询参数映射关系，违背 "实时监控" 的高效性需求（需求说明书 2.4.2 节：实时监控需 "直观展示状态"）。

告警

基础状态异常触发告警

在线状态异常：从机未在 "读取频率" 时间内上报数据（如读取频率 60 分钟，从机超过 60 分钟无数据），系统判定 "离线"，生成 "离线告警" 并关联该从机；
电源状态异常 ：从机上报的 alarm 列表中包含 "断电"，系统生成 "电源故障告警" 并关联该从机；
电池状态异常 ：从机上报的 alarm 列表中包含 "电池低"，系统生成 "电池电量不足告警" 并关联该从机。

设备上报MQTT消息

↓

DeviceMessageHandler.handleMessage()

↓

解析JSON消息 → DeviceMessageDTO

↓

遍历每个从机数据 (device_in数组)

↓

processDeviceData() - 处理单个从机

↓

parseDeviceStatus() - 解析设备状态

↓

AlarmService.checkAndCreateAlarm() - 告警检测

↓

检测三种告警类型：

checkPowerAlarm() - 断电告警
checkBatteryAlarm() - 电量低告警
checkOfflineAlarm() - 离线告警

当前告警记录（/api/dashboard/current-alarms）查询的是 MySQL 中的 alarm_record 表
告警趋势（/api/dashboard/alarm-trend）查询的是 InfluxDB 中的 alarm_event 时序数据

离线告警

其中num设置的是从机编号

设备断电告警

核心修改：status 中的 alarm 改为 power_off，device_in 的 alarm 数组第一个元素改为 "供电异常"

解除告警：

电池低告警

核心修改：status 中的 alarm 改为 battery_low，device_in 的 alarm 数组第二个元素改为 "电池低"

首页数据

设备统计

走的是redis；

matt上报消息近触发"设备实时状态缓存的更新"，首页缓存需要通过"定时任务"或"页面触发"才会生成；

http://localhost:8080/api/dashboard/statistics

bash 复制代码

{
  "code": 200,
  "msg": "操作成功",
  "data": {
    "hostCount": 3, //主机数量
    "slaveCount": 12, //从机数量
    "normalHouseCount": 8, //正常栏舍
    "emptyHouseCount": 4, //空栏
    "alarmHouseCount": 2 //告警栏舍
  }
}

influxdb

influxd.exe --http-bind-address 127.0.0.1:8017

更换组织

打包

两种场景的核心区别

场景	正确交付物	用途
让别人运行你的项目	可执行 JAR 包（通过 mvn package 打包）	部署、测试运行，无需改代码
让别人继续开发你的项目	完整的项目源代码（整个项目文件夹）	可以修改代码、调试、二次开发

redis

设备状态

device:{deviceAddr}:{slaveCode}

首页相关：

"dashboard:current-alarms"
"dashboard:statistics"
"dashboard:trend:24h"
"dashboard:trend:15d"

1、所有用于缓存的DTO都必须实现 `Serializable` 接口，否则Jackson序列化会失败（静默失败，不抛出异常）。

2、MQTT上传信息仅触发设备实施状态缓存的更新

首页缓存需要通过"定时任务"或"页面触发"才会生成；

验证：/api/dashboard/current-alarms

3、告警状态变化会自动清除缓存