摘要

随着物联网设备数量的快速增长，设备之间“能连上”已经不是问题，如何低成本、低复杂度、稳定地接入和管理设备，才是开发中的核心难点。
在传统模式下，IoT 设备往往只是一个“外设”，需要开发者自己处理协议、连接、状态同步、安全等大量细节。

鸿蒙系统在设计之初就把“多设备协同”作为核心能力，通过网络通信、分布式软总线以及分布式能力，把 IoT 设备从“外设”提升为“系统节点”。
本文将从实际项目视角出发，结合可运行 Demo 代码，系统讲清楚鸿蒙是如何支持物联网设备接入的，以及在真实场景中该如何选型和落地。

引言

在当前的 IoT 应用中，你可能已经遇到过这些情况：

• 写了一堆 Socket 代码，只是为了控制一个简单设备
• 不同设备协议不统一，后期维护成本很高
• 设备和 App 强耦合，换设备就要改一堆逻辑
• 同一局域网下，设备发现、连接、状态同步全靠自己维护

鸿蒙提供的思路并不是“再造一个协议”，而是从系统层面帮你把设备管理这件事做掉一大半。
你只需要关心两件事：

1. 设备能提供什么能力
2. 我什么时候调用这些能力

接下来我们就一步一步来看，鸿蒙是如何做到这一点的。

鸿蒙支持物联网设备接入的整体思路

从工程角度看，鸿蒙的 IoT 接入可以拆成五层能力：

设备发现与连接
Wi-Fi、蓝牙、BLE、分布式软总线

设备身份与安全
设备 ID、认证、加密通信

设备能力抽象
把具体硬件行为抽象成“能力接口”

数据通信与控制
消息、属性、事件上报

分布式能力调用
像调用本地模块一样控制远端设备

一句话理解就是：
鸿蒙希望你把 IoT 设备当成系统里的一个远程模块，而不是一个“麻烦的外设”。

最通用的 IoT 接入方式：基于网络通信

适用场景说明

这种方式在真实项目中非常常见，适合：

• 智能灯、插座、传感器
• 局域网设备控制
• 网关类设备
• 远程升级（OTA）场景

架构非常直观：

IoT 设备  <—— TCP / MQTT ——>  鸿蒙 App

你只需要保证双方协议一致即可。

Demo：鸿蒙端通过 TCP 连接 IoT 设备

这是一个最小可运行示例，用于演示鸿蒙设备如何直接控制一个 IoT 设备。

import socket from '@ohos.net.socket';

const tcpSocket = socket.constructTCPSocket();

// 连接设备
tcpSocket.connect({
  address: '192.168.1.100',
  port: 8888
}, () => {
  console.log('已连接到 IoT 设备');
});

// 发送控制指令（示例：开灯）
const command = new Uint8Array([0x01, 0x01]);
tcpSocket.send({ data: command });

// 接收设备返回的数据
tcpSocket.on('message', (msg) => {
  console.log('设备上报数据:', msg.message);
});

代码说明

• constructTCPSocket()
  创建一个 TCP 客户端

• connect()
  直接连接 IoT 设备 IP 和端口

• send()
  发送控制指令，协议完全由你定义

• on('message')
  接收设备主动上报的数据

这种方式的优缺点

优点：

• 实现简单
• 灵活度高
• 不依赖系统生态

缺点：

• 协议需要自己维护
• 安全和设备管理成本高
• 设备多了之后会比较累

鸿蒙的核心优势：分布式软总线接入设备

为什么说这是鸿蒙的“杀手锏”

在传统系统里，设备发现、连接、认证基本都要自己做。
而在鸿蒙里，这些能力是系统级别提供的。

你不需要关心：

• IP 地址
• 端口
• 网络类型
• 设备是否在同一子网

系统会帮你统一处理。

Demo：发现并感知 IoT 设备上线

import deviceManager from '@ohos.distributedDeviceManager';

const dm = deviceManager.createDeviceManager('com.example.iot');

dm.on('deviceStateChange', (data) => {
  if (data.action === deviceManager.DeviceStateChangeAction.ONLINE) {
    console.log('发现新设备:', data.device.deviceName);
  }
});

代码说明

• createDeviceManager()
  创建分布式设备管理器

• deviceStateChange
  监听设备上下线状态

• ONLINE
  设备上线即被系统感知

这一步完成之后，你已经可以完全不依赖网络细节来管理设备。

把 IoT 设备“像本地模块一样用”

分布式能力的核心思想

IoT 设备不再只是一个地址，而是一个提供能力的节点。

比如，一个智能插座可以提供：

• 打开
• 关闭
• 查询状态

Demo：远程调用 IoT 设备能力

设备端暴露能力

export function turnOn() {
  // 控制继电器上电
}

export function turnOff() {
  // 控制继电器断电
}

鸿蒙端调用能力

import rpc from '@ohos.rpc';

rpc.callRemoteAbility({
  deviceId: remoteDeviceId,
  bundleName: 'com.example.device',
  abilityName: 'ControlAbility'
});

实际效果

• 没有 Socket
• 没有协议解析
• 调用方式和本地服务几乎一致

这在复杂项目中能极大降低维护成本。

典型应用场景分析与示例

场景一：智能灯控制

场景说明

用户在鸿蒙平板或手机上控制家里的灯。

实现方式

• 同一局域网
• 分布式软总线发现设备
• 分布式能力调用开关

示例代码（控制）

function openLight(deviceId: string) {
  rpc.callRemoteAbility({
    deviceId,
    bundleName: 'com.example.light',
    abilityName: 'LightControlAbility'
  });
}

场景二：环境传感器数据采集

场景说明

温湿度、空气质量传感器周期性上报数据。

实现方式

• TCP / MQTT 上传数据
• 鸿蒙端统一解析展示

tcpSocket.on('message', (msg) => {
  const data = JSON.parse(msg.message);
  console.log('温度:', data.temp);
  console.log('湿度:', data.humidity);
});

场景三：设备远程升级（OTA）

场景说明

批量设备需要升级固件。

实现方式

• 鸿蒙端下发升级指令
• 设备拉取固件并校验
• 重启生效

function startUpgrade(deviceId: string) {
  const cmd = new Uint8Array([0x02, 0x01]);
  tcpSocket.send({ data: cmd });
}

这个场景和你之前做的远程升级项目是高度一致的。

QA 环节（常见问题）

Q：一定要用分布式吗？
不一定，小规模或跨公网设备，用 TCP / MQTT 更合适。

Q：分布式适合哪些设备？
同一生态、同一网络、需要强系统协同的设备。

Q：能不能混合使用？
完全可以，实际项目里经常混合。

总结

从工程角度来看，鸿蒙对 IoT 的支持并不是“多了几个 API”，而是从系统架构层面降低了设备接入的复杂度。

你可以这样概括：

• 网络通信解决“能不能连”
• 分布式软总线解决“好不好连”
• 分布式能力解决“用起来像不像本地”

当你真正做过设备控制、状态同步、远程升级这些场景后，会发现这种设计在长期维护中非常省心。