Top

iOS 下发设备控制 DP 设备没有执行排查技巧

App开发相关产品技术讨论，包括OEM App、App SDK等话题


Post Reply
aotuo
Posts: 2

问题背景
在给设备下发 DP 控制时，出现设备没有执行，如何进行排查确认问题

排查思路

排查一：检查设备是否在线

首先，想要设备能控制的前提，是设备处于在线的状态。

我们可以通过 ThingSmartDeviceModel 对象 的 isOnline 方法 获取设备的总体在线状态。

进一步，可以通过 ThingSmartDeviceModel 对象 的 communication 属性 遍历 "communicationModes" 检查设备会走什么通道进行控制。相关类型定义如下：

Code: Select all


/// 设备通讯协议类型定义
typedef NS_ENUM(NSUInteger, ThingCommunicationType) {
    ThingCommunicationTypeLAN      = 0, // LAN
    ThingCommunicationTypeMQTT     = 1, // MQTT
    ThingCommunicationTypeHTTP     = 2, // Http
    ThingCommunicationTypeBLE      = 3, // Single Point Bluetooth
    ThingCommunicationTypeSIGMesh  = 4, // Sig Mesh
    ThingCommunicationTypeBLEMesh  = 5, // Thing Private Mesh
    ThingCommunicationTypeBLEBeacon  = 6, // Beacon
    ThingCommunicationTypeMatter    = 8,  // Matter
    ThingCommunicationTypeYuNetMqtt = 12,  // YuNet MQTT
    ThingCommunicationTypeCloudMode = 100, // Cloud Mode
};

/// 通讯顺序定义
@interface ThingSmartCommunicationMode : NSObject

/// 通讯协议版本
@property (nonatomic, assign) double pv;

/// 设备通讯协议类型（见枚举 ThingCommunicationType定义）
@property (nonatomic, assign) ThingCommunicationType type;


@end

/// 设备通讯属性类
@interface ThingSmartCommunication : NSObject

/// 通讯顺序定义数组，下发时默认遵循这个顺序，看哪个通道是在线的来选择控制通道
@property (nonatomic, strong) NSArray<ThingSmartCommunicationMode *> *communicationModes;

///...
@end

常见设备来说：
1、WiFi 单模设备的 communicationModes 数组对象的 type 是 [0, 1] 即：局域网 -> MQTT
2、WiFi+BLE 双模设备是 [0, 1, 3] 即：局域网 -> MQTT -> BLE。（也有特殊的设备蓝牙是第一优先级）
3、BLE 单点设备是 [3] 即：BLE。但其挂在网关下时，可通过网关连云控制，则会变成 局域网 -> MQTT -> BLE。

那么我们可以进一步检查这个设备对应通讯方式的通道至少有一个是在线的才可以正常控制。

排查二：检查 DP 是否合法

通过 ThingSmartDeviceModel 的 schemaArray 可以获取到所有的 DP点 定义（即在 IoT 平台设备产品里定义的功能点）。

1、检查下发的 DP 的 dpId（即 key）需要在 schemaArray -- dpId 是存在的。

特别注意：若是正在开发中的设备，在平台新增的 DP 功能点，需要等待云端缓存刷新，通常中国区是15分钟，国外区要 1h 左右。在等待缓存更新之后，建议重新给设备配网。

2、检查下发 DP 的类型是否符合 schema 定义。

2.1 schema 对象的 mode 不能是 ro（即：定义为仅上报）
2.2 bool 类型，需下发 @(YES) 或者 @(NO)，不能是 @(1) / @(0)
2.2 string 类型，检查长度是否小于等于 maxlen 定义
2.3 enum 类型，检查下发值是否在定义的 range 范围内
2.4 value 类型，检查下发值是否在定义的 min, max 范围内
2.5 raw 类型，检查下发内容是否是 HexString，长度是偶数，字符串内容仅限 09 和 AF。例如："01020304"
2.6 bitmap 类型，检查下发值是否小于等于 maxlen 定义

通常下发存在不合法的时候，会直接在 App SDK 内拦截，不发送给设备。

可以检查控制台打印：

Code: Select all

// 打印此日志代表有不合法的 dps，其中 validDps 代表的是合法的dp，未打印出的dp则是不合法的
dps invalid format devId:xxxxx validDps:{"x": y}

排查三：特殊情况排查
对于一次性下发 >= 2条 dp 的组合 dps，有些设备固件对组合 DP 处理逻辑不佳。

常见有：开灯并调整亮度 { "1": true, "2": 1000} 或者多路开关全开 {"1": true, "2": true, "3": true}。

设备固件强制识别 DP 顺序，即：必须 dps 内容是 1、2、3 这么一个顺序，若 App 发送的是 {"2": true, "1": true, "3": true} 就不执行。

此时会出现 安卓可以正常控制设备，iOS 下发控制到了设备，但设备不执行。

本质原因是：dps 是一个 HashMap，本质上应当是无序的，在转换成 Json String 时 安卓系统层会强制排序，而 iOS 依然是无序的，这是系统差异导致，App侧无法兼容。

建议的解决方案：
方式1：设备侧优化，不要写死顺序进行执行
方式2：下发时，将 dp 拆开成多条发送

Tags:
精华帖
Post Reply