多设备接入需求
- 多个设备接入 MQTT
- 多种设备型号的兼容。考虑到蓝牙网关/体征监测设备商可能停产，或升级。造成蓝牙协议变化。
MQTT Client ID 规范
- 终端类型
- 整机设备标识 DeviceID
- 座位标识 SeatIndex 例如：1/2/3 ...。以密封舱内多设备为例。
例如：
- 蓝牙网关：gateway_<DeviceID>_<SeatIndex>
- Pad: pad_<DeviceID>_<SeatIndex>
主要是为了防止 client id 冲突。
TOPIC 规范
mqtt 订阅回调函数中可以获取到消息的来源主题，然后从主题中解码出设备信息。
补充两个变量：
- 蓝牙网关型号标识 GatewayModel
- 体征检测仪型号标识 MonitorModel
主题：
- 蓝牙网关数据上报 topic: healthdata/monitor/<DeviceID>_<SeatIndex>/<GatewayModel>_<MonitorModel>
- 平板监听 topic: healthdata/pad/<DeviceID>_<SeatIndex>
服务端订阅多个主题
使用多层通配符。例如，healthdata/monitor/#。
client 账号密码问题
为了偷懒，我打算 pub / sub 用两套账号密码，就不逐个设备不同的账号密码了。
sub 的平板 pad 上，账号密码被获取到的概率较大，所以独立一套。但是数据又没有敏感性，所以还好。
座位 id 问题的修正：背景
之前忽略了一个问题，一个舱内只会有一个蓝牙网关，而不是多个。 所以没法用蓝牙网关的 client id 来标注体征监测设备的型号及座位 id。
蓝牙网关
client id
- device id
- 蓝牙网关型号
是否要在后台建个网关的表。通过心跳记录蓝牙网关是否在线，方便诊断。(pad 端给出提示)
蓝牙网关与体征监测设备建立连接时
首先，建立连接的请求量很小，这个请求频率可控。
获取蓝牙设备 mac 地址，去 go 缓存查询是否有对应的 device id & seat id.
- 有，不做处理。
- 没有时, 去数据表查。查到写入缓存。
- 如果数据表也查询不到。写入一条记录到数据表，mac & device id
体征监测设备数据表
- id
- mac: 已与厂家确认 mac 设备的地址唯一，6 个字节
- device_id
- seat_id
- model 型号: 只能后台手动录入
- notes 备注
mac 加索引；device_id & seat_id 组合唯一索引
收到上报数据时
首先查询 go 缓存中是否有对应的 mac 地址：
- 没有丢弃数据
- 有，将数据 publish 到 device id & seat_id 拼接出来的 mqtt topic 中。部分选择性写入
TODO
- [X] 修正蓝牙网关的 client id。由 gateway_DeviceID_SeatIndex 变更为 gateway_DeviceID，实际上只是为了保证 mqtt client id 的唯一性，并没有解析价值
- [X] 修正上报 topic，由 healthdata/monitor/DeviceID_SeatIndex/GatewayModel_MonitorModel 变更为 healthdata/monitor/DeviceID/GatewayModel
- [X] 修正 topic 解析逻辑
- [X] 建表：体征监护仪
- [X] 解析设备通信状态变化（主动上报）, 04 已连接上。先确定能收到，再考虑数据库操作的问题。
- [X] 体征监测设备后台管理 go api & antd
- [X] cache 逻辑: 查询全局 cache 是否有该 mac 对应的记录：有，则 pass；无，则去数据库表查询 / 写入
- [X] publish topic
- 线上建表