Odoo 企业版工位质检测量为什么不是点开 Worksheet 手填数字：Shop Floor、IoT read_once 与 pass/fail 回调链路

很多人对制造质检 Worksheet 的理解，停留在“工位上弹一张表，员工把结果填进去”。

但在接入 IoT 后，Odoo 企业版其实在改一件更底层的事：测量值到底来自人手输入，还是来自设备读数。

这篇文章主要参考：

• enterprise/quality_mrp_workorder_iot/static/src/mrp_display/quality_check.js
• enterprise/quality_mrp_workorder_iot/models/iot_trigger.py
• enterprise/mrp_workorder_iot/static/src/mrp_display/quality_check.js

一、IoT 集成改的不是字段，而是点击行为

quality_mrp_workorder_iot 对 QualityCheck 前端组件做了 patch。

最核心的方法就是重写 clicked()：

• 先从当前记录读取 iotBoxId 和 deviceIdentifier
• 如果当前检查类型不是 measure，或者没有绑定设备，就回退到原本的 super.clicked()
• 只有当它确实是测量类检查，且设备信息完整时，才走 IoT 读取流程

这个设计非常克制。

它没有把所有 quality check 都强行 IoT 化，而是明确限制在“测量型检查 + 已绑定设备”的场景里。也就是说，企业版不是在追求“界面都变高级”，而是在尽量不破坏原有 Worksheet/Shop Floor 体验的前提下，把设备测量插进正确的节点。

二、真正的动作是 read_once，而不是弹窗要求你填数

满足条件后，前端会先提示一句：Getting measurement...。

接着调用：

• this.iotHttpService.action(...)
• 目标 IoT Box：iotBoxId
• 目标设备：deviceIdentifier
• 动作参数：{ action: "read_once" }

这一步很关键。

它说明企业版这里追求的不是持续数据流，而是工位检查节点上的一次性取值。也就是：

• 到了这道质检，你向设备读一次
• 拿到当前值
• 用这个值推进当前这张 quality check

所以它更像“现场取证”而不是“持续监控”。这很符合制造质检语义：很多测量不是要把设备变成实时看板，而是要在某道工序的某个时点拿到一笔可信读数。

三、拿到测量值后，系统并不会停在 IoT 层，而是继续回到质检链路

iotUpdateMeasurement(data) 收到设备回传后，会先判断 data.value 是否存在。

• 没值：走失败通知
• 有值：await this.props.record.update({ measure: data.value })
• 更新完成后：继续 super.clicked()

这三步说明了一个很重要的设计意图：IoT 不是替代 quality check，而是在给 quality check 喂一个更可靠的 measure。

换句话说，Odoo 并没有把“设备读取成功”直接等同于“质检通过”。

它只是先把测量值灌回检查记录，再让原本的 quality check 链路接着跑。后面该不该通过、是不是超容差、要不要触发 fail，依旧由原来的质检逻辑决定。

这正是架构上最稳妥的做法：

• 设备负责提供值
• 质量模型负责解释值
• Shop Floor 负责把两者接起来

四、selection_add 暗示了 IoT 触发器开始理解制造质检动作

后端 iot_trigger.py 很短，但信息量不小。

它对 iot.trigger.action 做了 selection_add，补入：

• pass
• fail
• measure

这意味着在 IoT 触发模型眼里，制造质检不再只是“设备被调用一次”，而是已经被抽象成几种质量动作语义。

这很重要，因为它说明 IoT 模块不是孤立的设备网关，而开始理解制造现场的业务动作：

• 有些设备事件要触发通过
• 有些设备事件要触发失败
• 有些设备事件要产生测量值

从系统分层看，这一步让 IoT 不再只是底层 I/O，而成为质量流程的一部分。

五、为什么这和普通 Worksheet 填表是两种完全不同的治理模式

如果让操作员直接手填测量值，系统默认相信的是“人”。

如果让 Shop Floor 在节点上执行 read_once，系统默认相信的是“设备 + 现场触发时点”。

两者最大的差异，不在于谁更方便，而在于审计和责任边界：

• 手填模式下，重点是员工有没有如实录入
• IoT 读数模式下，重点是设备是否在线、设备身份是否正确、读取时点是否对

因此前端里还专门保留了失败通知 _notifyFailure()：如果设备没连上，不能假装这次检查已经完成。企业版在这里很明确——设备链断了，就该把问题暴露出来，而不是悄悄退回“那你手填吧”。

六、它真正提升的不是酷炫感，而是量测可信度

把 IoT 接进工位质检，最容易被误解成“更自动化、更高级”。

其实真正被改善的是三件事：

1. 测量值来源更稳定：来自设备而不是人为录入
2. 质检动作时点更清楚：在具体 Shop Floor 检查节点触发
3. 通过/失败判断仍留在质量模型：设备不越权决定质量结论

这三点合起来，才让 IoT 量测在制造现场有价值。否则它只会变成一个酷炫但不可信的外设按钮。

结论

Odoo 企业版的工位质检测量，不是把 Worksheet 上的输入框换成了一个设备图标。

它真正做的是：把 measure 类检查重写成“Shop Floor 点击 → IoT read_once → 回写 measure → 继续 pass/fail 逻辑”的闭环。

所以这套设计的重点从来不是“更少手输”，而是让制造质检的测量值，尽可能来自可识别、可追踪、可校验的设备读数。