1. 项目背景与整体设计思路做物联网平台这件事我在不同阶段踩过不少坑。早期用某云厂商的物联网套件设备接入倒是快但问题出在数据闭环上——设备报警了告警推送停在手机App里运维人员看完还得手工去ERP系统登记维修单一忙起来就漏登记尤其夜班报警第二天早上才发现设备已经带病跑了一整夜。所以当某工厂找到我想做一个能覆盖“设备状态采集—异常识别—自动生成维修工单”全链路的内部平台时我几乎没犹豫就确定了技术组合Go 写物联网接入与业务服务Odoo 承担 ERP 侧的设备档案、维修工单和备件管理。核心目标只有一个设备数据到了异常判断做完维修单能自动落到 ERP 系统里全程不需要人手工搬运数据。这个标题描述的场景本质上解决的是物联网系统与ERP系统之间的数据孤岛问题。设备产生了异常信号如果只是在物联平台弹一条告警价值和一条手机推送没区别真正有价值的是让告警直接驱动企业业务流程——生成维修单、通知维修班组、关联设备备件、跟踪维修闭环。1.1 为什么选 Go Odoo而不是其他组合先说 Go。我在选型时也犹豫过要不要用 Java 或者 Node.js但最终 Go 胜出的理由非常实际并发模型适合设备接入。一个工厂几百台设备每台设备几秒上报一次数据意味着每秒几百上千条消息进来Go 的 goroutine 处理这种高并发 IO 场景非常自然代码写起来也不用像 Java 那样堆线程池配置。部署简单。编译出来就是一个二进制文件丢到服务器上就能跑对现场运维人员非常友好。某工厂的服务器环境比较老旧没有 DockerJava 项目光装 JRE、配环境变量就折腾半天Go 完全没有这个问题。内存占用低。这一点在工控机上尤其重要很多边缘网关内存只有几百MBGo 程序跑起来占用资源比 Java 少一个量级。再聊 Odoo。当时也考虑过用泛微、SAP 之类的大型 ERP但某工厂的需求是维修工单流程灵活、要能对接外部 API、预算有限、希望业务人员直接网页操作。Odoo 的吸引力在于开源社区版免费功能够用。设备管理、工单管理、库存管理这些模块开箱即用。API 成熟。支持 JSON-RPC 和 XML-RPC 两种外部调用方式方便 Go 服务集成。工作流可配置。维修单的审批、派工、结单流程可以通过 Odoo Studio 或直接在代码里调整不用每次改动都找厂商。这个组合的定位是Go 负责实时数据处理和业务编排Odoo 负责企业流程和状态沉淀各干各擅长的事。1.2 系统架构与核心流程整个系统的架构可以概括成“三横一纵”接入层设备通过 MQTT 协议上报数据到 EMQX BrokerGo 服务作为 MQTT 客户端订阅所有设备主题实时消费数据。处理层Go 服务完成数据解析、异常检测、告警判定并将设备实时状态同步到 Redis历史数据批量写入 时序数据库这里用的某开源时序库。业务层Go 服务通过 Odoo 外部 API 创建设备维修工单触发 Odoo 内部的消息通知把维修任务分配到对应班组。核心流程是这样的设备上报数据 - MQTT Broker - Go 服务消费消息 - 异常检测引擎判断 - 正常仅更新 Redis 设备状态 - 异常写入告警记录调用 Odoo API 创建维修单 - Odoo 维修单创建成功 - 回写维修单号到平台 - 通知对应维修人员这个流程里最关键的设计点是把实时处理和历史记录分开。设备数据量大如果每一条都直接写数据库磁盘和数据库压力都会很大但如果只依赖内存判断又没法追溯历史趋势。所以做了分层实时判断走内存和 Redis历史数据异步批量落库保证热路径的响应速度。1.3 关键模块拆解整个系统拆成六个模块每个模块的职责边界非常清晰模块职责关键点设备接入服务MQTT 订阅、消息解析、协议适配多协议兼容、断线重连实时数据处理数据清洗、单位换算、数据补全容错处理脏数据异常检测引擎阈值判断、趋势判断、状态机规则可配置、防误报告警中心告警生成、告警分级、升级策略避免告警风暴Odoo 集成服务工单创建、设备关联、状态回写API 调用、幂等控制运维看板设备状态总览、异常趋势、工单跟踪数据可视化每个模块都可以独立部署、独立升级。比如刚开始异常检测引擎只做了简单的阈值判断后来逐步加了趋势分析和状态机这个过程不用动其他模块只要保证接口没破坏就行。2. 设备接入与数据链路搭建2.1 设备端协议选型为什么是 MQTT物联网设备接入的协议选择其实就那么几种HTTP 轮询、CoAP、MQTT、Modbus TCP 直连。我最后选了 MQTT原因是它天然适合“大量设备 低带宽 不稳定的网络环境”这种场景。MQTT 是发布订阅模式设备只负责发布消息到主题服务端只负责订阅主题消费消息设备不用关心服务端的 IP 和端口除了 Broker这对现场网络环境复杂、设备经常移动的场景非常友好。某工厂的设备用的是某款工业网关支持 MQTT 协议上报 JSON 格式的数据。每台设备会上报几个主题factory/device/{device_id}/telemetry实时遥测数据包括温度、压力、振动、转速等。factory/device/{device_id}/status设备启停状态、故障码。factory/device/{device_id}/event设备主动上报的事件比如急停、开门、参数变更。设备侧配置比较简单无非是 Broker 地址、端口、ClientID用设备唯一编号、用户名密码、上报周期。这里特别提醒一下ClientID 必须全局唯一否则多个设备同时在线时会发生互相踢下线的问题这是 MQTT 协议的特性踩过坑的人都知道这个痛苦。2.2 Go 接入服务设计与实现Go 这边我用的是某开源 MQTT 客户端库支持 QoS 0/1/2 三种消息质量级别重连机制也比较完善。核心代码逻辑其实不复杂但有几个细节需要注意// MQTT 消息处理的核心结构体 type MQTTService struct { client mqtt.Client deviceSvc *DeviceService alarmEngine *AlarmEngine odooSvc *OdooService } // 订阅消息的回调函数 func (s *MQTTService) handleMessage(_ mqtt.Client, msg mqtt.Message) { // 1. 从主题中解析设备ID deviceID, err : parseDeviceIDFromTopic(msg.Topic()) if err ! nil { logrus.WithField(topic, msg.Topic()).Error(解析设备ID失败) return } // 2. 解析消息内容JSON格式 var payload map[string]interface{} if err : json.Unmarshal(msg.Payload(), payload); err ! nil { logrus.WithField(device_id, deviceID).Warn(设备上报数据解析失败) return } // 3. 设备数据标准化处理 metric, err : s.deviceSvc.Standardize(deviceID, payload) if err ! nil { logrus.WithField(device_id, deviceID).Error(数据标准化失败) return } // 4. 送入实时判断引擎异步避免阻塞消息循环 s.alarmEngine.ProcessMetric(metric) }这个结构最大的好处是消息处理不走阻塞路径ProcessMetric内部是异步的这样即使某台设备的处理逻辑很慢也不会拖累整个系统的吞吐量。但这样设计也有一个坑异步处理在系统重启时容易丢消息。MQTT QoS 1 能保证消息不丢失但可能重复所以在落库之前必须做去重处理。我的方案是每条消息带一个自增序号seq设备每 5 秒上报一次序号单调递增。Go 服务在 Redis 里维护每个设备最近一条消息的 seq新消息的 seq 如果小于等于已处理的 seq直接丢弃。2.3 设备数据标准化与存储设备上报的数据格式五花八门有的字段叫temp有的叫temperature有的上报的是华氏度有的是摄氏度还有的单位是 kPa 但系统里要换算成 MPa。所以我做了数据标准化层核心逻辑是统一字段命名所有设备的遥测数据统一转换为temperature、pressure、vibration、rotation_speed四个核心指标。统一单位温度统一为摄氏度压力统一为 MPa振动统一为 mm/s。统一精度浮点数统一保留两位小数。这个标准化层非常关键后续所有的异常检测规则、阈值配置、告警展示都基于标准字段不用为每个设备单独写判断逻辑。配置层面用一张映射表维护# 设备字段映射配置示例 device_type: centrifuge field_mapping: temp: temperature press: pressure vib: vibration speed: rotation_speed unit_conversion: press: kPa_to_MPa # 数值除以1000数据存储分两层实时数据存 RedisTTL 设置为 24 小时历史数据异步写入时序库。时序库的写入策略是批量写入每 5 秒 flush 一次减少 IO 压力。实际跑下来一个月的数据量大概 2TB 左右300 台设备每 5 秒一条时序库的压缩比不错实际磁盘占用约 300GB完全在可接受范围。3. 异常检测与告警规则设计这是整个平台最核心的部分也是用户满意度影响最大的模块。如果异常检测太灵敏一天几百条告警运维人员会直接忽略所有告警如果太迟钝设备坏了半天没人发现自动生成工单就失去了意义。3.1 阈值检测与动态基线最开始做的是最简单的阈值判断温度超过 80 摄氏度就报警压力超过 1.2 MPa 就报警。但在实际测试中发现静态阈值完全不够用离心机在启动瞬间转速从 0 直接到 3000 转/分钟振动值会有一个尖峰如果阈值设低了会误报。不同设备的正常工况不一样同型号设备在不同原料批次下的温度基线也不同。夏天环境温度高设备散热差正常运行温度可能比冬天高 10 度。所以后来引入了动态基线算法。基本思路是以过去 24 小时的数据为样本计算每个时间段按小时的均值和标准差用“当前值 均值 3倍标准差”作为异常判据。这个方案我参考了一些时序异常检测的实践实现起来也不复杂。// 动态基线异常判断核心逻辑 func (e *AlarmEngine) checkDynamicBaseline(deviceID string, metric string, value float64) bool { // 获取过去24小时的样本数据按小时分组 samples : e.metricCache.GetLast24Hours(deviceID, metric) hour : time.Now().Hour() hourSamples : samples[hour] if len(hourSamples) 30 { // 样本不足退化为静态阈值 return value e.getStaticThreshold(metric) } mean : calculateMean(hourSamples) stddev : calculateStddev(hourSamples) // 当前值超过均值3*标准差判定为异常 threshold : mean 3*stddev return value threshold }这个方案跑了一段时间后误报率显著下降。但动态基线也有个问题如果设备已经坏了很多天坏数据会被当成正常基线。所以我又加了一个约束基线样本只取“设备健康状态”时段的数据如果设备当时正处于告警状态该时段数据不参与基线计算。3.2 告警分级与升级策略告警不能全一个级别否则关键时刻分不清轻重。我按照设备故障的严重程度和影响范围设置了四级告警级别含义响应时限示例P0紧急停机、安全风险5分钟电机超温、急停触发P1严重故障、影响生产30分钟振动严重超标、压力过高P2一般故障、需监控4小时温度偏高、运行效率下降P3提示信息24小时润滑周期到期、参数漂移不同级别的告警触发的动作不一样P3只在平台内记录不生成维修单减少噪音。P2生成维修单并通知班组长要求在 4 小时内确认。P1生成维修单同时通过短信和电话语音通知设备主管。P0生成维修单同时触发设备安全联锁通过反向 MQTT 指令让设备降载或停机。告警升级策略也很重要。比如 P2 告警生成了维修单但 4 小时内没有人接单系统会自动升级到 P1重新分配维修班组并通知上一级主管。这个策略是用 Odoo 的定时任务Cron Job实现的每 5 分钟扫描一次未接单的工单。3.3 避免误报的三道闸门误报是告警系统最大的敌人实际运行中我做了三道防线第一道短时滤波。瞬时跳变不触发告警必须是连续 3 次采样15 秒都超过阈值才确认异常。这个机制过滤掉了传感器本身噪声和瞬时干扰。第二道交叉验证。同一设备如果有多个传感器异常信号需要至少两个指标同时超限才触发。比如振动值高同时转速异常才判定为机械故障只有振动值高但转速正常可能只是传感器本身接触不良标记为疑似传感器故障不生成维修单。第三道人工复核窗口。这个设计比较巧妙——设备产生告警后系统不会立即生成维修单而是先进入 30 秒的“确认窗口”。在这 30 秒内如果后续数据恢复正常告警自动撤销如果继续异常才触发维修单创建。这个逻辑借鉴了断路器模式效果非常好能过滤掉不少一次性扰动。但人工复核窗口带来的一个问题是维修单生成时间延后了 30 秒。对于 P0 级告警这个延迟不能接受。所以 P0 级别不走确认窗口直接创建维修单并触发联动。4. 对接 Odoo 生成维修单的实现细节4.1 Odoo 外部 API 的两种对接方式Odoo 对外提供两种远程调用接口XML-RPC 和 JSON-RPC。我一开始用的 XML-RPC因为网上资料多、案例多很多老项目都是用这种协议对接的。但实际用下来发现 XML-RPC 的调试很痛苦返回的数据结构比较啰嗦而且 Python 生态之外的客户端库支持不够好。后来切换到 JSON-RPC同样用execute_kw方法Go 侧只需要发一个 HTTP POST 请求就行了数据结构清晰调试也方便。Odoo 从 13 版本开始 JSON-RPC 的接口已经很稳定了。调用 Odoo 创建维修单的交互流程Go 服务 - POST /web/dataset/call_kw - 认证API 密钥 - 调用维修单模型的 create 方法 - 传入工单数据设备ID、故障描述、级别、报修人 - 等待 Odoo 返回新工单 ID4.2 用 Go 调用 Odoo API 创建维修单这里给出一个核心的代码片段展示 Go 服务如何调用 Odoo 的 JSON-RPC 接口创建维修单package odoo import ( bytes encoding/json fmt net/http time ) // OdooClient 是 Odoo API 的客户端封装 type OdooClient struct { BaseURL string DB string Username string Password string UID int HTTPClient *http.Client } // CallKw 调用 Odoo 的通用 JSON-RPC 方法 func (c *OdooClient) CallKw(model string, method string, args []interface{}, kwargs map[string]interface{}) (interface{}, error) { payload : map[string]interface{}{ jsonrpc: 2.0, method: call, params: map[string]interface{}{ model: model, method: method, args: args, kwargs: kwargs, context: map[string]interface{}{ lang: zh_CN, }, }, } body, _ : json.Marshal(payload) req, _ : http.NewRequest(POST, c.BaseURL/web/dataset/call_kw, bytes.NewBuffer(body)) req.Header.Set(Content-Type, application/json) req.SetBasicAuth(c.Username, c.Password) resp, err : c.HTTPClient.Do(req) if err ! nil { return nil, fmt.Errorf(调用Odoo接口失败: %w, err) } defer resp.Body.Close() var result map[string]interface{} if err : json.NewDecoder(resp.Body).Decode(result); err ! nil { return nil, err } if result[error] ! nil { return nil, fmt.Errorf(Odoo返回错误: %v, result[error]) } return result[result], nil } // CreateMaintenanceOrder 创建维修单 func (c *OdooClient) CreateMaintenanceOrder(params MaintenanceOrderParams) (int, error) { values : map[string]interface{}{ x_device_id: params.DeviceID, x_device_name: params.DeviceName, x_fault_desc: params.FaultDesc, x_alarm_level: params.AlarmLevel, x_repair_team: params.RepairTeam, x_source: iot_platform, // 标记来源方便追踪 x_platform_alarm_id: params.AlarmID, // 平台侧告警ID做幂等用 name: fmt.Sprintf([IoT] %s - %s, params.DeviceName, params.FaultDesc), } result, err : c.CallKw(x_maintenance.order, create, []interface{}{values}, map[string]interface{}{}) if err ! nil { return 0, err } // Odoo 的 create 返回新记录的 ID if id, ok : result.(float64); ok { return int(id), nil } return 0, fmt.Errorf(Odoo返回格式异常: %v, result) }这里我用的是 Odoo 的x_自定义字段而不是标准的维修工单模型maintenance.request因为某工厂的工单流程比较特殊需要挂接设备编号、告警级别、平台告警 ID 等自定义属性。在 Odoo 里通过“开发者模式-技术-字段”创建这些自定义字段过程不算复杂但需要点耐心。身份证级的建议所有通过 API 对接的字段最好都加上 x_ 前缀这样一眼就能看出是从外部系统同步过来的字段避免和 Odoo 原生的name、date_deadline这些字段混淆。另外记得给这些字段加上索引否则数据量上来后查询会非常慢。4.3 内外账号联动与状态同步设备告警自动生成的维修单最终是要让维修班组去处理的。这里有个关键问题维修班组的人不一定会登录物联网平台他们只会在 Odoo 里看工单。所以我的做法是工单会显示一个来源标签[IoT]同时显示设备编号和故障描述。维修人员只需要在 Odoo 里完成接单、填写处理情况、关闭工单。Odoo 侧通过一个服务器动作基于webhook或cron将工单状态变更推送到 Go 服务或由 Go 服务定时轮询。Go 服务拿到最新状态后更新本地告警的状态——比如“维修中”、“已修复”等。状态同步的方式我最初用的是 Odoo webhookOdoo 在工单状态变化时调用 Go 服务的 HTTP 接口。但实际运行中发现 Odoo 的 webhook 不稳定经常有消息丢失的情况。后来改成了 Go 服务每分钟轮询一次 Odoo 接口获取最近变更的工单记录再同步到本地。轮询虽然有一点延迟但保证不丢数据可靠性优先。状态同步需要注意防止循环调用。Go 服务创建了维修单维修单状态变化时 Odoo 通知 Go 服务Go 服务又更新告警这个链路中要加一个标识避免 Odoo 状态变化回调又触发 Go 服务去创建新的工单。我的方案是在创建工单时设置x_source iot_platformGo 服务只在创建新工单时检查这个标记不会因为维修单状态变化再创建新的维修单从而打断了循环。5. 常见问题与排查技巧实录项目上线不是终点稳定运行才是考验。这半年里遇到的各种问题挑几个有代表性的分享出来希望能帮后来者少走弯路。5.1 MQTT 断线重连与消息积压问题上线初期遇到最头疼的问题就是 MQTT 断线。现场的网络环境比办公室复杂得多设备经常因为网络抖动和 Broker 断开连接。而且有些网关设备的 MQTT 客户端实现不完善重连逻辑写得不好经常出现“假死”状态——设备看起来在线但已经停止了数据上报。排查过程首先在 Broker 侧开启了 WebHook监听设备上下线事件。然后用一个定时任务每 10 分钟检查一次每台设备的最后上报时间如果超过 3 个上报周期没有新数据判定设备“失联”在平台标记为离线。人工去现场查看那台网关发现是网关的 TCP 长连接没有设置心跳被中间的路由器 NAPT 表项清除后连接断开了但网关不自知也不主动重连。解决方案是让设备侧每 30 秒发送一次 MQTT PingReq心跳包并将 MQTT KeepAlive 参数设置为 60 秒。如果 3 次心跳没有收到 PingResp 就主动重连重连的时间退避策略是1 秒、2 秒、4 秒、8 秒……最长 60 秒避免同时大量设备重连造成 Broker 压力过大。遇到消息积压的问题某次 Broker 挂了 20 分钟重启积压了约 1 万条设备消息。Go 服务恢复消费后由于处理速度跟不上在 Redis 里积压了大量待处理数据。这个问题的教训是一定要在下游存储时序库、Redis的 IO 路径上做熔断和限流。后来我在时序库写入层加了令牌桶限流同时扩充了消费者 goroutine 的数量从默认的 4 个扩展到 16 个。5.2 消息乱序与幂等控制MQTT 的 QoS 1 保证消息至少送达一次但不保证顺序也不保证不重复。实际运行中确实遇到了几次乱序问题某设备上报温度先报 90 度异常再报 95 度异常。但因为网络原因90 度这条消息后到了。异常检测引擎先看到 95 度触发了 P1 告警然后 90 度消息到达判断结果也是异常又触发了一次 P1 告警重复生成两张维修单。解决思路分两层第一层按设备串行处理。Go 接入服务里给每台设备分配一个独立的 goroutine带缓冲的 channel同一台设备的消息严格按 seq 序号排序后逐个处理。Redis 里记录每个设备最后处理的 seq新消息 seq 小于等于记录的直接丢弃。这样从源头上保证进入检测引擎的消息是有序且不重复的。第二层检测侧幂等。告警检测引擎里维护设备的当前状态正常/告警只有在状态发生转换时才触发新的告警动作。比如设备持续超温只会在第一次超温时创建维修单后续的超温数据不会继续触发。只有当这个告警解除设备恢复正常后再次发生超温才会创建新维修单。这个“状态机”设计避免了很多重复工单。5.3 Odoo 接口调用的几个经典坑第一个坑是 Odoo 的日期字段格式。通过 JSON-RPC 传日期必须用 ISO 8601 格式而且 Odoo 对时区非常敏感。如果直接传2024-08-01 15:30:00Odoo 会把它当成 UTC 时间东八区的用户看到的时间会多 8 个小时。解决办法是在请求上下文中设置tz为Asia/Shanghai。第二个坑是 Odoo 的create方法返回 ID 时的类型问题。在 JSON-RPC 中返回的整数在 Go 的interface{}里很可能被解析成float64这就是我在代码里做的类型断言result.(float64)的原因。这个小问题曾经让我排查了半天最后用日志打印%T才发现类型不匹配。第三个坑是 Odoo 的权限模型。外部 API 调用时用的是 API 账户如果没有对应的访问权限create操作会静默失败或报权限错误。而且 Odoo 的“记录规则”Record Rules也会影响可见性默认情况下外部 API 账户只能访问自己创建的数据需要到“设置-安全-记录规则”里针对x_maintenance.order模型配置全局可见和全局创建权限。5.4 常见问题速查表问题现象可能原因排查步骤解决方案设备显示离线但网关正常MQTT 心跳设置不合理查看 Broker 在线列表设备侧配置 KeepAlive60s启用主动重连维修单重复创建消息乱序或重复Redis 查询设备最近 seq按设备串行处理 告警状态机工单日期相差 8 小时时区配置不一致查看请求上下文JSON-RPC 请求体中设置tz: Asia/ShanghaiOdoo API 返回权限错误API 账户权限不足查看 Odoo 日志给 API 账户配置模型级读写权限历史数据查询缓慢时序库未建立标签索引EXPLAIN 查询计划为 device_id 和 metric 字段建索引告警太多太频繁阈值设置太敏感分析告警趋势调高阈值倍数加入短时滤波这里再分享一个独门排错技巧在 Go 服务里给每一条关键路径都打上结构化日志设备ID、消息ID、处理耗时。刚开始觉得很繁琐但真正排查问题时这些日志的价值远超预期。生产环境我直接用文件收集日志写入本地并推送到日志分析平台做检索。比较好的效果是某次 Odoo 接口响应变慢从日志里看到调用耗时从 50ms 涨到了 800ms提前发现了 Odoo 数据库连接池打满的问题。6. 项目上线后的实际效果与优化空间6.1 上线前后的数据对比这个系统上线稳定运行了三个月后我做了一次数据对比效果很明显指标上线前上线后设备异常发现到生成维修单的时间平均 2.5 小时人工发现平均 30 秒自动检测维修单漏登记率约 15%夜班尤其严重0%平均维修响应时间4 小时1.5 小时设备非计划停机次数月均 5 次月均 2 次最典型的一次某台压缩机在凌晨 2 点发生振动异常系统在 35 秒内生成了 P1 级维修单并短信通知了设备主管维修班组早上 6 点就完成了轴承更换。放在以前这种夜间故障最快也要等到早上巡检才能发现至少损失半天生产时间。但这个项目也有很多可以优化的地方这也是我想重点说的任何事情都是迭代出来的。6.2 项目局限与后续优化思路第一告警规则的配置化程度还不够。目前规则还是写在 Go 代码里的调整阈值需要改代码重新编译发布。对运维人员来说最好是在管理后台可视化配置规则。我建议后续可以引入规则引擎比如把规则存在 时序数据库 或独立的 MQTT 主题里通过配置下发的方式动态更新。第二Odoo 侧还可以做更多自动化。目前只是自动创建了维修单但后续的维修进度跟踪比如备件领用、工时填报还是人工在 Odoo 里操作。理论上可以在 Go 服务里做库存联动——当维修单关联了备件更换自动从 Odoo 库存中预留或扣减对应备件这部分流程跑通后备件管理的效率还能提升一大截。第三设备预测性维护是个大方向。目前的异常检测是基于实时数据的反应式判断也就是“发生异常了才知道”。后续可以基于时序数据做趋势预测比如振动值连续一周上升虽然还没超过阈值但预测未来 3 天可能发生故障提前安排计划性检修。这样能把“被动维修”变成“主动维护”大幅降低非计划停机时间。第四边缘计算能力还没用起来。现在所有设备数据都往云端传如果直接在边缘网关侧做初步的异常预判比如简单的阈值和趋势判断只在异常时才向云端上报可以大幅降低网络带宽和云端计算压力。这也是后续可以考虑的方向。6.3 给后来者的几点建议如果看文章的你正准备做类似的物联网ERP 集成项目我个人的经验建议是先理业务流程再定技术架构。物联网平台本身好做难的是理解企业实际的维修流程。一定要花时间去设备现场看一遍和维修师傅聊一聊设备多久保养一次故障报修是走什么流程谁负责审批谁负责接单只有把这些业务流程吃透了才能在 Odoo 里做出真正符合实际的操作界面和工作流。数据结构设计要留出扩展余地。设备类型会变、传感器会加、业务字段会调整数据库设计时不要过度规范化导致后面扩展困难。我在设备遥测数据表里用 JSON 字段存储附加指标虽然违背了“规范化”的理念但换来的是极强的灵活性。小步快跑先做最核心的闭环。第一个版本不用做得很完美能跑通“设备异常 - 自动生成维修单”这个核心闭环就够了。等用户用起来、反馈来了再逐步加功能、优化体验。我第一版只有阈值告警和工单自动创建两个功能上线用了两周后才有信心逐步增加动态基线、告警分级、状态同步这些进阶能力。技术选型和架构设计都是可以讨论和调整的但有一个原则不能变系统最终是给现场用户用的用户觉得好用、愿意用才是真正的成功指标。这套 Go Odoo 的平台从设备数据接入到 ERP 工单闭环技术本身没什么稀奇但确实解决了工厂真实的问题减少了设备故障的漏发现、漏登记缩短了维修响应时间。这种“把对的技术用在真正有价值的地方”的成就感大概就是我坚持做这块的原因吧。 
长河君 · 2026/10/11 5:09:27 · 阅读 1.2k Go与Odoo构建物联网平台：从设备数据采集到自动生成维修工单
1. 项目背景与整体设计思路做物联网平台这件事我在不同阶段踩过不少坑。早期用某云厂商的物联网套件设备接入倒是快但问题出在数据闭环上——设备报警了告警推送停在手机App里运维人员看完还得手工去ERP系统登记维修单一忙起来就漏登记尤其夜班报警第二天早上才发现设备已经带病跑了一整夜。所以当某工厂找到我想做一个能覆盖“设备状态采集—异常识别—自动生成维修工单”全链路的内部平台时我几乎没犹豫就确定了技术组合Go 写物联网接入与业务服务Odoo 承担 ERP 侧的设备档案、维修工单和备件管理。核心目标只有一个设备数据到了异常判断做完维修单能自动落到 ERP 系统里全程不需要人手工搬运数据。这个标题描述的场景本质上解决的是物联网系统与ERP系统之间的数据孤岛问题。设备产生了异常信号如果只是在物联平台弹一条告警价值和一条手机推送没区别真正有价值的是让告警直接驱动企业业务流程——生成维修单、通知维修班组、关联设备备件、跟踪维修闭环。1.1 为什么选 Go Odoo而不是其他组合先说 Go。我在选型时也犹豫过要不要用 Java 或者 Node.js但最终 Go 胜出的理由非常实际并发模型适合设备接入。一个工厂几百台设备每台设备几秒上报一次数据意味着每秒几百上千条消息进来Go 的 goroutine 处理这种高并发 IO 场景非常自然代码写起来也不用像 Java 那样堆线程池配置。部署简单。编译出来就是一个二进制文件丢到服务器上就能跑对现场运维人员非常友好。某工厂的服务器环境比较老旧没有 DockerJava 项目光装 JRE、配环境变量就折腾半天Go 完全没有这个问题。内存占用低。这一点在工控机上尤其重要很多边缘网关内存只有几百MBGo 程序跑起来占用资源比 Java 少一个量级。再聊 Odoo。当时也考虑过用泛微、SAP 之类的大型 ERP但某工厂的需求是维修工单流程灵活、要能对接外部 API、预算有限、希望业务人员直接网页操作。Odoo 的吸引力在于开源社区版免费功能够用。设备管理、工单管理、库存管理这些模块开箱即用。API 成熟。支持 JSON-RPC 和 XML-RPC 两种外部调用方式方便 Go 服务集成。工作流可配置。维修单的审批、派工、结单流程可以通过 Odoo Studio 或直接在代码里调整不用每次改动都找厂商。这个组合的定位是Go 负责实时数据处理和业务编排Odoo 负责企业流程和状态沉淀各干各擅长的事。1.2 系统架构与核心流程整个系统的架构可以概括成“三横一纵”接入层设备通过 MQTT 协议上报数据到 EMQX BrokerGo 服务作为 MQTT 客户端订阅所有设备主题实时消费数据。处理层Go 服务完成数据解析、异常检测、告警判定并将设备实时状态同步到 Redis历史数据批量写入 时序数据库这里用的某开源时序库。业务层Go 服务通过 Odoo 外部 API 创建设备维修工单触发 Odoo 内部的消息通知把维修任务分配到对应班组。核心流程是这样的设备上报数据 - MQTT Broker - Go 服务消费消息 - 异常检测引擎判断 - 正常仅更新 Redis 设备状态 - 异常写入告警记录调用 Odoo API 创建维修单 - Odoo 维修单创建成功 - 回写维修单号到平台 - 通知对应维修人员这个流程里最关键的设计点是把实时处理和历史记录分开。设备数据量大如果每一条都直接写数据库磁盘和数据库压力都会很大但如果只依赖内存判断又没法追溯历史趋势。所以做了分层实时判断走内存和 Redis历史数据异步批量落库保证热路径的响应速度。1.3 关键模块拆解整个系统拆成六个模块每个模块的职责边界非常清晰模块职责关键点设备接入服务MQTT 订阅、消息解析、协议适配多协议兼容、断线重连实时数据处理数据清洗、单位换算、数据补全容错处理脏数据异常检测引擎阈值判断、趋势判断、状态机规则可配置、防误报告警中心告警生成、告警分级、升级策略避免告警风暴Odoo 集成服务工单创建、设备关联、状态回写API 调用、幂等控制运维看板设备状态总览、异常趋势、工单跟踪数据可视化每个模块都可以独立部署、独立升级。比如刚开始异常检测引擎只做了简单的阈值判断后来逐步加了趋势分析和状态机这个过程不用动其他模块只要保证接口没破坏就行。2. 设备接入与数据链路搭建2.1 设备端协议选型为什么是 MQTT物联网设备接入的协议选择其实就那么几种HTTP 轮询、CoAP、MQTT、Modbus TCP 直连。我最后选了 MQTT原因是它天然适合“大量设备 低带宽 不稳定的网络环境”这种场景。MQTT 是发布订阅模式设备只负责发布消息到主题服务端只负责订阅主题消费消息设备不用关心服务端的 IP 和端口除了 Broker这对现场网络环境复杂、设备经常移动的场景非常友好。某工厂的设备用的是某款工业网关支持 MQTT 协议上报 JSON 格式的数据。每台设备会上报几个主题factory/device/{device_id}/telemetry实时遥测数据包括温度、压力、振动、转速等。factory/device/{device_id}/status设备启停状态、故障码。factory/device/{device_id}/event设备主动上报的事件比如急停、开门、参数变更。设备侧配置比较简单无非是 Broker 地址、端口、ClientID用设备唯一编号、用户名密码、上报周期。这里特别提醒一下ClientID 必须全局唯一否则多个设备同时在线时会发生互相踢下线的问题这是 MQTT 协议的特性踩过坑的人都知道这个痛苦。2.2 Go 接入服务设计与实现Go 这边我用的是某开源 MQTT 客户端库支持 QoS 0/1/2 三种消息质量级别重连机制也比较完善。核心代码逻辑其实不复杂但有几个细节需要注意// MQTT 消息处理的核心结构体 type MQTTService struct { client mqtt.Client deviceSvc *DeviceService alarmEngine *AlarmEngine odooSvc *OdooService } // 订阅消息的回调函数 func (s *MQTTService) handleMessage(_ mqtt.Client, msg mqtt.Message) { // 1. 从主题中解析设备ID deviceID, err : parseDeviceIDFromTopic(msg.Topic()) if err ! nil { logrus.WithField(topic, msg.Topic()).Error(解析设备ID失败) return } // 2. 解析消息内容JSON格式 var payload map[string]interface{} if err : json.Unmarshal(msg.Payload(), payload); err ! nil { logrus.WithField(device_id, deviceID).Warn(设备上报数据解析失败) return } // 3. 设备数据标准化处理 metric, err : s.deviceSvc.Standardize(deviceID, payload) if err ! nil { logrus.WithField(device_id, deviceID).Error(数据标准化失败) return } // 4. 送入实时判断引擎异步避免阻塞消息循环 s.alarmEngine.ProcessMetric(metric) }这个结构最大的好处是消息处理不走阻塞路径ProcessMetric内部是异步的这样即使某台设备的处理逻辑很慢也不会拖累整个系统的吞吐量。但这样设计也有一个坑异步处理在系统重启时容易丢消息。MQTT QoS 1 能保证消息不丢失但可能重复所以在落库之前必须做去重处理。我的方案是每条消息带一个自增序号seq设备每 5 秒上报一次序号单调递增。Go 服务在 Redis 里维护每个设备最近一条消息的 seq新消息的 seq 如果小于等于已处理的 seq直接丢弃。2.3 设备数据标准化与存储设备上报的数据格式五花八门有的字段叫temp有的叫temperature有的上报的是华氏度有的是摄氏度还有的单位是 kPa 但系统里要换算成 MPa。所以我做了数据标准化层核心逻辑是统一字段命名所有设备的遥测数据统一转换为temperature、pressure、vibration、rotation_speed四个核心指标。统一单位温度统一为摄氏度压力统一为 MPa振动统一为 mm/s。统一精度浮点数统一保留两位小数。这个标准化层非常关键后续所有的异常检测规则、阈值配置、告警展示都基于标准字段不用为每个设备单独写判断逻辑。配置层面用一张映射表维护# 设备字段映射配置示例 device_type: centrifuge field_mapping: temp: temperature press: pressure vib: vibration speed: rotation_speed unit_conversion: press: kPa_to_MPa # 数值除以1000数据存储分两层实时数据存 RedisTTL 设置为 24 小时历史数据异步写入时序库。时序库的写入策略是批量写入每 5 秒 flush 一次减少 IO 压力。实际跑下来一个月的数据量大概 2TB 左右300 台设备每 5 秒一条时序库的压缩比不错实际磁盘占用约 300GB完全在可接受范围。3. 异常检测与告警规则设计这是整个平台最核心的部分也是用户满意度影响最大的模块。如果异常检测太灵敏一天几百条告警运维人员会直接忽略所有告警如果太迟钝设备坏了半天没人发现自动生成工单就失去了意义。3.1 阈值检测与动态基线最开始做的是最简单的阈值判断温度超过 80 摄氏度就报警压力超过 1.2 MPa 就报警。但在实际测试中发现静态阈值完全不够用离心机在启动瞬间转速从 0 直接到 3000 转/分钟振动值会有一个尖峰如果阈值设低了会误报。不同设备的正常工况不一样同型号设备在不同原料批次下的温度基线也不同。夏天环境温度高设备散热差正常运行温度可能比冬天高 10 度。所以后来引入了动态基线算法。基本思路是以过去 24 小时的数据为样本计算每个时间段按小时的均值和标准差用“当前值 均值 3倍标准差”作为异常判据。这个方案我参考了一些时序异常检测的实践实现起来也不复杂。// 动态基线异常判断核心逻辑 func (e *AlarmEngine) checkDynamicBaseline(deviceID string, metric string, value float64) bool { // 获取过去24小时的样本数据按小时分组 samples : e.metricCache.GetLast24Hours(deviceID, metric) hour : time.Now().Hour() hourSamples : samples[hour] if len(hourSamples) 30 { // 样本不足退化为静态阈值 return value e.getStaticThreshold(metric) } mean : calculateMean(hourSamples) stddev : calculateStddev(hourSamples) // 当前值超过均值3*标准差判定为异常 threshold : mean 3*stddev return value threshold }这个方案跑了一段时间后误报率显著下降。但动态基线也有个问题如果设备已经坏了很多天坏数据会被当成正常基线。所以我又加了一个约束基线样本只取“设备健康状态”时段的数据如果设备当时正处于告警状态该时段数据不参与基线计算。3.2 告警分级与升级策略告警不能全一个级别否则关键时刻分不清轻重。我按照设备故障的严重程度和影响范围设置了四级告警级别含义响应时限示例P0紧急停机、安全风险5分钟电机超温、急停触发P1严重故障、影响生产30分钟振动严重超标、压力过高P2一般故障、需监控4小时温度偏高、运行效率下降P3提示信息24小时润滑周期到期、参数漂移不同级别的告警触发的动作不一样P3只在平台内记录不生成维修单减少噪音。P2生成维修单并通知班组长要求在 4 小时内确认。P1生成维修单同时通过短信和电话语音通知设备主管。P0生成维修单同时触发设备安全联锁通过反向 MQTT 指令让设备降载或停机。告警升级策略也很重要。比如 P2 告警生成了维修单但 4 小时内没有人接单系统会自动升级到 P1重新分配维修班组并通知上一级主管。这个策略是用 Odoo 的定时任务Cron Job实现的每 5 分钟扫描一次未接单的工单。3.3 避免误报的三道闸门误报是告警系统最大的敌人实际运行中我做了三道防线第一道短时滤波。瞬时跳变不触发告警必须是连续 3 次采样15 秒都超过阈值才确认异常。这个机制过滤掉了传感器本身噪声和瞬时干扰。第二道交叉验证。同一设备如果有多个传感器异常信号需要至少两个指标同时超限才触发。比如振动值高同时转速异常才判定为机械故障只有振动值高但转速正常可能只是传感器本身接触不良标记为疑似传感器故障不生成维修单。第三道人工复核窗口。这个设计比较巧妙——设备产生告警后系统不会立即生成维修单而是先进入 30 秒的“确认窗口”。在这 30 秒内如果后续数据恢复正常告警自动撤销如果继续异常才触发维修单创建。这个逻辑借鉴了断路器模式效果非常好能过滤掉不少一次性扰动。但人工复核窗口带来的一个问题是维修单生成时间延后了 30 秒。对于 P0 级告警这个延迟不能接受。所以 P0 级别不走确认窗口直接创建维修单并触发联动。4. 对接 Odoo 生成维修单的实现细节4.1 Odoo 外部 API 的两种对接方式Odoo 对外提供两种远程调用接口XML-RPC 和 JSON-RPC。我一开始用的 XML-RPC因为网上资料多、案例多很多老项目都是用这种协议对接的。但实际用下来发现 XML-RPC 的调试很痛苦返回的数据结构比较啰嗦而且 Python 生态之外的客户端库支持不够好。后来切换到 JSON-RPC同样用execute_kw方法Go 侧只需要发一个 HTTP POST 请求就行了数据结构清晰调试也方便。Odoo 从 13 版本开始 JSON-RPC 的接口已经很稳定了。调用 Odoo 创建维修单的交互流程Go 服务 - POST /web/dataset/call_kw - 认证API 密钥 - 调用维修单模型的 create 方法 - 传入工单数据设备ID、故障描述、级别、报修人 - 等待 Odoo 返回新工单 ID4.2 用 Go 调用 Odoo API 创建维修单这里给出一个核心的代码片段展示 Go 服务如何调用 Odoo 的 JSON-RPC 接口创建维修单package odoo import ( bytes encoding/json fmt net/http time ) // OdooClient 是 Odoo API 的客户端封装 type OdooClient struct { BaseURL string DB string Username string Password string UID int HTTPClient *http.Client } // CallKw 调用 Odoo 的通用 JSON-RPC 方法 func (c *OdooClient) CallKw(model string, method string, args []interface{}, kwargs map[string]interface{}) (interface{}, error) { payload : map[string]interface{}{ jsonrpc: 2.0, method: call, params: map[string]interface{}{ model: model, method: method, args: args, kwargs: kwargs, context: map[string]interface{}{ lang: zh_CN, }, }, } body, _ : json.Marshal(payload) req, _ : http.NewRequest(POST, c.BaseURL/web/dataset/call_kw, bytes.NewBuffer(body)) req.Header.Set(Content-Type, application/json) req.SetBasicAuth(c.Username, c.Password) resp, err : c.HTTPClient.Do(req) if err ! nil { return nil, fmt.Errorf(调用Odoo接口失败: %w, err) } defer resp.Body.Close() var result map[string]interface{} if err : json.NewDecoder(resp.Body).Decode(result); err ! nil { return nil, err } if result[error] ! nil { return nil, fmt.Errorf(Odoo返回错误: %v, result[error]) } return result[result], nil } // CreateMaintenanceOrder 创建维修单 func (c *OdooClient) CreateMaintenanceOrder(params MaintenanceOrderParams) (int, error) { values : map[string]interface{}{ x_device_id: params.DeviceID, x_device_name: params.DeviceName, x_fault_desc: params.FaultDesc, x_alarm_level: params.AlarmLevel, x_repair_team: params.RepairTeam, x_source: iot_platform, // 标记来源方便追踪 x_platform_alarm_id: params.AlarmID, // 平台侧告警ID做幂等用 name: fmt.Sprintf([IoT] %s - %s, params.DeviceName, params.FaultDesc), } result, err : c.CallKw(x_maintenance.order, create, []interface{}{values}, map[string]interface{}{}) if err ! nil { return 0, err } // Odoo 的 create 返回新记录的 ID if id, ok : result.(float64); ok { return int(id), nil } return 0, fmt.Errorf(Odoo返回格式异常: %v, result) }这里我用的是 Odoo 的x_自定义字段而不是标准的维修工单模型maintenance.request因为某工厂的工单流程比较特殊需要挂接设备编号、告警级别、平台告警 ID 等自定义属性。在 Odoo 里通过“开发者模式-技术-字段”创建这些自定义字段过程不算复杂但需要点耐心。身份证级的建议所有通过 API 对接的字段最好都加上 x_ 前缀这样一眼就能看出是从外部系统同步过来的字段避免和 Odoo 原生的name、date_deadline这些字段混淆。另外记得给这些字段加上索引否则数据量上来后查询会非常慢。4.3 内外账号联动与状态同步设备告警自动生成的维修单最终是要让维修班组去处理的。这里有个关键问题维修班组的人不一定会登录物联网平台他们只会在 Odoo 里看工单。所以我的做法是工单会显示一个来源标签[IoT]同时显示设备编号和故障描述。维修人员只需要在 Odoo 里完成接单、填写处理情况、关闭工单。Odoo 侧通过一个服务器动作基于webhook或cron将工单状态变更推送到 Go 服务或由 Go 服务定时轮询。Go 服务拿到最新状态后更新本地告警的状态——比如“维修中”、“已修复”等。状态同步的方式我最初用的是 Odoo webhookOdoo 在工单状态变化时调用 Go 服务的 HTTP 接口。但实际运行中发现 Odoo 的 webhook 不稳定经常有消息丢失的情况。后来改成了 Go 服务每分钟轮询一次 Odoo 接口获取最近变更的工单记录再同步到本地。轮询虽然有一点延迟但保证不丢数据可靠性优先。状态同步需要注意防止循环调用。Go 服务创建了维修单维修单状态变化时 Odoo 通知 Go 服务Go 服务又更新告警这个链路中要加一个标识避免 Odoo 状态变化回调又触发 Go 服务去创建新的工单。我的方案是在创建工单时设置x_source iot_platformGo 服务只在创建新工单时检查这个标记不会因为维修单状态变化再创建新的维修单从而打断了循环。5. 常见问题与排查技巧实录项目上线不是终点稳定运行才是考验。这半年里遇到的各种问题挑几个有代表性的分享出来希望能帮后来者少走弯路。5.1 MQTT 断线重连与消息积压问题上线初期遇到最头疼的问题就是 MQTT 断线。现场的网络环境比办公室复杂得多设备经常因为网络抖动和 Broker 断开连接。而且有些网关设备的 MQTT 客户端实现不完善重连逻辑写得不好经常出现“假死”状态——设备看起来在线但已经停止了数据上报。排查过程首先在 Broker 侧开启了 WebHook监听设备上下线事件。然后用一个定时任务每 10 分钟检查一次每台设备的最后上报时间如果超过 3 个上报周期没有新数据判定设备“失联”在平台标记为离线。人工去现场查看那台网关发现是网关的 TCP 长连接没有设置心跳被中间的路由器 NAPT 表项清除后连接断开了但网关不自知也不主动重连。解决方案是让设备侧每 30 秒发送一次 MQTT PingReq心跳包并将 MQTT KeepAlive 参数设置为 60 秒。如果 3 次心跳没有收到 PingResp 就主动重连重连的时间退避策略是1 秒、2 秒、4 秒、8 秒……最长 60 秒避免同时大量设备重连造成 Broker 压力过大。遇到消息积压的问题某次 Broker 挂了 20 分钟重启积压了约 1 万条设备消息。Go 服务恢复消费后由于处理速度跟不上在 Redis 里积压了大量待处理数据。这个问题的教训是一定要在下游存储时序库、Redis的 IO 路径上做熔断和限流。后来我在时序库写入层加了令牌桶限流同时扩充了消费者 goroutine 的数量从默认的 4 个扩展到 16 个。5.2 消息乱序与幂等控制MQTT 的 QoS 1 保证消息至少送达一次但不保证顺序也不保证不重复。实际运行中确实遇到了几次乱序问题某设备上报温度先报 90 度异常再报 95 度异常。但因为网络原因90 度这条消息后到了。异常检测引擎先看到 95 度触发了 P1 告警然后 90 度消息到达判断结果也是异常又触发了一次 P1 告警重复生成两张维修单。解决思路分两层第一层按设备串行处理。Go 接入服务里给每台设备分配一个独立的 goroutine带缓冲的 channel同一台设备的消息严格按 seq 序号排序后逐个处理。Redis 里记录每个设备最后处理的 seq新消息 seq 小于等于记录的直接丢弃。这样从源头上保证进入检测引擎的消息是有序且不重复的。第二层检测侧幂等。告警检测引擎里维护设备的当前状态正常/告警只有在状态发生转换时才触发新的告警动作。比如设备持续超温只会在第一次超温时创建维修单后续的超温数据不会继续触发。只有当这个告警解除设备恢复正常后再次发生超温才会创建新维修单。这个“状态机”设计避免了很多重复工单。5.3 Odoo 接口调用的几个经典坑第一个坑是 Odoo 的日期字段格式。通过 JSON-RPC 传日期必须用 ISO 8601 格式而且 Odoo 对时区非常敏感。如果直接传2024-08-01 15:30:00Odoo 会把它当成 UTC 时间东八区的用户看到的时间会多 8 个小时。解决办法是在请求上下文中设置tz为Asia/Shanghai。第二个坑是 Odoo 的create方法返回 ID 时的类型问题。在 JSON-RPC 中返回的整数在 Go 的interface{}里很可能被解析成float64这就是我在代码里做的类型断言result.(float64)的原因。这个小问题曾经让我排查了半天最后用日志打印%T才发现类型不匹配。第三个坑是 Odoo 的权限模型。外部 API 调用时用的是 API 账户如果没有对应的访问权限create操作会静默失败或报权限错误。而且 Odoo 的“记录规则”Record Rules也会影响可见性默认情况下外部 API 账户只能访问自己创建的数据需要到“设置-安全-记录规则”里针对x_maintenance.order模型配置全局可见和全局创建权限。5.4 常见问题速查表问题现象可能原因排查步骤解决方案设备显示离线但网关正常MQTT 心跳设置不合理查看 Broker 在线列表设备侧配置 KeepAlive60s启用主动重连维修单重复创建消息乱序或重复Redis 查询设备最近 seq按设备串行处理 告警状态机工单日期相差 8 小时时区配置不一致查看请求上下文JSON-RPC 请求体中设置tz: Asia/ShanghaiOdoo API 返回权限错误API 账户权限不足查看 Odoo 日志给 API 账户配置模型级读写权限历史数据查询缓慢时序库未建立标签索引EXPLAIN 查询计划为 device_id 和 metric 字段建索引告警太多太频繁阈值设置太敏感分析告警趋势调高阈值倍数加入短时滤波这里再分享一个独门排错技巧在 Go 服务里给每一条关键路径都打上结构化日志设备ID、消息ID、处理耗时。刚开始觉得很繁琐但真正排查问题时这些日志的价值远超预期。生产环境我直接用文件收集日志写入本地并推送到日志分析平台做检索。比较好的效果是某次 Odoo 接口响应变慢从日志里看到调用耗时从 50ms 涨到了 800ms提前发现了 Odoo 数据库连接池打满的问题。6. 项目上线后的实际效果与优化空间6.1 上线前后的数据对比这个系统上线稳定运行了三个月后我做了一次数据对比效果很明显指标上线前上线后设备异常发现到生成维修单的时间平均 2.5 小时人工发现平均 30 秒自动检测维修单漏登记率约 15%夜班尤其严重0%平均维修响应时间4 小时1.5 小时设备非计划停机次数月均 5 次月均 2 次最典型的一次某台压缩机在凌晨 2 点发生振动异常系统在 35 秒内生成了 P1 级维修单并短信通知了设备主管维修班组早上 6 点就完成了轴承更换。放在以前这种夜间故障最快也要等到早上巡检才能发现至少损失半天生产时间。但这个项目也有很多可以优化的地方这也是我想重点说的任何事情都是迭代出来的。6.2 项目局限与后续优化思路第一告警规则的配置化程度还不够。目前规则还是写在 Go 代码里的调整阈值需要改代码重新编译发布。对运维人员来说最好是在管理后台可视化配置规则。我建议后续可以引入规则引擎比如把规则存在 时序数据库 或独立的 MQTT 主题里通过配置下发的方式动态更新。第二Odoo 侧还可以做更多自动化。目前只是自动创建了维修单但后续的维修进度跟踪比如备件领用、工时填报还是人工在 Odoo 里操作。理论上可以在 Go 服务里做库存联动——当维修单关联了备件更换自动从 Odoo 库存中预留或扣减对应备件这部分流程跑通后备件管理的效率还能提升一大截。第三设备预测性维护是个大方向。目前的异常检测是基于实时数据的反应式判断也就是“发生异常了才知道”。后续可以基于时序数据做趋势预测比如振动值连续一周上升虽然还没超过阈值但预测未来 3 天可能发生故障提前安排计划性检修。这样能把“被动维修”变成“主动维护”大幅降低非计划停机时间。第四边缘计算能力还没用起来。现在所有设备数据都往云端传如果直接在边缘网关侧做初步的异常预判比如简单的阈值和趋势判断只在异常时才向云端上报可以大幅降低网络带宽和云端计算压力。这也是后续可以考虑的方向。6.3 给后来者的几点建议如果看文章的你正准备做类似的物联网ERP 集成项目我个人的经验建议是先理业务流程再定技术架构。物联网平台本身好做难的是理解企业实际的维修流程。一定要花时间去设备现场看一遍和维修师傅聊一聊设备多久保养一次故障报修是走什么流程谁负责审批谁负责接单只有把这些业务流程吃透了才能在 Odoo 里做出真正符合实际的操作界面和工作流。数据结构设计要留出扩展余地。设备类型会变、传感器会加、业务字段会调整数据库设计时不要过度规范化导致后面扩展困难。我在设备遥测数据表里用 JSON 字段存储附加指标虽然违背了“规范化”的理念但换来的是极强的灵活性。小步快跑先做最核心的闭环。第一个版本不用做得很完美能跑通“设备异常 - 自动生成维修单”这个核心闭环就够了。等用户用起来、反馈来了再逐步加功能、优化体验。我第一版只有阈值告警和工单自动创建两个功能上线用了两周后才有信心逐步增加动态基线、告警分级、状态同步这些进阶能力。技术选型和架构设计都是可以讨论和调整的但有一个原则不能变系统最终是给现场用户用的用户觉得好用、愿意用才是真正的成功指标。这套 Go Odoo 的平台从设备数据接入到 ERP 工单闭环技术本身没什么稀奇但确实解决了工厂真实的问题减少了设备故障的漏发现、漏登记缩短了维修响应时间。这种“把对的技术用在真正有价值的地方”的成就感大概就是我坚持做这块的原因吧。