15 Commits

Author SHA1 Message Date
2995840376
066d374673 fix(M): 修复品类中文乱码, 子设备在线状态按父网关判定
乱码: 服务器 mysql 客户端在 C locale 下 character_set_client=latin1, 迁移脚本经 Windows type|plink 管道执行时 UTF-8 字节被按 latin1 解读, 中文双重编码。修复: V25/V26 脚本首行加 SET NAMES utf8mb4, deploy-all.bat 的 mysql 调用补 --default-character-set=utf8mb4, 新增 V26 按 code 写回正确中文(幂等)。已验证 product_category.name 的 hex 为正确 UTF-8。

子设备在线: 涂鸦 Mesh/Zigbee 子设备无独立在线通道, SDK 与云端快照对其 online 恒 false, APP 上报后被写成离线。后端新增 resolveEffectiveOnlineStatus —— 上报在线即 online; 子设备上报离线时以父网关为准(父在线则 online); 设备列表输出再做一次父网关聚合, 历史数据立即生效。前端 DeviceInfo 增报 parentDeviceId, 并按品类推断 is_gateway。

APP: 网关下挂设备不再用涂鸦 SDK 快照覆盖后端结论; 列表状态改为在线/离线/状态未知三态; uniapp 端修复状态比大写 ONLINE 导致恒离线、且把状态字符串当 DP JSON 解析的问题。生产验证: JD2BTSA/JD6BTSA 由 offline 变为 online。
2026-10-28 01:25:46 +08:00
2995840376
903b44c84b feat(L): 新增品类管理, 收口涂鸦设备写入的归属校验
品类管理: 新建 product_category 品类字典表(V25, 灌入 8 个预设品类并回填存量 product.category), 后端提供 ProductCategory 增删改查/启停/字典接口, 后台新增「品类管理」页面(设备管理组, 与产品管理同级), 产品管理的品类下拉改为读字典(失败回退内置枚举)。

孤儿设备根治: TuyaController.bindDevices 收口三道校验 —— 绑定门禁(本平台未绑定涂鸦账号直接拒绝)、归属白名单(上报设备须在该用户涂鸦账号真实清单内, 拉取失败降级放行)、owner 校验(他人名下设备不改写; 恢复已删设备时归属改到当前用户)。

兜底自愈: 新增 OrphanTuyaDeviceCleanupTask, 每天 04:30 回收无绑定记录用户的涂鸦设备与 AI 档案(逻辑删除, 可恢复)。

Android: 查看设备时的补同步先确认后端绑定状态, 未绑定不再写库; 同步被拒时记录原因而非静默失败。单测 TuyaControllerBindTest 5 用例覆盖门禁/白名单/owner/恢复归属。
2026-10-28 01:10:59 +08:00
2995840376
91d50eda91 fix(J): 清理孤儿涂鸦设备与测试联动数据, 解绑时联动失效设备与AI档案
数据层(V24 迁移): 逻辑删除无涂鸦绑定记录的孤儿涂鸦设备及其AI档案; 物理删除测试阶段的联动规则、场景与场景执行记录(条件相同但动作矛盾的测试数据); 保留产品/物模型/家庭/成员/活动日志。幂等可重复执行。

代码层(根治): TuyaCloudService.unbindUser 解绑时联动逻辑删除该用户的涂鸦设备与AI档案, 避免解绑后设备仍在列表被联动规则反复命中而刷错误日志; 采用逻辑删除, 用户重新绑定同步时 restoreById 自动恢复。
2026-10-27 21:56:45 +08:00
2995840376
56a40edd8e fix(G): 设备控制指令业务异常降噪, 避免定时场景刷爆错误日志
问题:定时场景(SceneCronScheduler, 如 bb 场景)每分钟执行 7 条规则并向涂鸦设备下发控制指令,
而设备归属用户尚未绑定涂鸦账号,每次下发都抛 BusinessException,并以 ERROR + 完整堆栈记录,
单日产生上千条错误日志,掩盖真实故障。

改动(iot-device DeviceCommandListener):
- 区分业务可预期异常与系统异常:
  BusinessException(如"请先在个人中心绑定涂鸦账号")改为 WARN 单行输出,不再打印堆栈
- 新增 60 秒日志抑制窗口:同一 deviceId 在窗口内只详细记录一次,其余静默累计;
  下一个窗口首次记录时汇总上一周期被抑制的次数,避免高频场景刷屏
- 系统异常保留 ERROR + 堆栈(窗口内首次),同样受窗口抑制保护

生产验证:重启后日志变为 WARN「设备控制指令业务异常: 请先在个人中心绑定涂鸦账号(上一周期同类异常已抑制 N 次)」,
不再输出堆栈;RabbitMQ 队列深度为 0;4 个服务 active。
2026-10-27 18:40:51 +08:00
2995840376
b2d758be33 fix(F): 日志轮转治理 - 统一 logback 配置 + journald 限额
问题根因:
- iot-device.out 涨到 613MB:systemd StandardOutput=append: 无任何轮转
- DEBUG 刷屏(单日 11521 条):logging.level.com.iot=DEBUG 使 MyBatis 每条 SQL 打印两遍
- 涂鸦 open-mq-sdk jar 自带 logback.xml 抢占日志配置(iot-data/rule/alarm 未声明 logging.config),
  把日志写到 ./logs 相对目录且无总量上限

改动:
- 新增 backend/iot-common/src/main/resources/logback-spring.xml(4 服务共用唯一真相源):
  RollingFileAppender 按日 + 50MB 双触发切分,保留 7 天,主日志总量上限 2GB,
  错误日志单独一份(保留 30 天 / 512MB),并对涂鸦/MQTT/AMQP 等第三方 SDK 降噪
- 父 pom 增加 maven-resources-plugin,把该配置复制进各服务 BOOT-INF/classes
- 4 个服务 application.yml 统一声明 logging.config,并把 com.iot 级别收敛为 INFO
- 新增 backend/deploy/systemd/:4 个 unit 改为 StandardOutput=journal + 注入 LOG_DIR,
  附 journald 限额(SystemMaxUse=1G / SystemMaxFileSize=50M / MaxRetentionSec=7day)
- deploy-all.bat 增加日志治理步骤(同步 unit + journald + 清理历史 .out)

生产验证:日志落到 /opt/iotsaas/logs/app/*.log,DEBUG 计数 0,历史 .out 已清理,
journal 776M 降到 552M,4 服务 active,9081/9083 文档返回 200
2026-10-27 18:28:19 +08:00
2995840376
6e3f3ea661 fix(E): 修复 iot-device 启动失败 + V22 迁移脚本重写为可执行版本
【生产故障与修复】
iot-device 部署后反复重启失败(status=1/FAILURE, restart counter 3+):
  UnsatisfiedDependencyException: No qualifying bean of type
  'com.iot.device.mapper.ProductActionMapper' available
根因: iot-device 模块【没有 @MapperScan】(仅 iot-rule 有), Mapper 靠
      @Mapper 注解被 mybatis-spring-boot-starter 自动扫描;
      新建的 ProductEventMapper / ProductActionMapper 漏写 @Mapper 注解,
      导致扫描不到 -> ControlSchemaServiceImpl 注入失败 -> 启动失败。
修复: 两个 Mapper 补 @Mapper 注解; 已全量核查 iot-device 31 个 Mapper 均有该注解。

【V22 迁移脚本重写】(实测发现原写法在本环境根本执行不了)
- 原写法使用存储过程 + DELIMITER, 实测三种执行方式(管道/文件重定向/source)
  全部失败: MySQL 客户端在 batch 模式会把 DELIMITER 当普通 SQL 发给服务器。
  生产库现存存储过程数为 0, 佐证历史 V19/V21 等含 DELIMITER 的脚本
  其存储过程部分从未生效(仅 ADD COLUMN 等语句生效)。
- 重写为零存储过程、零 DELIMITER 的普通语句序列:
  加列幂等 -> PREPARE + information_schema 判定(ADD COLUMN 走 PREPARE 实测可用)
  索引     -> 直接 DDL(ADD INDEX 走 PREPARE 实测报 1064, 直接执行可用)
- 库名统一用 DATABASE() 判定, 测试库克隆无需改写脚本
- 清理顺序调整: 唯一索引统一放在软删重复行清理之后, 避免索引创建失败

【生产验证】(R730 192.168.3.3)
- 全库备份: /opt/iotsaas/backup/iot_platform_before_v22.sql
- 克隆库演练: 建克隆库 -> 跑 V22 -> 校验 -> DROP, 生产数据零风险
- 正式执行: platform_type 8行 / product.protocol / product_property.grp,
  is_primary, enum_label / product_action.completion_mode 全部就位
- 唯一索引: uk_platform_product / uk_product_code(x3) / idx_product_id 全部就位
- 数据完整性: product=11 device=13, 与迁移前一致
- 数据清洗: 脏 model/manufacturer=0, 空串 platform_product_id=0, device.miot=0
- tracking 表已标记 V22, 避免 deploy 脚本重复执行

【部署脚本加固】
deploy-all.bat 迁移步骤加 --force: 迁移脚本中'已存在'的 DDL(重复列/索引)
属正常情况, 不应中断整体部署

验证: 4 服务全部 active; 后台首页/SPA路由/9081文档/9083文档 均 200;
产品列表 API 返回 401 未认证(路由与过滤器正常)
2026-10-27 13:49:15 +08:00
2995840376
d6d9a94736 feat(C2-C4): 物模型编辑器支持语义编辑 + 修复全量替换撞唯一索引
SpecEditor.vue:
- 属性表新增 语义/分组/主开关 三列
- 属性编辑表单新增 semantic 下拉(17种标签, 与后端 SpecSemanticResolver 一一对应)、
  grp 下拉(8种分组)、is_primary 开关
- 分组说明写明: switch 组的开关位支持整组联动(switch_1~4 一起开关)
- 语义说明写明: 决定客户端如何渲染与能否作为主开关, 取代按名称猜测

后端 saveSpec 修复:
- 全量替换由逻辑删除改为物理删除
  原因: 逻辑删除留下同 (product_id, code) 的软删行, 与 V22 的
  (product_id, code, deleted) 唯一索引冲突 —— 连续保存两次即报错
- 新增 ProductEventMapper/ProductActionMapper.physicallyDeleteByProductId
- 语义缺失时自动推导(与 SpecSemanticResolver 规则一致)
- 状态量被误标 write 时强制只读
- 保存后调用 applyPrimary 重算主开关
- action 缺省 completionMode=SYNC

applyPrimary 语义修正:
- 人工优先: 已存在人工标记(is_primary=1)则保留人工选择, 不自动改写
- 仅在无人工标记时按语义规则自动补齐
  (reconcile 场景重建后无标记 -> 自动选; 后台编辑场景有人工标记 -> 尊重)

V22 迁移顺序修正:
- 唯一索引统一移到'软删重复行清理'之后执行, 避免索引创建即失败
- 新增软删重复行物理清理(同 (product_id, code) 只保留 id 最小的一条)
- 索引语句去重

验证: mvn BUILD SUCCESS; vite build 通过(ProductDetail chunk 已更新)
2026-10-27 13:19:08 +08:00
2995840376
3120af6464 feat(C2-C3): 后台产品/设备管理重构 - 产品中心 + 关系可视化
后端:
- Product 实体新增统计字段(deviceCount/propertyCount/eventCount/
  mainSwitchCode/mainSwitchName, 非持久化)
- ProductServiceImpl.fillProductStats(): 列表批量回填
  一次 selectBatchIds, 无 N+1; 让产品-设备-物模型的关系在 UI 层可见
  (此前关系在数据层存在但 UI 层完全不可见, 这就是'看起来乱'的根因)
- Device 实体新增 productName/productKey 非持久化字段
- DeviceServiceImpl.fillProductInfo(): 设备列表回填所属产品

前端 api/product.ts:
- Product/ProductProperty/ControlItem 接口补齐语义与统计字段
- 新增 syncProductSpec(): 从涂鸦云同步物模型
- 新增 listProductDevices(): 复用设备列表按 productId 过滤

产品列表 (ProductList.vue):
- 新增'物模型'列: DP 数量 + 主开关名 (未同步显示告警标签)
- 新增'设备'列: 挂载台数, 点击跳转设备列表并带 productId 过滤
- 新增'同步'按钮: 从涂鸦云同步物模型
- 新增'详情'按钮 -> 产品详情页
- 删除提示改为动态显示设备数

新增产品详情页 (ProductDetail.vue):
- 概览统计卡: 设备数/DP数/事件数/主开关
- 5 Tab: 基本信息 / 物模型 / 设备 / 固件与OTA
- 物模型 Tab 展示 semantic/grp/isPrimary/dpId, 并可切换属性/事件/服务

设备列表 (DeviceList.vue):
- 新增'所属产品'列, 可点击跳产品详情, 未关联显示'未关联'
- 新增'所属产品'筛选下拉(含各产品设备数)
- 支持从产品页跳转带 productId 参数自动筛选

MainLayout.vue 修复:
- groupedRoutes 未过滤 meta.hidden, 详情页会混进侧边栏菜单

验证: mvn 编译通过; npx vite build 通过(ProductDetail chunk 已产出)
2026-10-27 12:45:54 +08:00
2995840376
fdf0e265fc feat(B8-B9): 屏端物模型回流 + 设备级 schema 覆盖层(消除死数据)
问题: device.schema_json 是中控屏上报物模型的唯一落点, 但全仓只写不读,
属死数据; 同时屏端本地设备(zigbee/ble/matter)无平台产品, 产品级物模型里
也查不到东西, 导致这类设备拿不到 control-schema。

新增 PanelSpecAdoptService:
- 归一化: 屏端通用协议类型(BOOLEAN/INTEGER/NUMBER/ENUM/STRING) ->
  产品物模型类型(bool/int/float/enum/string);
  access(READ/WRITE/READ_WRITE) -> (read/write/read,write)
- 回流: 已存在的属性只补齐/修正屏端明确提供的字段(不做破坏性覆盖),
  不存在的补建; 产品级已有而屏端未报的属性保留(产品级是超集)
- 语义: 屏端已上报 semantic/channel 直接落库, 缺失时由
  SpecSemanticResolver 兜底推导
- toProperties(): 供无产品设备直接以设备级 schema 作为模型来源

PanelDeviceService: register / updateSchema 均触发回流

ControlSchemaServiceImpl.getDeviceSchema 改造:
- 无 product_id 的设备: 用设备级 schema 构建控制模型(不再直接返回空)
- 有 product_id: 产品基线 + 设备级覆盖层 merge
  同 code 以设备级为准, 设备级独有的 code 追加
- 新增 mergeItem(): 仅覆盖屏端明确提供的字段

验证: mvn -pl iot-common,iot-device -am compile 通过
2026-10-27 12:39:23 +08:00
2995840376
a8c2d005a8 feat(B10): 产品<->设备反向查询 - 设备列表可按产品过滤并展示所属产品
后端:
- DeviceQuery 新增 productId(精确) 与 productKeyword(按产品名/编码模糊)
- DeviceServiceImpl.pageDevices 支持两种产品维度过滤
  productKeyword 场景: 先解析匹配的 product_id 集合再约束 device,
  集合为空时用 1=0 保证不误返回全部
- 新增 fillProductInfo(): 批量回填设备所属产品名称与业务编码
  (一次 selectBatchIds, 避免 N+1)
- Device 实体新增非持久化展示字段 productName / productKey

验证: mvn -pl iot-common,iot-device -am compile 通过
2026-10-27 12:35:52 +08:00
2995840376
d7e34efb58 feat(B2-B4): 产品生命周期闭环 - 删除防孤儿 / reconcile 幂等全量 / 同步自愈
B2 deleteProduct 引用校验:
- 原实现直接 deleteById, 会留下 product_id 指向已删产品的孤儿设备,
  且 reconcile 只补 NULL 的设备 => 孤儿永远无法回收
- 现校验 device / firmware / ota_task 三类引用, 任一存在即拒绝删除并提示数量
  (此前前端却提示'已关联设备的产品不可删除', 后端实际毫无校验)

B3 reconcileDevices 幂等全量对齐:
- 原: 仅处理 product_id IS NULL 的设备
- 现: 对所有有 platform_product_id 的设备按 (platform, platform_product_id)
  重新解析产品并校正 product_id, 已对齐的跳过(不产生无谓写)
- 无平台产品ID的纯本地手工设备跳过

B4 同步自愈 (新增 ProductService.ensureDeviceProduct):
- TuyaController 同步路径由「仅当 product_id IS NULL 才解析」改为每次校验
- 产品不存在(含已逻辑删除)/平台产品ID不匹配 => 自动重新解析或创建产品
- 配合 B2 引用校验, 产品删除不再产生不可回收的孤儿

验证: mvn -pl iot-common,iot-device -am compile 通过
2026-10-27 12:34:27 +08:00
2995840376
6461acecd1 feat(B5-B7): 引入 SpecSemanticResolver 作为物模型语义唯一权威
新增 SpecSemanticResolver (356行):
- 语义标签体系: power/switch/backlight/indicator/brightness/color_temp/
  mode/scene/countdown/child_lock/temperature/humidity/battery/motion/
  contact/fault/raw
- 功能分组 grp: switch/scene/mode/countdown/display/config/measure/status
- resolve(): 单功能点语义推导(非主控词优先 -> 功能语义 -> 开关兜底)
- pickPrimary(): 产品范围内选主开关(power优先 -> switch组首个 -> 唯一可写bool兜底)
- isReadOnly(): 只读语义修正, 修复涂鸦 fnCodes 为空时兜底'全部可写'的缺陷

实体/DTO 补齐语义字段(V19 建了列但代码里没有):
- ProductProperty: semantic/grp/isPrimary/channel/completionMode/enumLabel
- ProductAction: completionMode
- ControlItem: semantic/grp/isPrimary/enumLabels

ControlSchemaServiceImpl 改造:
- toItem(): 搬运语义字段; 物模型无语义时即时推导(旧数据兼容);
  状态量被误标 write 时强制只读
- pickMainSwitch(): 优先 is_primary -> semantic=power -> 回退旧启发式
  (原实现按名称含 switch/power 猜测, 是 JD2BTSA 背光误控的根因)
- fillValues(): code 优先、dp_id 兜底(修复 dps key 语义分裂导致回填失败)

ProductServiceImpl.reconcileSpecFromTuya:
- 同步物模型时落库 semantic/grp, 并用语义修正 access
- 新增 applyPrimary(): 选主开关并回填 is_primary

验证: mvn -pl iot-common,iot-device -am compile 通过
2026-10-27 12:32:06 +08:00
2995840376
9786286ad3 fix(B1): 修复 resolveProductId 参数错位污染产品字段 + product_key 确定性化
根因: TuyaController 两处调用把「涂鸦 productId」填进 model 位、把字面量
'tuya' 填进 manufacturer 位, 导致 product.model / manufacturer 被写入
平台产品ID (生产数据已出现 P_tuya_y1ouxiqr_42bff218 的脏记录)。

修复:
- TuyaController: 2 处调用改为 model=null, manufacturer=null
  (涂鸦 OpenAPI 确实未提供真实型号/厂商, 此前是错位而非真实值)
- ProductServiceImpl.resolveProductId: 新增 sanitizeDimension() 防御,
  对畸形入参(等于平台产品ID / 等于平台编码)统一置空, 杜绝同类错位复发
- resolveProductId 入口 platform 经 PlatformType.normalize() 归一

product_key 确定性化:
- 旧: P_<platform>_<model>_<随机UUID8>  -> 不可读、无法反查
- 新: P_<platform>_<platformProductId|model>  -> 恒定、可反查
  (超 56 字符截断并追加短哈希防碰撞)

验证: mvn -pl iot-common,iot-device -am compile 通过
2026-10-27 12:22:39 +08:00
2995840376
a932633c50 refactor(A): 产品/物模型/设备三层架构重构 - 地基批次
新增:
- iot-common/PlatformType: 平台维度单一真相源(枚举)
  统一 tuya/matter/local/xiaomi/huawei/dueros/alexa/google_home,
  提供 legacy 别名归一(miot|mi -> xiaomi)与已知性判定
- backend/sql/V22__product_device_arch_refactor.sql: 幂等迁移(153行)
  A. platform_type 平台字典表 + 种子数据(后台可维护)
  B. product 加 protocol 列; platform_product_id 空串清洗为 NULL;
     清洗 model/manufacturer 被涂鸦 productId 污染的历史脏数据;
     加 (platform, platform_product_id, deleted) 唯一约束
  C. product_property 加 grp/is_primary/enum_label + (product_id,code) 唯一约束
  D. product_event/product_action 加 (product_id,code) 唯一约束;
     product_action 加 completion_mode
  E. device 加 product_id 索引(OTA 物化目标设备此前全表扫); platform 归一

改造:
- DeviceAdapter 新增 platform() 显式声明平台
- DeviceAdapterManager 改为按 platform() 精确匹配,
  移除'类名是否包含平台字符串'的脆弱约定(类名与平台码不同名会静默降级)
- DevicePlatform 委托 PlatformType, 消除第四套平台取值域

验证: mvn -pl iot-common,iot-device -am compile 通过
2026-10-27 12:08:44 +08:00
2995840376
0ce191c448 chore: 初始化 iotsaas 版本库基线
纳入范围:
- backend/  Spring Boot 多模块后端(iot-common/device/rule/data/alarm/auth)
- frontend/admin/  Vue3 + Element Plus 管理后台
- Android/   涂鸦原生 APP (com.xhai.iot)
- backend/sql/  Flyway 风格迁移脚本(V2~V21)
- docs/       对接文档与设计文档

排除范围:
- 构建产物: node_modules/ target/ build/ dist/ .gradle/
- 签名密钥: *.jks *.keystore (严禁入库)
- 本机配置: Android/local.properties
- 运行日志: logs/ *.log
- AI 协作本地数据 .codebuddy/ 与第三方 demo tuya-demo/

.gitattributes 统一以 LF 存储, Windows 批处理保留 CRLF
2026-10-27 12:00:41 +08:00