智能家居核心

智能家居模组

前言：如何实现家居的智能化？都需要模组吗？

我们先给出答案，让一个普通灯泡智能化的最简单方式是**”智能开关/智能插座”模式。这是一种极致的智能家居，根本不需要设备本身有多智能**。（详情查看下文的执行器）。

以上的灯泡其实还只是普通灯泡，只是通过智能插座，让其看起来是智能的，类似的例子还有普通电视、普通饮水机、普通电饭煲等。

那如果要让硬件本身实现智能化，就需要涉及到嵌入式软件开发。在这个过程中，一般使用模组最简单，但并不是一定需要使用模组。

两种智能家居🏠的实现路径

路径一：**”后装”智能（需要模组）**

这是目前绝大多数智能设备的实现方式，即”模组路线”。

• 原理：传统设备（灯泡、插座、空调）本身是”哑巴”，通过嵌入一个智能模组，让它学会”说话”和”听话”。

• 典型例子：

  • 普通灯泡 + 涂鸦模组 = 智能灯泡
  • 传统空调 + 智能空调伴侣 = 可以用手机控制的空调

• 优点：灵活，旧设备也能变智能；成本低，几十块钱就能改造一个设备

• 适用场景：你希望把家里已有的普通电器变智能，或者开发新产品时想快速上市

路径二：**”前装”智能（无需额外模组）**

设备从设计之初，就把”智能”作为原生功能集成在主控芯片里，而不是通过外挂一个独立的模组来实现。

• 原理：设备的主芯片本身就具备联网和智能处理能力，不需要再单独买一个”翻译官”插上去。
• 典型例子：
  • 小米/华为等品牌的旗舰大家电：比如一台小米空调，它的主板上直接集成了Wi-Fi/蓝牙芯片，不需要再外挂一个模组。
  • 苹果HomePod、Google Nest Hub：这些本身就是智能中枢，自带完整的计算和连接能力。
• 优点：集成度更高、成本更低（少了一个独立模组的物料成本）、更稳定（减少了一个连接点）
• 适用场景：大规模生产的成熟产品，从零开始设计的智能设备

你可能会问：这不就是模组焊死在主板上的区别吗？

不完全对。 关键区别在于：

维度	模组方案	原生集成方案
硬件架构	独立的模组（带屏蔽罩、晶振、天线）通过焊接或插拔连接	联网芯片直接集成在主板上，共用电源、时钟等资源
开发难度	低，模组厂商已经做好了最难的射频部分	高，需要自己有射频设计能力
灵活性	高，可以随时更换模组供应商	低，一旦设计定型就很难改动
认证周期	短，模组已有FCC/CE等认证	长，整机需要重新过认证

• 模组方案 = 你们现在做的定时插座，是给普通插座加一个定时模块
• 原生集成 = 从电路设计之初，就把定时功能和主控功能做在同一块芯片上，不需要单独的定时模

一、智能家居的基础概念

假设你想实现”人来灯亮，人走灯灭”的智能场景：

1、三大核心基础角色/智能设备

智能设备的核心定义是：能通过无线通信接收或发送指令的设备。

传感器、控制器、执行器，这三个都算智能设备（都必须有模组）。

首先要先了解智能家居的三个基本角色：

角色	例如	核心职责
传感器	人体传感器、门磁	感知环境的（看到人、检测温度）
控制器/中枢	智能音箱、网关、APP	发指令的（判断”有人→开灯”）
执行器	智能插座、智能开关、智能灯泡	干活的（发光、转动、通电/断电）
被执行的工具	普通灯泡、普通风扇	被动干活，听不懂指令

一个完整的智能场景，这三个角色缺一不可。但关键是：它们可以在同一个设备里，也可以分开在不同设备里。

2、智能家居的四种实现

方式	架构	核心特点	典型代表	跨品牌
方式一	设备全包	一个设备搞定一切	智能灯泡	不能
方式二	传感器→执行器	点对点直连，不需要独立控制器	传感器+智能插座直连	不能
方式三	传感器→控制器→执行器	本地中枢做复杂决策	Home Assistant	有限
方式四	传感器→云→执行器	云端大脑，无限可能	米家、涂鸦、HomeKit	可以

二、执行器

1、智能开关和智能插座区别

智能开关和智能插座虽然都是”执行器”，但它们的安装方式、控制对象、适用场景完全不同。我用最直接的方式给你拆解。

1.1、核心区别：一个控制”线路”，一个控制”插座”

维度	智能开关	智能插座
控制对象	控制墙里的电线线路	控制插在它上面的设备
安装方式	替换原有的墙壁开关，需要接线	直接插在原有插座上，无需接线
适用场景	控制天花板上的灯、吊扇、筒灯	控制台灯、风扇、加湿器、电视
是否需要电工	通常需要（涉及墙内电线）	完全不需要（即插即用）
外观	像普通开关，固定在墙上	像转换器或小盒子，插在墙上

关键：智能插座是新增的设备，不取代任何东西。台灯本身不需要任何改造，还是那个普通台灯。

对比项	智能开关	智能插座
控制对象	墙里电线（顶灯、吊扇）	插在上面的设备（台灯、风扇）
安装	拆墙上的开关，接线	直接插墙上
用户	房主、装修人群	所有人，包括租房族
你们能不能做	能做，但需要强电研发能力	特别适合，和现有产品线最匹配

2、场景举例

2.1、普通灯泡+接智能插座执行器：控制”插着的设备”

场景：你床头有个台灯，插在墙上的插座上。

• 传统方式：你走过去，按台灯上的开关，灯亮
• 智能化方式：把智能插座插在墙上，然后把台灯插在智能插座上
• 结果：
  • 你仍然可以按台灯自己的开关（台灯本身功能还在）
  • 你也可以用手机控制智能插座，从而控制台灯通断电
  • 你可以设置自动化：”早上7点台灯亮当闹钟”

“本来灯泡插在普通插座上，现在需要把智能插座插在普通插座上，再把灯泡插在智能插座上。”

[墙壁上的普通插座] ←插→ [智能插座] ←插→ [普通灯泡/台灯]

[墙壁上的普通插座] ←插→ [智能插座] ←插→ [普通设备（台灯/风扇）的插头]

让我用一个真实家庭布局来画给你看：

[门口]             [客厅]                    [天花板]
传感器（有模组）    中枢（有模组）             普通灯泡
    ↓                  ↓                          ↑
    └──→ 检测到人 ──→ 判断该开灯 ──→ 发指令 ──→ 智能插座（有模组）
                                                    ↑
                                                [墙壁]普通插座

工作流程：

1. 传感器看到人 → 2. 告诉控制器 → 3. 控制器判断该开灯了 → 4. 控制器给插座发指令 → 5. 插座通电 → 6. 灯泡亮

关键点：

• 传感器：装在门口，专门负责”看有没有人”
• 控制器/中枢：装在客厅某个地方，专门负责”做决策”
• 智能插座：插在墙上的普通插座上，专门负责”执行”
• 普通灯泡：插在智能插座上，只负责”发光”

中枢和智能插座是两个分开的硬件，它们之间通过无线通信（Wi-Fi/Zigbee/蓝牙）交流。

这时候，灯泡还是那个灯泡，它不知道自己”被智能了”。

2.2、普通灯泡+接智能插座执行器：控制”顶上的灯”

场景：你家客厅天花板上有一盏主灯，开关在墙上。

• 传统方式：你走过去，按墙上的开关，灯亮
• 智能化方式：把墙上的普通开关拆下来，换上智能开关
• 结果：
  • 你仍然可以走过去按开关（物理按键还在）
  • 你也可以用手机控制
  • 你可以设置自动化：”晚上7点自动开灯”

关键：智能开关取代了原来的普通开关，直接控制墙里的电线。天花板上的灯不需要任何改造，还是那个普通灯泡。

智能插座是：
[墙壁上的普通插座] ←插→ [智能插座] ←插→ [普通灯泡/台灯]
[墙壁上的普通插座] ←插→ [智能插座] ←插→ [普通设备（台灯/风扇）的插头]

智能开关是：
[墙里的电线（火线/零线）] ←接→ [智能开关（取代原开关）] ←接→ [天花板上的普通灯泡]

让我用一个真实家庭布局来画给你看：

智能插座是：
[门口]             [客厅]                    [天花板]
传感器（有模组）    中枢（有模组）             普通灯泡
    ↓                  ↓                          ↑
    └──→ 检测到人 ──→ 判断该开灯 ──→ 发指令 ──→ 智能插座（有模组）
                                                    ↑
                                                [墙壁]普通插座
                                                
智能开关是：                                                
[门口]             [客厅]                    [天花板]
传感器             中枢（有模组）              普通灯泡（吸顶灯/筒灯）
    ↓                  ↓                          ↑
    └──→ 检测到人 ──→ 判断开灯 ──→ 发指令 ──→ 智能开关（有模组）
                                                    ↑
                                                [墙壁]（墙里面）
                                                    火线/零线直接来自配电箱

关键点：

• 传感器：装在门口，专门负责”看有没有人”
• 控制器/中枢：装在客厅某个地方，专门负责”做决策”
• 智能开关：替换原来的墙壁开关，专门负责”执行”
• 普通灯泡：插在原来的位置，只负责”发光”

小结：要实现智能家居，不需要每个设备都成为”智能硬件”，但整个家居系统一定需要”智能组件”（传感器、控制器、中枢）。

智能灯泡（灯泡自己全包了）

• 灯泡里有什么：发光芯片（执行器）+ 人体传感器 + 控制芯片（控制器）
• 怎么工作：灯泡自己感知有人→灯泡自己决定开灯→灯泡自己发光
• 优点：简单，买一个灯泡就行
• 缺点：贵（一个灯泡带这么多功能），而且传感器在灯泡上位置不一定好

**这就是你想象中的”一个灯泡硬件就够了”**——确实可以，只要你愿意为每个灯泡多花钱。

三、执行器怎么接收命令？配网 / 连 Wi-Fi 方式

执行器要执行指定操作 ← 就必须接收我们的命令 ← 也就要求要先有通信连接，才能接收命令。

那这个连接在哪？何时建立的？

这个连接是在”设备配网”时建立的，一旦建立就会一直保持（除非断网或重启），云端随时可以通过这个现成的连接发指令。

1、插座连 Wi-Fi 的过程（插座配网）

第一步：插座通电
[智能插座] ── 启动，进入配网模式

第二步：手机App告诉插座家里的Wi-Fi密码
[手机App] ── 通过蓝牙或声波 ──→ [智能插座]  "你家Wi-Fi是XXX，密码是YYY"

第三步：插座连接路由器：插座用app告知的密码，连上你家的Wi-Fi
[智能插座] ── 用得到的密码 ──→ [你家路由器]

2、插座连 Wi-Fi 的常见方式

问：设备是怎么获取到要连接的WiFi名称和密码的？

答：一般是app通过某些方式告知设备的。方式如下：

配网方式	你看到的现象	优点	缺点
AP模式	突然多个WiFi，让你去连	直观、兼容性好、成功率最高	需要你手动切WiFi，步骤略多
SmartConfig	App里点一下，不用切WiFi	体验流畅，一步完成	成功率受环境影响，部分老手机不支持
蓝牙配网	App里自动发现设备	体验最好，交互丰富	设备需带蓝牙芯片，成本高

更多更全的设备配网

为什么很多产品还是用AP模式？
因为成功率高、兼容性好。你手机能连上这个临时WiFi，说明信号没问题；你亲自填密码，不会因为编码问题传错。虽然多了一步切换WiFi的动作，但这是最可靠的方案。

2.1、AP模式(热点模式)

即”突然多出来的WiFi”的配网方式（设备自己开热点，手机连上去填信息）：

• 它开了一个小范围的WiFi，专门等你来
• 你把家里的WiFi密码告诉它
• 它记下后，关掉自己的WiFi，去连你家网络
• 从此以后，它就一直在你家网络里，听候指令

2.2、Wi-Fi 快连模式

Wi-Fi 快连配网又称 快连模式（Easy-Connect）、SmartConfig 或 EZ 配网。

3、插座接收命令（插座接云）

命令我们一般从云端接收，使得即使app关闭后也能够从云端发送命令给插座。

前面我们已经让插座连接上了 Wi-Fi 了，那下面就是在插座有网络的基础上，让插座连接上云服务器。

具体连接建立过程如下：

第四步：插座连接云端服务器：插座主动去互联网上找云服务器，建立连接
[智能插座] ── 通过路由器 ──→ [云端服务器]  "你好，我是设备ID:12345，请求建立永久连接"

第五步：云端确认身份
[云端服务器] 查数据库：这个设备是合法的 → 接受连接

第六步：连接建立成功，保持开放
[智能插座] ←── 长连接（如MQTT）──→ [云端服务器]  （一直在线）

这个连接一旦建立，就会一直保持，像一根看不见的网线，把插座和云端永远连在一起。

工作流程：

1. 出厂烧写：固件中只烧写一个固定的引导服务地址（全球统一）
2. 首次连接：设备上电后先连接引导服务器，进行身份认证
3. 获取配置：引导服务器根据设备所属区域、产品类型，动态返回业务服务器地址
4. 切换连接：设备断开引导服务器，连接业务服务器开始正常工作

3.1、第四步的详细拆解：插座是怎么“找到”云端的？

第四步“插座连接云端服务器”的本质：

1. 主动发起：插座连上你家Wi-Fi后，主动去连接出厂时预设的云端地址

   在插座出厂时，它的固件（芯片里的程序）里已经写死了云端服务器的地址 。

   这个地址有两种形式：

   • 域名：比如 api.tuya.com 或 a3orti3lw2padm-ats.iot.us-east-1.amazonaws.com
   • IP地址：但通常用域名，方便云端换服务器时不用改插座固件

   关键：这个地址是出厂前就烧在芯片里的，就像你的手机里预装了浏览器，知道怎么上百度。

2. 身份验证：通过TLS/SSL加密通道，双方互相验明正身

3. 上报身份：插座告诉云端“我是谁”，云端确认合法

4. 建立长连接：双方保持一条永久在线的通道，随时收发指令

这个连接一旦建立，只要插座不断电、不断网，就永远在线。你关掉App、出门上班，这条连接都在——云端随时可以通过它给你家插座发指令。

3.2、将云端地址烧写在固件里，万一地址变了，怎么避免设备变砖？

问：固件中只烧写一个固定的引导服务地址。那岂不是得保证这个地址永远可用，不然后续都没法升级了，之前的硬件也会因为该地址无效，而变砖？

答：容错与生存机制

方式一：可以在给插座配 Wi-Fi 的时候，通过app将云服务器地址从app中更新到固件里。

方式二：本地备胎地址：固件中除了引导地址，通常还会硬编码一个或多个备用的、最基本的升级服务器地址。当连接主引导地址失败无数次后，设备可以尝试连接这个备用地址，至少保证能下载一个紧急修复固件。

方式三：近场强制升级（物理接触）：这是最后的防线。对于网关这类核心设备，厂商会提供本地升级工具。你可以通过USB线连接电脑，或者把固件文件放入SD卡/TF卡，按住设备上的某个物理按键（重置键或专用升级键）再通电，设备就会强制从这些本地介质中读取固件进行恢复。这完全绕过了网络。

四、控制器：本地控制器和云服务控制

1、场景举例

本地控制器：

[人体传感器] ──→ [智能音箱/网关 控制器] ──→ [智能插座 执行器] ──通电──→ [普通台灯]
     |                |                    								|
  装在门口  	本地做决策："有人来该开灯"   										插在墙上

云服务控制：(打出↕的方法在输入法中打”shangxia”)

								用户可以手动控制
											|						
									[手机APP]
											↕
[人体传感器] ──→ [涂鸦云/米家云	云服务] ──→ [智能插座 执行器] ──通电──→ [普通台灯]
     |             		|                    									|
  装在门口   	云端做决策："有人来该开灯"   										插在墙上

2、本地控制器

2.1、本地控制器的完整工作流程

第一步：配置阶段（需要手机/电脑）

[手机App/电脑] ──（本地网络）──→ [控制器]
       ↑                 
  你设置规则："晚上7点后有人来才开灯"

在这个阶段：

• 你用手机App连接控制器（通过Wi-Fi或蓝牙）
• 在App里”教”控制器各种规则：什么时候该做什么
• 这些规则被保存到控制器的本地存储芯片里

关键：这个配置过程只需要一次，之后手机就可以退出了。

第二步：运行阶段（手机可以离开）

[传感器] ──检测到人──→ [控制器] ──（查本地规则）──→ "现在7点，有人，该开灯" ──发指令──→ [智能插座]
                               ↑
                       规则存在本地，无需联网

在这个阶段：

• 控制器完全独立运行，不需要手机一直在线
• 传感器发来信号，控制器查自己”脑子”里的规则，做出判断
• 即使家里断网，只要控制器和传感器、执行器在同一个局域网，照样工作

本地控制器的管理是通过”配置过程”完成的——你在手机App上设置好规则，然后把规则”告诉”控制器，之后控制器就能脱离手机独立运行。

控制器的本质：它是一个本地运行的小型决策引擎，你把规则”喂”给它一次，它就能一直按规则干活，不需要时刻请示云端。

3、云端控制器

云端要发指令控制开灯，那不是要有通信连接，这个连接在哪？何时建立的？

4、代码层面的对比

我们以灯泡为例

底层硬件控制代码（最终执行者）

无论指令来自哪里，最终控制硬件的那几行代码是完全相同的：

// ============ 底层硬件控制代码（最终执行者）============
// 智能灯泡的硬件抽象层
void light_set_state(uint8_t on_off, uint8_t brightness) 
{
    // 1. 控制开关（继电器或MOSFET）
    if(on_off) {
        GPIO_SetBits(LIGHT_GPIO_PORT, LIGHT_PIN);  // 拉高引脚，开启灯泡
    } else {
        GPIO_ResetBits(LIGHT_GPIO_PORT, LIGHT_PIN); // 拉低引脚，关闭灯泡
    }
    
    // 2. 如果需要调光，设置PWM占空比
    if(brightness > 0 && brightness <= 100) {
        TIM_SetCompare1(TIM2, brightness);  // 设置PWM值控制亮度
    }
    
    // 3. 保存当前状态到Flash（用于断电恢复）
    save_light_state_to_flash(on_off, brightness);
}

4.1、全本地控制架构

特点：所有事情本地做，不依赖网络，但规则修改麻烦

// ============ 全本地控制架构 ============
// 设备：自己存规则、自己检查时间、自己执行
void device_main_loop(void)
{
    while(1) {
        // 1. 获取当前时间（本地RTC）
        uint32_t now = get_rtc_time();
        
        // 2. 遍历本地规则
        for(int i = 0; i < rule_count; i++) {
            if(rule_table[i].enabled && now == rule_table[i].trigger_time) {
                // 3. 时间到了，执行动作
                // 这里的action和云端payload结构一样！
                light_command_t cmd = rule_table[i].action;
                
                // 4. 调用最终执行函数
                light_set_state(cmd.command, cmd.brightness);
            }
        }
        
        delay(100);
    }
}

4.2、纯云端控制架构

特点：设备极简，但完全依赖网络

// ============ 纯云端控制架构 ============
// 设备：只执行，不思考
// 云端：存规则、检查时间、下发指令

// ===== 设备端代码（非常简单）=====
void device_main_loop(void)
{
    while(1) {
        // 唯一任务：等待云端指令
        if(mqtt_message_available()) {
	          // MQTT消息回调函数 - 处理云端下发的指令
						// payload内容示例: '{"command":"turn_on","brightness":80}'
            char* payload = read_mqtt_payload();
            
            // 解析JSON成命令结构
            light_command_t cmd = parse_json(payload);
            
            // 直接执行（不关心为什么执行）
            light_set_state(cmd.command, cmd.brightness);
        }
        
        // 什么都不用想，进入低功耗
        enter_sleep_mode();
    }
}

// ===== 云端代码（伪代码）=====
// 云端定时服务
function cloud_scheduler() {
    setInterval(() => {
        let now = get_current_time();  // 云端NTP时间
        
        // 遍历所有用户的规则
        database.rules.find({enabled: true}).forEach(rule => {
            if(now == rule.trigger_time) {
                // 构造命令（和本地规则一样的格式）
                let command = {
                    cmd: rule.action.command,
                    bri: rule.action.brightness
                };
                
                // 转为JSON下发
                let payload = JSON.stringify(command);
                // payload: '{"cmd":1,"bri":80,"time":5}'
                
                // 通过MQTT推送给设备
                mqtt_publish(rule.device_id, payload);
            }
        });
    }, 1000);  // 每秒检查一次
}

5. 控制器产品方向

	产品方向	控制逻辑在哪	用户关掉App后	断网后	优缺点
1	本地规则插座	插座芯片里	✅ 照常执行	断网也能用	但规则简单
2	纯云智能插座	云端服务器	✅ 照常执行	不能（必须联网）	但方便
3	蓝牙直连插座	手机内存	❌ 停止执行		必须手机一直开着

最好的产品：云端+本地双保险

• 正常情况：用云端（方便远程、复杂规则）
• 断网时：用本地芯片里存的简单规则（如定时）
• 用户关App：云端继续工作

关闭App后，规则还在云端服务器里运行。云端是7x24小时在线的”机器人管家”，替你守着时间，到点就发指令开灯关灯。你关掉App，只是关掉了”设置规则的工具”，但规则本身还在云端好好运行着。

从控制器思考产品发展方向

选项A：你们不做控制器，只做执行器（智能插座）

• 用户怎么用：用户家里已经有控制器（小米音箱、华为中枢、Home Assistant）
• 你们的任务：确保智能插座能被这些控制器发现和控制（支持通用协议）
• 好处：不用操心控制器的研发，专注做好插座

选项B：你们做自己的控制器+执行器全套

• 怎么玩：开发一个”智能中枢”，用户用”智能App”配置规则
• 需要什么：需要做App开发、规则引擎、本地存储
• 好处：自成生态，用户粘性强
• 挑战：研发投入大，用户家里如果有其他品牌设备，不一定能联动

选项C：做”配置友好型”执行器

• 怎么玩：智能插座本身带简单存储能力，可以通过App直接给插座设规则
• 例子：智能插座内置定时规则（”每天19:00开，23:00关”），不需要独立控制器
• 好处：最简单，用户买了插上、设好规则，就独立运行

五、模组

模组 = 硬件芯片 + 里面烧录的代码

模组 = 物理硬件（芯片/电路） + 固件代码（我们写的那些程序）

可以把模组精准地理解为：一个封装好的“硬件+固件”解决方案。

我们之前写的所有设备端代码（C语言那部分），最终都会被编译、烧录到模组的Flash芯片里。

问	答
模组是硬件吗？	✅ 是，它是一个物理组件
模组里有代码吗？	✅ 有，我们写的那些程序烧在里面
那些代码跑在哪？	✅ 跑在模组的芯片里
买模组和写代码的关系？	买模组 = 买预装好基础软件的电脑 写代码 = 装自己的业务软件

模组 = 硬件载体 + 软件灵魂。没有代码的模组只是一块废铁，没有模组的代码无处安放。

硬件部分（看得见摸得着的）：

• 核心芯片（SoC/MCU）：这是大脑，负责计算和控制。
• 通信芯片：负责Wi-Fi、蓝牙、Zigbee等无线信号的收发。
• PCB板：承载以上所有元件的电路板。
• 晶振、电容、天线：保证芯片正常工作的辅助元件。

固件部分（烧写在芯片里的灵魂）：

• 通信协议栈：比如Wi-Fi的TCP/IP协议、蓝牙的GATT协议。让模组“会说”这门无线语言。
• 驱动程序：控制模组上的引脚（GPIO）如何输出高低电平，从而控制外接的灯、电机等。
• 引导程序：启动代码，告诉芯片上电后第一步做什么。
• 基础应用框架：比如如何连接云端、如何处理接收到的数据包。这部分就是让模组“懂事”的基础。

1、模组是属于纯硬件开发吗？

既是，也不是。准确地说，它是一个以硬件为载体、核心价值在软件的解决方案。

把它理解为 “固件开发” 或 “嵌入式软件开发” 会更贴切。

• 硬件层面：你确实需要设计或选用一块包含芯片、麦克风接口、控制接口等的电路板。从这个角度看，它是硬件。
• 软件/算法层面：这块硬件之所以能“听懂”人话，是因为芯片里烧录了复杂的语音识别算法。这个算法是软件。同时，你需要通过配套的工具，把自定义的唤醒词和指令词（如“你好，小智”、“打开风扇”）也烧录进去。这个配置过程，就是软件开发。

所以，开发模组，不仅仅是画电路板，更重要的是选对芯片方案，并用好配套的软件工具，把识别模型和指令词部署到硬件上。

2、智能家居_语音模组

六、固件

1、“固件”是什么，在哪里？

在我们之前讨论的“本地控制器 vs 云控制器”里，你提到的“烧写进芯片”的东西，其实就是固件。

固件，就是存储在硬件设备内部芯片里的一段“永久”软件。你可以把它理解为硬件设备的“操作系统”+“出厂自带的核心程序”。

灯泡里那颗芯片上烧写的程序，就是固件。它决定了灯泡怎么联网、怎么响应指令、怎么调光。

2、固件升级是什么？

固件升级（Firmware Update/OTA），就是给硬件设备“更新大脑”——把芯片里旧的固件程序，替换成一个新版本。

固件升级就是给这个灵魂“打补丁、加技能”，让已经卖出去的设备也能变强、变稳、变安全。

而云端服务器上的软件更新，不属于“设备固件升级”的范畴，那是服务端的迭代。

2.1、为什么需要固件升级？

原因	具体场景
修复 Bug	灯泡偶尔断连、传感器误报，通过固件修复
增加新功能	原本不支持调光的插座，升级后支持了
提升性能	优化配网速度、降低功耗
安全补丁	修复可能被黑客利用的漏洞
兼容性	适配新的路由器、新的手机系统

固件升级的两种方式

方式	说明	适用场景
有线升级	用 USB 线、编程器连接设备，通过电脑烧录	工厂生产、开发调试、设备变砖后的“救砖”
OTA 升级（Over-The-Air）	通过网络（Wi-Fi/蓝牙/Zigbee）远程推送固件	用户日常使用中最常见的方式

2.2.1、固件 OTA 升级的典型流程

OTA，全称是 Over-The-Air，也就是空中升级。整个过程不需要你插线连接电脑，完全通过网络完成。

一个典型的OTA流程如下：

1. 通知：厂商在平台上传新固件文件（如 light_v2.0.bin），平台推送升级通知到 App。你的手机App上出现提示：“发现新固件，体积XX，是否升级？”
2. 下载：用户点击确认后，设备（或网关）会通过 Wi-Fi 从厂商的云端服务器下载新的固件文件。
3. 校验：下载完成后，设备会检查这个文件是不是完整、是不是官方签发的，防止被篡改。
4. 写入：设备将新固件写入到芯片的指定存储区域，然后自动重启。
5. 生效：重启后，设备就开始运行新版本的固件了，升级完成。

整个过程用户无感，设备不会变砖——因为设计上会保留一个“最小系统”，即使升级失败也能回滚或重新进入配网模式。

3、固件中烧写的地址固定了？

固件中烧写的地址固定了？

七、模组

问：固件是烧录到模组上的，那模组是怎么安装/集成到设备上的？

模组安装到设备上，通常是通过焊接或插接的方式，把它固定在你的产品主板上，然后通过电路板上的走线，连接到电源、MCU（如果有）以及被控制的硬件（如LED、电机、继电器）。

所以，是设备安装模组，模组里烧录着固件。

1、使用模组实现家居智能化的三种方式和流程

假设我们有三块完全相同的硬件（一个灯泡主板），这块主板上，已经焊好了模组的插座、LED驱动电路、电源，唯独缺一个“大脑”。请问如何实现智能化？

1.1、SoC（System on a Chip，片上系统）

SoC（System on a Chip，片上系统）开发是将微处理器（CPU）、内存、外设接口、GPU等多个功能模块集成在单一芯片上的技术。

1. 你下载涂鸦的 SoC SDK
2. 你自己写代码：if(收到开灯指令) GPIO_Write(LED_PIN, HIGH);
3. 编译生成固件，烧录进空白模组
4. 模组焊到主板上，模组里的 MCU 直接控制 LED
5. 业务逻辑（你写的开关、调光）跑在模组里的 MCU 中

1.2、零代码

1. 你在涂鸦平台网页上配置：“我的产品是灯泡，有开关、调光、调色三个功能，控制引脚是 GPIO 8、9、10”
2. 平台根据你的定义，自动生成一个“专属固件”，你下载。这个固件里，已经把“当收到开灯指令时，把 GPIO 8 拉高”这种if逻辑都写好了。
3. 你把平台生成的这个固件，烧录进一个空白模组（比如 BK7231N）
4. 你把烧好固件的模组插到/焊到主板上，模组里的 MCU 直接控制 LED
5. 业务逻辑（开关、调光）跑在模组里的 MCU 中

1.3、模组 MCU SDK

1. 你买了一个“预烧标准固件”的模组。这个固件的作用是：让模组具备联网、配网、连接云端的能力。但它不知道你的产品是灯泡，还是插座，也不知道怎么控制你板子上的 LED。
2. 你把模组插到主板上。
3. 现在问题来了：模组虽然能上网了，但谁来告诉它“当收到云端‘开灯’指令时，应该把板子上的哪个引脚拉高”？谁来告诉它“当用户按下按键时，该上报什么状态”？
   答案：你的外部 MCU（比如 STM32）。你在外部 MCU（比如 STM32）上写代码：if(收到串口指令“开灯”) GPIO_Write(LED_PIN, HIGH);，这个 MCU 通过串口和模组对话，是它让整个系统“活”起来。
4. 云端发来“开灯”指令 → 模组收到 → 通过串口告诉 STM32 → STM32 控制 LED
5. 业务逻辑跑在外部 STM32 里

这种方式下，模组是“会说话但没大脑”的翻译官，你的 MCU 才是真正的大脑。

1.4、模组的三种方式的区别

三种方式，最终都是执行 “如果收到开灯指令，就把引脚拉高” 这样的 if 逻辑，只是这个 if 逻辑跑的位置和生成方式不同。

所以，以联网模组接收指令来操作灯泡开关说，从代码上讲，核心区别如下：

方式	联网模组里的MCU	if 逻辑的位置	if 逻辑由谁生成	联网能力在哪
零代码	不用动，且已集成if逻辑 适用简单且标准产品 买的是空白模组，然后自己烧录平台为你生成的已包含if的完整固件	(联网)模组里的 MCU	平台根据你在网页上的if配置，帮你生成代码	(联网)模组里
SoC	要动，要基于SDK写if逻辑 适用简单但非标准产品 买的是空白模组，然后烧录你自己基于平台SDK补充完if开发的完整固件	(联网)模组里的 MCU	你自己手写if 逻辑	(联网)模组里
MCU SDK	不能动，if逻辑去模组外写，适用复杂产品 买的是产商已帮你烧录好标准联网固件的模组(但是无if逻辑)，你不需要烧录	(联网)模组外的 MCU	你自己手写if 逻辑	(联网)模组里

即：
Soc和零代码的区别是Soc需要自己写if，而零代码是在网页上配置完之后就生成了if。而它们和MCU SDK的区别是它们的if写在模组里的MCU，而MCU SDK是写在模组外的其他MCU。

其他区别：

即：
零代码是下载固件，要自己烧录到模组里，业务逻辑是在下载固件前在网页上编辑了，然后之后就在模组里的MCU了。
Soc是你自己写全部固件（联网+业务逻辑）→ 编译烧录进模组 → 业务逻辑在模组内的 MCU 里。
MCU是产商已经帮你烧录好的模组，需要自己在另一个MCU（非产商烧录的模组MCU上）上补充业务逻辑，所以业务逻辑在外部MCU。

1.5、零代码/SoC 与 MCU SDK 的区别

零代码/SoC 与 MCU SDK 的区别是它们的if写在模组里的MCU，而MCU SDK是写在模组外的其他MCU。

1.5.1、为什么会有这种差异？

这背后是产品复杂度和成本/效率权衡的结果：

• 零代码/SoC：针对逻辑简单的产品（如灯泡、插座）。将 if 逻辑放在模组内，只需要一颗芯片（模组），硬件成本最低，开发也最快。
• MCU SDK：针对逻辑复杂的产品（如空调、洗衣机）。这类产品原本就有一颗强大的 MCU 在控制复杂的机械和传感器。此时，让这颗原有的强大 MCU 继续负责业务逻辑（if 逻辑），模组只负责它最擅长的联网，是改动最小、风险最低、开发最快的方案。虽然多了一颗芯片，但复用了原有的软件资产。

1.5.2、如何选择到合适的方式

我的理解是：MCU SDK方式为了针对逻辑复杂的产品（如空调、洗衣机），在他们原有的MCU上去写if业务逻辑，才能在加入了联网模组MCU后，更好的去对原本逻辑和新逻辑做综合的控制；而零代码/SoC针对逻辑简单的产品（如灯泡、插座）。将 if 逻辑写在原有MCU，还是模组里的MCU，其实都没差，因为业务逻辑或者说功能就没几个，相反写在模组里更合适。

你的理解完全正确

你的总结	技术本质	产品逻辑
MCU SDK方式：将if逻辑写在产品原有的MCU上，联网模组只负责通信，便于对原有复杂逻辑和新增联网逻辑做统一、综合的控制。	这是一种解耦架构：业务逻辑与通信逻辑分离。它复用了产品原有的强大计算资源（MCU）和成熟的软件资产，让复杂的控制算法（如空调的变频算法）和联网功能可以独立演进、互不干扰。	适合逻辑复杂、本身就有主控的产品。核心目标是：以最小改动、最低风险的方式，为成熟产品增加联网功能。
零代码/SoC方式：将if逻辑写在模组内的MCU上。对于简单产品，逻辑写在原有MCU还是模组MCU差别不大，而写在模组里更合适。	这是一种集成架构：通信和业务逻辑高度集成在一颗芯片上。它简化了硬件设计，降低了物料成本。	适合功能单一、从零设计的新产品。核心目标是：最快、最便宜地让一个简单产品实现智能化。

即：

1. 如果你面对的是逻辑复杂的现有产品（如空调、洗衣机），你的目标是为它增加联网功能，那么 MCU SDK 方式是改动最小、最稳妥的选择。你的if逻辑将继续写在那个你熟悉的主控MCU上。
2. 如果你是从零开始设计一个简单的产品（如灯泡、插座），你的目标是让它变智能，那么 零代码（不想写代码）或 SoC（想自己写代码）是最直接、成本最低的选择。你的if逻辑将写在模组里。

1.6、零代码 与 SoC 的区别

零代码与Soc的区别是Soc需要自己写if，而零代码是在网页上配置完之后就生成了if。

1.6.1、相比零代码，用SoC还得多自己去写if逻辑，为啥还需要SoC的存在？

SoC依然不可或缺的原因如下：

零代码：只能控制平台定义好的标准硬件，且只能配置“如果…就…”这样的简单联动。如果要处理非标准的，或者是实现复杂的联动，零代码满足不了。

2、实现智能化的五条路径

路径	核心做法	是否用模组	你需要做什么	适合谁
1. 零代码（成品模组）	买模组，在线配置，烧录固件	✅ 用模组	网页点选功能，烧录固件	最快上市，不想碰代码
2. 模组 SoC 方案	买可编程模组，自己写固件	✅ 用模组	在模组 SDK 上写业务逻辑	想控制成本，愿意写代码
3. 模组 MCU SDK	买标准模组，搭配自己的 MCU	✅ 用模组	在自己的 MCU 上写程序	已有主控板，只需加联网
4. 自选芯片 + 开源方案	自己选Wi-Fi芯片(如ESP32) ，用开源方案(如Home Assistant)或自建MQTT服务器	❌ 不用模组	写全套代码，自建 MQTT 服务器：配网、联网、设备发现、云端对接	想完全自主，有全栈能力
5. 自研全套	自己设计射频电路、协议栈	❌ 不用模组	硬件+嵌入式+后端+App 全自研	科技巨头，特殊安全需求

3、涂鸦：硬件开发快速入门

涂鸦智能提供的硬件开发方式包含零代码开发、低代码（MCU SDK）和多代码（模组 SDK等）开发方式。

嵌入式开发。根据开发方式不同，分为以下方案。

开发方案	适用条件	说明
零代码开发	电工、照明、传感等功能相对标准的产品。	涂鸦提供可视化功能配置界面，无需任何编程经验，只需在线配置产品的功能，即可完成固件开发，快速完成产品智能化。
MCU SDK 开发	硬件方案中有 MCU 的产品。	涂鸦提供 MCU SDK，SDK 对上下行通信、OTA、数据解析等功能进行函数接口封装，您可以将 SDK 移植到 MCU 内进行接口适配，并调用相关接口完成应用代码开发，即可实现产品智能化。
Wi-Fi SoC 开发	功能相对简单，可以使用 Wi-Fi 模组直接进行 SDK 二次开发的产品。	涂鸦提供适配了Wi-Fi 协议的 SDK ，SDK 封装了 HAL 硬件层、系统层、网络层、OTA 等接口函数，您只需调用相关接口函数进行应用代码开发，无需关心复杂的功能逻辑，即可快速完成产品智能化。
蓝牙 SoC 开发	功能相对简单，可以使用蓝牙模组直接进行 SDK 二次开发的产品。	涂鸦提供适配了蓝牙协议的 SDK ，SDK 封装了蓝牙协议栈、应用回调、应用功能等接口函数，您只需调用相关接口函数进行应用代码开发，无需关心复杂的功能逻辑，即可快速完成产品智能化。
模组 SDK 开发	功能相对简单，可以使用模组直接进行 SDK 二次开发的产品。	涂鸦提供模组 SDK ，SDK 封装了 HAL 硬件层、系统层、网络层、OTA 等接口函数，您只需调用相关接口函数进行应用代码开发，无需关心复杂的功能逻辑，即可快速完成产品智能化。
网关 SDK 开发	Sub-G、Modbus、CAN、485、蓝牙 LE、Zigbee等各种子设备接入类型的网关设备。	根据子设备的接入方案和网关的开发方式，涂鸦提供 MCU SDK、网关联网 SDK、网关扩展 SDK 等多种方案供选择，您可以根据自身产品的子设备接入方式选择合适的开发方案，快速完成智能化网关开发。
IPC SDK 开发	IP 摄像机（IPC）设备开发。	涂鸦将复杂的 IPC 音视频、P2P、设备控制、OTA 等功能进行接口封装，根据您的芯片平台打包成 SDK ，您可以将 SDK 集成到现有设备内，无需关心设备功能复杂的实现方式，只需调用相关接口进行应用代码开发，即可快速完成 IPC 产品智能化。
QR SDK 开发	带屏幕类的设备。	涂鸦基于您的芯片平台和编译链工具打包 SDK ，以动态链接库（.so）或者静态库（.a）提供给您集成到现有设备内，调用相关的接口完成应用代码开发，即可使用涂鸦 App 扫码配网将设备连接到涂鸦开发者平台，实现产品智能化。
Link SDK 开发	任意自主开发的 智能设备接入涂鸦开发者平台。	Link SDK 提供设备连接、上下行通信和 OTA 等 TuyaOS 核心能力，不依赖具体设备平台及 OS 环境，仅需按照标准进行接口适配即可完成接入，实现产品智能化。

八、如何让 B品牌的音箱 可以控制 A品牌的灯泡

Matter 设备

Matter 协议是 CSA 联盟 与谷歌、亚马逊、苹果公司共同推进的物联网标准连接方案，旨在实现所有 IoT 设备的兼容性，实现一套协议控制所有设备，让设备使用单一协议与任何 Matter 认证的生态系统配合使用。

在Matter出现前，如果你买了A品牌的灯泡和B品牌的音箱，它们很可能无法直接配合。你想用B音箱去关掉A灯泡，需要非常复杂的设置甚至根本做不到。

Matter的诞生就是为了打破这些品牌壁垒。它由苹果、亚马逊、谷歌等行业巨头共同发起，目标是让所有通过Matter认证的设备，无论出自哪个品牌，都能无缝地、安全地协同工作

1、Matter 设备配网

九、其他

普通灯泡里本来就有芯片。一个普通的LED灯泡，即使不智能，它的驱动电路里也有一颗电源管理芯片（或LED驱动芯片）。这颗芯片负责把220V交流电转换成低压直流电，并恒流驱动LED灯珠。所以，普通灯泡里已经有芯片了，只是这颗芯片不能联网、不能编程。

在硬件开发语境里，我们说的“整个灯泡有几颗芯片”，是在忽略电源管理芯片的情况下说的。即：

• “芯片”通常指可编程的MCU（大脑）
• 电源管理芯片被视为“被动元件”或“驱动器件”，不算“智能芯片”

1、说一说硬件主板、模组、芯片、MCU这个几个关系？

MCU是芯片的一种。芯片还包括：电源管理芯片（PMIC）、存储器芯片（Flash、EEPROM）、传感器芯片（温湿度、加速度）、通信芯片（射频前端）

以一个智能空调为例

┌───────────────────────────────────────────────────────────┐
│                    硬件主板（1块）                          │
│  ┌──────────────────┐  ┌──────────────────┐               │
│  │   Wi-Fi模组（1个） │  │  语音模组（1个）   │               │
│  │ ┌──────────────┐ │  │ ┌──────────────┐ │               │
│  │ │  内部MCU芯片	  ││  │ │  内部MCU芯片   │ │               │
│  │ │  （负责联网） 	│ │  │ │  （语音识别）  │ │               │
│  │ └──────────────┘ │  │ └──────────────┘ │               │
│  └──────────────────┘  └──────────────────┘               │
│  ┌──────────────────┐  ┌──────────────────┐               │
│  │  独立主控MCU      │  │  电源管理芯片      │               │
│  │  （控制压缩机）    │  │  （供电）        	 │               │
│  └──────────────────┘  └──────────────────┘               │
└───────────────────────────────────────────────────────────┘

一个智能家居有几个主板、几个模组、几个芯片、几个MCU？

• 主板：通常 1块（除非是折叠屏手机、翻盖设备等复杂结构）
• 模组：通常 1~2个（至少1个联网模组，可选语音/蓝牙等）
• 芯片总数：通常 3~6颗（包括模组内的和主板上的）
• MCU总数：通常 1~3颗（模组内的 + 主板上的独立MCU）

2、模组和 MCU 有什么区别

• MCU 指的是 芯片类型
• 模组 指的是 包含MCU、射频电路、天线的成品组件

MCU 是通用芯片，你可以自己写固件。模组里也有一颗芯片，里面也跑着固件；“模组里也有MCU”——这是关键。

当你“用模组”时，本质上你是在用一颗封装好的MCU（它已经帮你处理好了射频和天线部分）。当你“用自己选的MCU”时，你需要自己解决联网的射频和天线问题。

• 模组硬件是通用的（同一款模组可以用于灯泡、插座、传感器）
• 但不同产品的固件是不同的
• 原始模组是“空白的”，必须烧录你产品的专属固件

End