企业官网建设流程全解析

简介：《百度IOT平台——平台使用手册》是一份面向物联网开发入门者与设备接入实施人员的中文操作文档，聚焦百度IoT云平台的设备接入、研发管理与应用配置流程。压缩包内仅含1个doc文件，大小约1.35MB，为完整Word版手册，便于检索、标注和离线查阅。手册围绕创建产品、下载CA与Profile、心跳检测、数据点设置与测试、批量生产、OTA升级等研发环节展开，并补充新增设备、设备存活、活跃、在网时长及固件版本分布等数据统计口径；服务列表与服务管理、创建与配置应用也有涉及，能帮助读者理解平台各模块的用途和配置要点。对于刚接触物联网平台、需要把设备从创建产品推进到联网调试的读者，文档中的流程顺序和统计指标解释具有较强参照性。已有384人学习，适合需要按手册完成设备云端接入、排查心跳与数据互通问题、梳理OTA和批量生产流程的开发者参考。

1. 把设备接进物联网 IoT 基础平台，翻车点往往不在代码

我见过最常见的场景是这样：产品建好了，Profile 和 CA 也下载了，烧进模组后设备就是不上报心跳，控制台里那台设备一直灰着。折腾一晚上，最后发现 CA 是从上一个测试产品那儿下的，Profile 却来自新批次——文件都在，只是不是一对。物联网 IoT 基础平台这类接入流程有个共同特点：每一步都是强顺序，先建产品才有 Profile，有 Profile 才有心跳，有心跳才能测数据点。跳一步，后面全得回头重来。这篇按平台手册的顺序，把环境准备、创建产品、下载凭证、心跳自检、数据点定义、批量生产、OTA 升级到应用配置整条链路拆开写，适合第一次把设备接进来的人照着走，也适合接过一次但被心跳和数据点卡住的人回头对照。

2. 环境准备：账号权限、烧录工具与目录规范

接入失败的案例里，相当一部分不是配置写错，而是环境没备齐就开始点按钮。设备端要烧录、手机端要扫码、电脑端要下载文件，三头对不上，问题就变成玄学。这一章先把三端的东西列清楚，再谈创建产品。

2.1 账号与项目空间：先确认「新建产品」按钮是亮的

平台的第一步不是技术动作，是权限。手册里写得很清楚：开发者完成注册流程后，进入开发者中心，在设备接入页面点击【新建产品】。这句话里藏了两个前提，缺一个按钮就是灰的或者根本不出现。

第一个前提是账号已经走完开发者注册。这个流程通常包括账号登录、开发者身份开通，有的环境还要走一遍主体信息确认。我一般建议在动手前先完整登录一次控制台，把左侧菜单从「设备接入」到「服务列表」「应用」都点一遍，能正常打开说明权限是通的；某个菜单点进去提示无权限，那就先解决权限，别急着建产品，否则后面下载 Profile 会卡在莫名其妙的地方。

第二个前提是当前所处的项目空间。同一账号可能挂了多个项目，建产品是建在某个项目下的，Profile 和 CA 也归那个项目管。切换项目后如果发现之前建的产品不见了，不是产品丢了，是你在另一个空间里。常见做法是：新建产品前先看一眼页面顶部的项目名，把它记在操作记录第一条，后面所有文件都按这个项目名归档。

2.2 设备端要准备的三样东西：串口、烧录工具、Demo APP

设备侧的准备工作，手册没有单独列章节，但从「烧录」「心跳」「扫码测试」这几个动作能反推出需要什么。我把常用清单列在下面，按重要性排：

串口工具是整套流程里最值得先打通的一环。设备到底有没有连上 Wi-Fi、有没有去连云端、连的时候报什么错，只有串口日志能告诉你。我的习惯是先不烧任何业务固件，只烧一个能打印日志的最小程序，确认串口能出字、能看见联网过程的打印，再往下走。这一步省掉，后面心跳失败就只能靠猜。

烧录工具要注意版本匹配。不同模组厂商的烧录工具界面差别很大，但共同点是都要求选择正确的芯片型号和串口号，选错型号写进去看着成功，设备起来直接不跑。至于 Demo APP，它主要服务于数据点测试环节，用来扫控制台生成的二维码，提前装好并确认能正常登录，比等到测试那一步再折腾要省事。

2.3 一套固定的目录结构和一次校验，能省掉半夜排查

文件管理听起来是小事，但在量产阶段它是大坑。一个产品下可能有测试批次、量产批次，每批都有各自的 Profile，文件名还长得差不多。我一般会在本地按项目建一套固定目录，用命令一次建好：

# 按项目 + 产品型号分层，凭证、固件、描述文件分开存 mkdir -p iot-demo/{ca,profile,firmware,desc,log} # 每次下载完立刻算一遍校验值，烧录前后各对一次 sha256sum iot-demo/ca/* iot-demo/profile/* > iot-demo/checksum.txt

目录命名里带上产品型号，是为了在同时维护多个型号时不至于混淆；ca放平台下载的证书文件，profile放每个设备或每个批次的 Profile，firmware放待 OTA 的固件包，desc放从数据点导出的设备描述文件，log存串口抓下来的日志。校验值那条命令的作用是防止下载中断导致的半截文件——浏览器下载失败但文件还在的情况并不少见，烧进去之后设备行为异常，排查方向会完全跑偏。烧录前跑一次sha256sum -c，对不上就重新下载，比在设备上找问题快得多。

这套结构配合下面的环境对照表使用，基本能把「环境没准备好」这类问题挡在动手之前：

3. 创建产品与凭证落地：CA、Profile 下载和心跳验证

产品和凭证是整个接入流程的地基。产品建错，后面所有文件都得重来；凭证拿错，心跳永远上不去。这一章把新建产品时的三个填写项、下载动作、烧录顺序和心跳判定标准逐个说清楚。

3.1 新建产品的三项基本信息，填错哪个最麻烦

在设备接入页面点【新建产品】，需要设置产品类别、产品型号、联网方式，还可以按需填自定义配置信息。这三项里，产品型号是最不能随手填的一个。

产品类别是分类标签，主要影响控制台里的归类展示和后续服务的选择，填错了修改成本不高。联网方式决定了平台侧对设备连接方式的预期，Wi-Fi、蓝牙、蜂窝这类选项要和模组实际能力对上，选错的话后面排查心跳时容易被误导——设备明明能连上，你却在怀疑平台配置。常见做法是先确定硬件方案，再回来建产品，别倒过来。

产品型号是这三项里最需要谨慎的。它通常会贯穿 Profile 文件、批次管理、OTA 固件版本、数据统计的口径，一旦有设备已经量产再想改型号，等于所有已烧录的设备都要重新处理。我的建议是型号里带上硬件版本或通信模组代号，比如把模组型号作为后缀，这样后续换料时有据可查。自定义配置信息属于可选项，用来记录一些平台不强制但团队内部要看的字段，比如负责人、固件基线版本，填了不亏。

填完点【新建】，产品会出现在新产品研发区域的右侧列表里。看不到的话先刷新，再确认项目空间，最后才怀疑是不是创建失败——这个顺序能省掉不少重复创建。

3.2 下载 Profile 和 CA：一对文件必须来自同一个产品

产品创建成功后，点进这个产品，页面上有【下载 Profile】和【下载 CA】两个按钮。这两个文件是设备与云端互通的钥匙，缺一个都通不了。

CA 是证书文件，设备联网后靠它和云端建立可信连接；Profile 里带的是这个产品（或这个批次）对应的设备身份信息。手册里提到，设备联网后 CA 会向平台定时发送心跳，用来验证设备是否已经和云端互通。换句话说，心跳能不能上报，直接取决于这两个文件是否配对、是否正确烧录。

这里有个容易被忽略的点：下载这两个文件时，必须确认当前点开的产品就是目标产品。控制台里产品多了，标签页开着好几个，很容易在 A 产品的页面下载了 B 产品的 CA。我一般的做法是下载完立刻把文件重命名成带产品型号和下载日期的形式，再算一次校验值，两个文件放同一个子目录，物理上绑在一起：

# 下载后立刻按 产品型号_文件类型_日期 重命名，避免跨产品混用 mv ~/Downloads/profile*.json iot-demo/profile/demo-v1_profile_$(date +%Y%m%d).json mv ~/Downloads/ca*.pem iot-demo/ca/demo-v1_ca_$(date +%Y%m%d).pem # 再跑一次校验，确认两个文件都在且完整 ls -l iot-demo/profile iot-demo/ca

重命名的意义不只是好看。量产阶段一个产品下会有多批 Profile，靠原始下载文件名根本分不清批次，重命名规则里带型号和日期，后面找文件基本不用思考。校验那步是确认文件真的落盘了，尤其是网络不稳的环境下。

3.3 烧录顺序与心跳检测：判断「通了」的唯一标准

烧录这一步，顺序比技巧重要。我踩过的坑是先把业务固件烧进去，再回头补 CA 和 Profile，结果设备起来直接跑业务逻辑，连接失败也不打印原因，只能整片擦除重来。稳妥的顺序是：先擦除，再写 CA 和 Profile，最后写业务固件。这样任何一步失败都能定位到具体环节，而不是面对一个跑起来但什么都不报的设备。

烧录完成后上电，用串口看日志。合格的日志至少能看到联网过程、连接云端的过程，以及心跳上报的动作。日志里如果卡在连接阶段，先回去查 CA 是否写对；如果连上了但控制台看不到设备，往下走心跳检测。

心跳检测在设备接入页面，点开对应产品后点【心跳检测】按钮，页面会显示正在检测。检测成功会弹窗提示，说明设备已经向云端上报过心跳，链路是通的；检测失败，手册给的方向是检查烧录过程是否有误，然后可以重新检测。这个提示很朴实，但确实是绝大多数失败的原因——烧录时选错文件、写到了错误的地址、烧完没复位，都会表现成心跳检测失败。

我一般会把心跳检测当成一道闸门：这一步不过，绝不往下做数据点。因为数据点测试依赖设备已经在线，链路不通的情况下去测数据点，看到的失败现象会混在一起，排查成本翻倍。检测通过后，顺手在串口日志里截一段心跳打印存进log目录，后面量产或者 OTA 出问题时，这段日志就是最直接的对照基线。

4. 数据点、量产与升级：数据点定义、批次 Profile 与 OTA 固件包

心跳通了只说明设备能连上平台，真正决定设备能不能用的，是数据点定义得对不对、批次 Profile 发得下去发不下去、固件升不升得动。这一章按从小到大的顺序走：先定义单个数据点，再测，再批量，再升级。

4.1 数据点：类型和数据类型的选择决定了后面所有麻烦

数据点定义的是设备和云端之间具体交互哪些数据。操作路径是：在产品数据点页面选择要编辑数据点的产品，点【新建数据点】，选数据点类型，再根据需要选数据类型，填完点【确认】，创建成功后还能编辑和删除。

数据点类型大致分两类：一类是设备上报给云端的状态量，比如温度、电量、开关状态；另一类是云端下发给设备的控制量，比如开灯、设置阈值。这个分类看着简单，实际决定了数据流的方向，方向搞反了，设备上报的数据在云端查不到，控制指令发下去设备也不动。

数据类型的选择更细，常见的整数、浮点、布尔、字符串、枚举各有适用场景。我的经验是：能用布尔就别用整数，能用枚举就别用字符串。原因在于设备端解析和云端展示都更省事，枚举还能在控制台上直接把数值翻成可读文字，排查时不用再对照文档。浮点类型要注意精度，传感器数值上报前先在设备端做一次取整或定标，避免出现一长串小数。

创建完数据点后，控制台里可以对已创建的数据点做编辑和删除。这里有个细节：数据点改定义，已经烧录的设备描述文件就作废了，需要重新导出重烧。所以数据点在测试阶段就该定稳，别等到量产前还在改字段。

4.2 导出设备描述文件，和 CA 一起烧进设备

数据点建好之后，不能直接烧。手册说得很明确：产品创建完数据点后，需要导出为设备描述文件，之后把它与 CA 集成，烧入设备，才能实现设备与云端的数据互通。也就是说，设备端真正认识数据点的依据是这个描述文件，不是控制台上的配置本身。

这一步最容易出的问题是顺序错。有人先导出了描述文件，回头又去改数据点，改完直接烧旧文件，结果设备上报的字段云端不认识。正确做法是：数据点定稿 → 导出描述文件 → 和对应产品的 CA 放同一目录 → 一起烧录 → 再测。文件名我一般按「产品型号_描述文件_日期」存，和 CA 的命名规则对齐。

描述文件里包含的字段以控制台导出结果为准，设备端要做的就是把这个文件和 CA 一起写进指定分区，注意两个文件写入的地址不要重叠。烧录工具里通常会有一个分区或地址配置，写之前对一遍模组手册，写完复位，用串口确认设备启动时读到了描述文件。这一步如果日志里提示描述文件校验失败，基本就是地址写错或者文件本身不完整，回去对校验值。

4.3 Demo APP 扫码测试：先跑通一条数据，再谈全量

数据点测试是整条链路里最直观的一环，也最容易被跳过。手册的操作是：在数据点设置页面点【数据点测试】按钮，然后用 Demo APP 扫描二维码，开始测试。

扫码测试的价值在于，它同时验证了三件事：设备在线、描述文件和 CA 匹配、数据点定义能被云端正确解析。任何一环不对，测试就会卡住或者数据对不上。常见的失败表现是扫码之后 APP 一直转圈，或者能连上但看不到数据项，前者多半是设备根本没在线，后者多半是数据点定义和描述文件不同步。

我一般会先只测一个数据点，就测最简单的那条上报字段。这条通了，再一次性把所有数据点都测一遍。这样出问题时很容易判断是单个数据点定义错了，还是整体链路有问题。测试通过后，把测试截图和串口日志一起归档，量产批次出问题时拿这批数据当基线对照。

4.4 批量生产：一个批次最多 10000 个 Profile 怎么规划

数据点创建并检测无问题后，就可以申请批量生产，批量生成大量 Profile。操作是选择要批量生产的产品型号，点【新建批次】，设置批次信息，创建完成后点开这个批次，就能下载对应的 Profile。

手册里给了一个硬约束：Profile 数量最多为 10000 个。这个数字要在建批次前就想清楚。如果一次生产量超过一万台，就得拆成多个批次，每个批次独立下载、独立归档、独立记录发放去向。批次拆得清不清楚，直接影响售后——某台设备的 Profile 丢了想补，你得能立刻定位到它在哪一批。

批次命名我建议带时间、产线或代工厂代号、数量区间三要素，比如「型号_年月_产线_序号段」。批次信息填写时把备注写满，别嫌麻烦，三个月后回来看看，没有备注的批次基本无法辨认用途。下载下来的 Profile 是压缩包还是单文件，以平台实际产出为准，解压后先算校验值，再和批次记录一起存到profile目录下按批次分的子目录里。

还有一个容易忽略的点：批量生产出来的 Profile 和测试阶段用的那个不是一回事。测试用的 Profile 通常对应一台调试设备，量产批次里每台设备应该用它自己那份。见过有人图省事，一个批次的设备全烧同一份配置，结果设备之间身份冲突，云端统计全部乱掉。批次下载完，按序列号或产线工位分发，一个设备一份，这是不能省的规矩。

4.5 OTA 固件包与应用配置：10MB zip 与 AK/SK 的硬约束

OTA 升级这块，手册给了三条明确约束，全都属于「配置前就要知道」的类型。操作路径是在 OTA 升级页面选择要升级的产品，点上传固件，固件最大 10MB，格式为 zip；然后填固件版本号和通知方式，完成升级规则配置。

10MB 这个上限意味着固件不能无脑打包。常见的做法是分包：资源类文件（比如语音、字库、图片）单独做一次升级，主固件只留代码和必要配置；压缩包里的目录结构按设备端升级程序约定的路径组织，不要把多套配置一起塞进去。上传前先本地确认解压后的目录结构，再压一次，避免把外层文件夹也压进去导致设备端解压路径不对。

通知方式有四种，手册写得很明白：静默是直接对设备进行升级，无提醒、无需用户干预；强提醒、弱提醒和被动提醒是推送给 APP 端的信息，可以在 APP 里做相应规则设置。选哪种取决于设备的用户场景——没人盯着的小型传感器节点适合静默，用户天天开 APP 的设备适合提醒式，避免升级时打断正常使用。我一般先在一个批次上试静默升级，验证固件本身没问题，再推广到全部批次。

应用配置是 APP 控制设备的前提。设备需要通过 APP 控制，必须先创建应用，拿到应用的 AK、SK 等基本信息。操作是点【创建应用】，输入应用名称即可创建成功；配置时选择要配置的应用，可以复制 APP 的 API Key 和 Secret Key，然后按平台填写：Android 需要填包名和应用签名，iOS 需要填 Bundle ID。

包名和签名这块翻车率很高。Android 的应用签名要和实际打包用的签名一致，调试签名和正式签名不是一回事，用错了 APP 连不上平台；iOS 的 Bundle ID 必须和工程里完全一致，大小写都不能差。手册里对这两项的要求写得很直接，填之前先在本地工程配置里复制一遍，别手敲。

5. 排查常见问题：心跳不通、扫码无反应、OTA 推不下去

接入流程里绝大多数问题都会在几个固定位置复现。这一章按现象整理五条，每条都给出原因和解决方向，遇到时对着这条链路走一遍，比漫无目的地试要快。

5.1 心跳检测一直失败，但设备日志显示已联网

现象：设备串口日志能看到连上 Wi-Fi、也能看到尝试连接云端，但控制台点【心跳检测】一直失败，多次重试都一样。

原因：最常见的是 CA 或 Profile 烧错了——两个文件来自不同产品，或者其中一个是上一个测试产品的残留。其次是烧录地址不对，文件写进去了但设备启动时没读到。还有一种情况是烧录后没有复位，设备跑的还是上一次的固件。

解决：先回控制台确认当前产品，重新下载这一对 CA 和 Profile，算校验值后整片擦除重烧，注意写地址和复位动作。重烧后看串口日志里有没有心跳上报的打印，有打印再点检测。仍然失败的话，把这一轮的串口日志和下载的文件校验值一起留档，用来判断是文件问题还是链路问题。

5.2 数据点测试扫码后一直转圈，或者能看到设备但数据项是空的

现象：用 Demo APP 扫控制台二维码，界面一直转圈不返回结果；或者连上了但看不到任何数据点。

原因：转圈通常是设备不在线，测试依赖设备已经连上云端。数据项为空则多半是描述文件和当前数据点不同步——改了数据点但没重新导出描述文件，或者导出了但没重烧。

解决：先回第 3 章确认心跳是通的，再回数据点页面核对当前定义，重新导出描述文件，和 CA 一起重烧。测试时先只保留一个最简单的上报字段，跑通再加其他字段。扫码前确认 Demo APP 相机权限正常，二维码是在当前产品下生成的。

5.3 OTA 上传固件被拒，或上传成功但设备侧没反应

现象：点上传固件，提示格式或大小不符合；或者包传上去了，规则也配了，设备那边一直没动静。

原因：大小超了 10MB 上限，或者不是 zip 格式，这是上传被拒的两大原因。设备无反应则通常是版本号问题——新固件版本号没有大于设备当前版本，设备端判定不需要升级；也可能是通知方式选了提醒类，但 APP 侧规则没配，消息推不出去。

解决：上传前先在本地看压缩包大小和扩展名，超了就拆包，优先把资源类内容拆出去。版本号按递增规则填，建议在设备端也打印一次当前版本，方便对照。先用静默方式推一台测试设备，确认固件本身能升上去，再考虑提醒方式。

5.4 应用配好了，但 APP 下发控制指令设备不响应

现象：应用创建成功，AK/SK 也复制了，APP 能登录，但下发控制指令后设备没有任何动作，云端也看不到状态变化。

原因：Android 的包名或应用签名和实际打包不一致，iOS 的 Bundle ID 和工程配置有出入，导致请求被拒。也可能是控制类数据点根本没有定义成下发方向，云端不知道要往哪个字段写。

解决：把工程里的包名、签名指纹、Bundle ID 逐字符对照控制台配置，别凭记忆填。再回数据点页面确认控制字段的类型和方向，改过定义就重新导出描述文件重烧设备。测试时先用最直接的一条开关指令，排除业务逻辑干扰。

5.5 数据统计里的设备数和实际发货数对不上

现象：统计页面的新增设备、设备存活、设备活跃几个数字互相不一致，和实际出货量也差很多。

原因：这几个口径定义不同，混着看必然对不上。新增设备指的是首次向云端上报心跳、即已激活的设备数量；设备存活是有数据上报的设备，包括心跳和通过 APP 连接控制时的上报；设备活跃是在指定时间内有非心跳数据上报的设备。另外一次心跳代表在网 30 分钟，在网时间按这个换算，设备离线后统计还会延续一段。

解决：先明确你要回答的是哪个问题——激活量看新增设备，在线规模看存活，真实使用看活跃。对比数字时把时间范围对齐，再排除未激活设备（固件版本分布不统计未激活设备）。日常巡检我一般只看活跃和固件版本分布两项，前者反映真实使用，后者反映升级覆盖情况。

6. 验收：五分钟把一条数据从设备送到控制台

装完不算完，能复现才算。我习惯在交付前跑一遍固定验收，全程控制在五分钟内，任何一步卡住就说明这条链路还有问题，不许绕过。

验收从干净状态开始：设备擦除、重新烧录这一产品的 CA、Profile、描述文件和业务固件，上电。第一步看串口，确认设备联网并在日志里打出心跳动作；第二步回控制台点【心跳检测】，等弹窗提示成功；第三步打开数据点页面，点【数据点测试】，用 Demo APP 扫码，确认能看到预先定义的那条上报字段并读到合理数值；第四步在 APP 里下发一条控制指令，回串口确认设备收到并执行；第五步看一眼数据统计，确认这台设备的激活计数有变化。

跑完这一遍，顺手把串口日志、扫码截图、批次号、固件版本号存进同一个目录，写上日期。这份东西在后来出问题时价值极高——有基线才能判断是这次改动引入的问题，还是一直就存在。量产阶段我还会额外抽一台设备做同样流程，抽检记录和批次绑定。

血泪经验就一条：接入这类平台，别相信「上次是这么配的」。产品型号、批次、应用签名，任何一项换了，整条链路都要重新验一遍。从那以后我每次上线前都强制走一遍这五步验收，宁可多花五分钟，也不想在半夜对着一个灰着的设备图标猜原因。希望帮到你。

本文还有配套的精品资源，点击获取