制造现场一说 IoT，很多人脑子里出现的是“设备接上后，工位自己会动起来”。这当然很诱人，但企业版并没有把自动化做成黑盒魔法。
mrp_workorder_iot 先在 mrp.workcenter 上新增 trigger_ids，再定义独立的 iot.trigger 模型。一个 trigger 至少包含：键盘型 device_id、触发键 key、所属 workcenter_id 和具体 action。支持的动作也不是无限自由文本，而是枚举好的 SKIP、PAUS、VALI、FINI、RECO、PROP、PRSL、PRNT、PACK、SCRA 等。
这说明企业版的自动化思想很务实：不是“任何设备事件都能随便触发任何操作”，而是先把某个工作中心允许哪些按键动作说清楚。再加上 device_id 域限制为 type = keyboard，你会发现它优先解决的是现场按钮盒、扫码键盘这类稳定输入源，而不是追求万物互联的炫技。
quality.py 里的 _compute_boxes() 更进一步把这些触发器按 IoT box 的 IP 聚合，再输出成 JSON。也就是说，前端不是只拿到一堆触发记录，而是拿到“哪台盒子上有哪些设备、每个设备什么键对应什么动作”的可执行映射表。这种按 box 分组的做法，能明显降低现场多盒子、多设备时的混乱。
action_print() 则体现了另一个常见边界：打印不是触发器动作的副产品，而是单独绑定到质检点设备。只要 quality_point_id.device_id 存在，返回动作里就会带上 device_ids，把打印任务定向发给指定硬件。也就是说，企业版区分“按钮触发作业动作”和“把打印发送到哪台设备”，这两件事不能混为一谈。
实施时最容易踩坑的地方，是把 IoT 设备接入当成业务规则配置的替代品。设备连上、盒子在线，只说明硬件通了；真正决定现场是否可用的，是 trigger 键位、工作中心绑定、动作枚举，以及打印设备是否正确挂在质量点上。
所以企业版 IoT 工位触发的核心，不是自动化本身，而是把自动化拆成一组可审计、可绑定、可限制的现场映射规则。
DISCUSSION
评论区