HCIP-IoT DeveloperV2.0实验素材，下载全部压缩包，解压part01即可。

创建了一个MQTT协议设备，按照文档https://support.huaweicloud.com/api-IoT/iot-api.pdf的8.2.2章节MQTT CONNECT 连接鉴权的说明client Id为  {设备的deviceId}_0_0_时间戳    具体到我的设备是 8598553f-1f3d-47e6-a7b4-bbdabce316ba_0_0_2019070314其中时间戳按照说明是YYYYMMDDHH格式User name为deviceId，具体为 8598553f-1f3d-47e6-a7b4-bbdabce316baPassword的值为使用“HMACSHA256”算法以时间戳为秘 钥，对secret进行加密后的值。 secret为注册设备时平台返回的secret：9254********a137c0e4按照这个说明，时间戳选择2019070314也是YYYYMMDDHH格式对吗？用这个在线工具http://tool.oschina.net/encrypt?type=2使用HMACSHA256”算法以时间戳为秘 钥，对secret进行加密后的值作为密码然后使用MQTT.fx 软件模拟设备链接服务器  49.4.93.24 端口 8883 ，无法建立链接。请问专家上述步骤有什么问题？为何链接不上MQTTS服务器？还需要什么设置吗？谢谢！在博客中找到一篇文章，完美解决了我的这个问题：参见：使用MQTT.fx工具连接IoT平台--源码附件：回复可见******https://bbs.huaweicloud.com/blogs/ca6a27ee34c311e9bd5a7ca23e93a891感谢大神IOBOhttps://bbs.huaweicloud.com/community/usersnew/id_1539070194174500感谢华为梁工的回复。很关键的指点，是证书的问题。证书没找对。谢谢！

HCIA-IoT V2.0课程即将发布，特将实验环境包上传至论坛，方便学员取用。

KubeEdge 是华为捐献给 CNCF 的第一个开源项目，也是全球首个基于 Kubernetes 扩展的，提供云边协同能力的开放式边缘计算平台。KubeEdge 的名字来源于 Kube + Edge，顾名思义就是依托 Kubernetes 的容器编排和调度能力，实现云边协同、计算下沉、海量设备接入等。K3S 是 Rancher 开源的一个自己裁剪的 Kubernetes **行版，K3S 名字来源于 K8s – 5，这里的“5”指的是 K3S 比 Kubernetes 更轻量使得它能更好地适配 CI，ARM，边缘技术，物联网和测试这 5 个场景。同样是基于 Kubernetes，同样是致力于解决边缘场景问题的开源软件，这两个项目不免经常被人拿来比较。本文将以边缘计算的实际场景和挑战为出**点，为您剖析 Kubernetes 能够在边缘计算领域的**力点，最后全方位对比 KubeEdge 和 K3S。边缘计算场景分类与挑战这里要讨论的“边缘”特指计算资源在地理分布上更加靠近设备，而远离云数据中心的资源节点。典型的边缘计算分为物联网（例如：下一代工业自动化，智慧城市，智能家居，大型商超等）和非物联网（例如：游戏，CDN 等）场景。在现实世界中，边缘计算无法单独存在，它必定要和远程数据中心 / 云打通（具体原因见下文）。以 IoT（Internet of Things，物联网）为例，边缘设备除了拥有传感器收集周边环境的数据外，还会从云端接收控制指令。边缘设备与云连接一般有两种模式：直连和通过中继边缘节点连接，如下图所示:边缘设备能否直连云端 / 数据中心取决于是否有全球唯一可路由的 IP，例如：手机、平板电脑等。不过，大部分的设备通过近场通信协议与边缘节点通信，进而和云端 / 数据中心连接的。边缘节点是设备的汇聚点，有分配 IP 地址，扮演了边缘网关的作用。边缘节点为普通的设备提供 IP 地址，也可以运行容器。我们注意到，边缘节点也是有不同层级的，而划分的标准之一就是资源（计算、存储、网络带宽等）的大小。如上所示，我们将 edge 分为“Device Edge”和“Infrastructure Edge”。Device Edge（设备边缘）是指那些并不被认为是 IT 基础设施组成部分的边缘节点，例如：火车、油田、工厂和家庭等。通常它们没什么计算能力，被用于解决最后“一公里”接入的问题，一个典型的例子就是智能路由器，它一端通过红外信号控制家中电器，另一端通过网络和云数据中心相连。由于设备边缘网络稳定性较差，因此必须要考虑它们会较长时间离线的情况（例如火车过隧道）。注：日常生活中很多设备我们可以看成是 device+device edge 的结合体，例如智能手机。Infrastructure Edge（基础设施边缘）相对于 Device Edge 计算和存储能力都更强，而且通常通过骨干网与数据中心连接，因此具有更大的网络带宽和更加可靠的网络连接，例如：CDN，游戏服务器等。基础设施边缘除了能运行容器外，有些甚至还有足够资源运行完整的 Kubernetes。对边缘节点进行分类的意义在于，针对不同层级的边缘需要有针对性的部署模型，并且平台要为边缘节点提供通信能力。最后，我们总结一下当前边缘计算领域面临的几个挑战：云边协同：AI/ 安全等业务在云和边的智能协同、弹性迁移；网络：边缘网络的可靠性和带宽限制；管理：边缘节点的资源管理与边缘应用生命周期管理；扩展：高度分布和大规模的可扩展性；异构：边缘异构硬件和通信协议。其中，云边协是当前面临最大的技术挑战！为什么我们需要云边协同边缘计算和云计算不是两种互斥的技术，它们是相辅相成的关系。而且从场景需求上看，IoT/Edge 与云数据中心有一些相似之处，例如：边缘也有管理节点的计算、存储、网络等资源的需求；边缘应用也想容器化和微服务化；边缘计算希望能有标准的 API 和工具链；安全，数据 / 信道加密和认证授权。因此，将云数据中心的现有架构和能力顺势延伸到边缘就变得水到渠成了。下面列举了一些需要云边协同的场景：AI 云上训练，边缘执行。即充分**挥云计算海量资源的优势，将 AI 模型的训练放在云端，而 AI 的执行则贴近设备侧；微服务，DevOps。微服务和 DevOps 不仅仅是云上开**的专利，将它们引入边缘将会显著加速嵌入式设备、机器人等 IoT 软件的迭代周期，提升部署和运维效率；数据备份转储。例如，海量的工业数据（加密后）存储在云端；远距离控制。云端远程下**对边缘设备的控制信号；自动扩展。由于边缘节点不如云具备良好的自动扩展能力，因此可以选择在峰值时将边缘的负载弹性扩容到云上。我们已经积累了足够的管理云上资源的经验，现在下一步的挑战就是如何构建一个边缘云平台，把对云上资源的管理方法延伸到边缘，让我们能够无缝地管理边缘的资源和设备。边缘云平台将重点解决以下问题：大规模 / 异构的设备，网关和边缘节点的接入；大量遥测数据汇聚、处理后提供给云端应用使用；设备安全和识别服务；支持远程下达对设备的指令；自动创建和管理边缘节点和设备；实现云端对边缘应用的编排、部署和配置；为边缘应用的开**提供数据存储、事件管理、API 管理和数据分析等能力。Kubernetes 的优势与挑战Kubernetes 已经成为云原生的标准，并且能够在任何基础设施上提供一致的云上体验。我们经常能够看到“容器 + Kubernetes”的组合在 DevOps **挥 10X 效率，最近也有越来越多 Kubernetes 运行在数据中心外（边缘）的需求。如果要在边缘部署较复杂的应用，那么 Kubernetes 是个理想的选择：容器的轻量化和可移植性非常适合边缘计算的场景；Kubernetes 已经被证明具备良好的可扩展性；能够跨底层基础设施提供一致的体验；同时支持集群和单机运维模式；Workload 抽象，例如：Deployment 和 Job 等；应用的滚动升级和回滚；围绕 Kubernetes 已经形成了一个强大的云原生技术生态圈，诸如：监控、日志、CI、存储、网络都能找到现成的工具链；支持异构的硬件配置（存储、CPU、GPU 等）；用户可以使用熟悉的 kubectl 或者 helm chart 把 IoT 应用从云端推到边缘；边缘节点可以直接映射成 Kubernetes 的 Node 资源，而 Kubernetes 的扩展API（CRD）可以实现对边缘设备的抽象。然而 Kubernetes 毕竟是为云数据中心设计的，要想在边缘使用 Kubernetes 的能力，Kubernetes 或其扩展需要解决以下问题：ARM 的低功耗和多核的特点又使得其在 IoT/Edge 领域的应用非常广泛，然而大部分的 Kubernetes **行版并不支持 ARM 架构；很多设备边缘的资源规格有限，特别是 CPU 处理能力较弱，因此无法部署完整的 Kubernetes；Kubernetes 非常依赖 list/watch 机制，不支持离线运行，而边缘节点的离线又是常态，例如：设备休眠重启；Kubernetes 的运维相对于边缘场景用到的功能子集还是太复杂了；特殊的网络协议和拓扑要求。设备接入协议往往非 TCP/IP 协议，例如，工业物联网的 Modbus 和 OPC UA，消费物联网的 Bluetooth 和 ZigBee 等；设备多租。关于如何在边缘使用 Kubernetes，Kubernetes IoT/Edge WG 组织的一个调查显示，30% 的用户希望在边缘部署完整的 Kubernetes 集群，而 70% 的用户希望在云端部署 Kubernetes 的管理面并且在边缘节点上只部署 Kubernetes 的 agent。把 Kubernetes 从云端延伸到边缘，有两个开源项目做得不错，分别是 KubeEdge 和 K3S，下面我们将详解这两个项目，并做全方位的对比。KubeEdge 架构分析KubeEdge 是首个基于 Kubernetes 扩展的，提供云边协同能力的开放式智能边缘平台，也是 CNCF 在智能边缘领域的首个正式项目。KubeEdge 重点要解决的问题是：云边协同资源异构大规模轻量化一致的设备管理和接入体验KubeEdge 的架构如下所示：KubeEdge 架构上清晰地分为**层，分别是：云端、边缘和设备层，这是一个从云到边缘再到设备的完整开源边缘云平台，消除了用户厂商绑定的顾虑。KubeEdge 的边缘进程包含以下 5 个组件：edged 是个重新开**的轻量化 Kubelet，实现 Pod，Volume，Node 等 Kubernetes 资源对象的生命周期管理；metamanager 负责本地元数据的持久化，是边缘节点自治能力的关键；edgehub 是多路复用的消息通道，提供可靠和高效的云边信息同步；devicetwin 用于抽象物理设备并在云端生成一个设备状态的映射；eventbus 订阅来自于 MQTT Broker 的设备数据。KubeEdge 的云端进程包含以下 2 个组件：cloudhub 部署在云端，接收 edgehub 同步到云端的信息；edgecontroller 部署在云端，用于控制 Kubernetes API Server 与边缘的节点、应用和配置的状态同步。Kubernetes maser 运行在云端，用户可以直接通过 kubectl 命令行在云端管理边缘节点、设备和应用，使用习惯与 Kubernetes 原生的完全一致，无需重新适应。K3S 架构分析K3S 是 CNCF 官方认证的 Kubernetes **行版，开源时间较 KubeEdge 稍晚。K3S 专为在资源有限的环境中运行 Kubernetes 的研**和运维人员设计，目的是为了在 x86、ARM64 和 ARMv7D 架构的边缘节点上运行小型的 Kubernetes 集群。K3S 的整体架构如下所示：事实上，K3S 就是基于一个特定版本 Kubernetes（例如：1.13）直接做了代码修改。K3S 分 Server 和 Agent，Server 就是 Kubernetes 管理面组件 + SQLite 和 Tunnel Proxy，Agent 即 Kubernetes 的数据面 + Tunnel Proxy。为了减少运行 Kubernetes 所需的资源，K3S 对原生 Kubernetes 代码做了以下几个方面的修改：删除旧的、非必须的代码。K3S 不包括任何非默认的、Alpha 或者过时的 Kubernetes 功能。除此之外，K3S 还删除了所有非默认的 Admission Controller，in-tree 的 cloud provider 和存储插件；整合打包进程。为了节省内存，K3S 将原本以多进程方式运行的 Kubernetes 管理面和数据面的多个进程分别合并成一个来运行；使用 containderd 替换 Docker，显著减少运行时占用空间；引入 SQLite 代替 etcd 作为管理面数据存储，并用 SQLite 实现了 list/watch 接口，即 Tunnel Proxy；加了一个简单的安装程序。K3S 的所有组件（包括 Server 和 Agent）都运行在边缘，因此不涉及云边协同。如果 K3S 要落到生产，在 K3S 之上应该还有一个集群管理方案负责跨集群的应用管理、监控、告警、日志、安全和策略等，遗憾的是 Rancher 尚未开源这部分能力。KubeEdge 与 K3S 全方位对比部署模型KubeEdge 遵循的是以下部署模型:KubeEdge 是一种完全去中心化的部署模式，管理面部署在云端，边缘节点无需太多资源就能运行 Kubernetes 的 agent，云边通过消息协同。从 Kubernetes 的角度看，边缘节点 + 云端才是一个完整的 Kubernetes 集群。这种部署模型能够同时满足“设备边缘”和“基础设施边缘”场景的部署要求。K3S 的部署模型如下所示：K3S 会在边缘运行完整的 Kubernetes 集群，这意味着 K3S 并不是一个去中心化的部署模型，每个边缘都需要额外部署 Kubernetes 管理面。这种部署模型带来的问题有：在边缘安装 Kubernetes 管理面将消耗较多资源，因此该部署模型只适合资源充足的“基础设施边缘”场景，并不适用于资源较少的“设备边缘”的场景；集群之间网络需要打通；为了管理边缘 Kubernetes 集群还需要在上面叠加一层多集群管理组件（遗憾的是该组件未开源）。云边协同云边协同是 KubeEdge 的一大亮点。KubeEdge 通过 Kubernetes 标准 API 在云端管理边缘节点、设备和工作负载的增删改查。边缘节点的系统升级和应用程序更新都可以直接从云端下**，提升边缘的运维效率。另外，KubeEdge 底层优化的多路复用消息通道相对于 Kubernetes 基于 HTTP 长连接的 list/watch 机制扩展性更好，允许海量边缘节点和设备的接入。KubeEdge 云端组件完全开源，用户可以在任何公有云 / 私有云上部署 KubeEdge 而不用担心厂商锁定，并且自由集成公有云的其他服务。K3S 并不提供云边协同的能力。边缘节点离线自治与 Kubernetes 集群的节点不同，边缘节点需要在完全断开连接的模式下自主工作，并不会定期进行状态同步，只有在重连时才会与控制面通信。此模式与 Kubernetes 管理面和工作节点通过心跳和 list/watch 保持状态更新的原始设计非常不同。KubeEdge 通过消息总线和元数据本地存储实现了节点的离线自治。用户期望的控制面配置和设备实时状态更新都通过消息同步到本地存储，这样节点在离线情况下即使重启也不会丢失管理元数据，并保持对本节点设备和应用的管理能力。K3S 也不涉及这方面能力。设备管理KubeEdge 提供了可插拔式的设备统一管理框架，允许用户在此框架上根据不同的协议或实际需求开**设备接入驱动。当前已经支持和计划支持的协议有：MQTT，BlueTooth，OPC UA，Modbus 等，随着越来越多社区合作伙伴的加入，KubeEdge 未来会支持更多的设备通信协议。KubeEdge 通过 device twins/digital twins 实现设备状态的更新和同步，并在云端提供 Kubernetes 的扩展 API 抽象设备对象，用户可以在云端使用 kubectl 操作 Kubernetes 资源对象的方式管理边缘设备。K3S 并不涉及这方面能力。轻量化为了将 Kubernetes 部署在边缘，KubeEdge 和 K3S 都进行了轻量化的改造。区别在于 K3S 的方向是基于社区版 Kubernetes 不断做减法（包括管理面和控制面），而 KubeEdge 则是保留了 Kubernetes 管理面，重新开**了节点 agent。需要注意的是，K3S 在裁剪 Kubernetes 的过程中导致部分管理面能力的缺失，例如：一些 Admission Controller。而 KubeEdge 则完整地保留了 Kubernetes 管理面，没有修改过一行代码。下面我们将从二进制大小、内存和 CPU **个维度对比 KubeEdge 和 K3S 的资源消耗情况。由于 KubeEdge 的管理面部署在云端，用户不太关心云端资源的消耗，而 K3S 的 server 和 agent 均运行在边缘，因此下面将对比 KubeEdge agent，K3S agent 和 K3S server 这**个不同的进程的 CPU 和内存的资源消耗。测试机规格为 4 vCPU，8GB RAM。内存消耗对比分别用 KubeEdge 和 K3S 部署 0~100 个应用，分别观测两者的内存消耗，对比如下所示：从上图可以看出，内存消耗：KubeEdge agent < K3S agent < K3S Server。有意思的是，K3S agent 即使不运行应用也消耗 100+MB 的内存，而 K3S server 在空跑的情况下内存消耗也在 300MB 左右。CPU 使用对比分别用 KubeEdge 和 K3S 部署 0~100 个应用，分别观测两者的 CPU 使用情况，对比如下所示：从上图可以看出，KubeEdge agent CPU 消耗要比 K3S agent 和 server 都要少。二进制大小KubeEdge agent 二进制大小为 62MB，K3S 二进制大小为 36MB。大规模Kubernetes 原生的可扩展性受制于 list/watch 的长连接消耗，生产环境能够稳定支持的节点规模是 1000 左右。KubeEdge 作为华为云智能边缘服务 IEF 的内核，通过多路复用的消息通道优化了云边的通信的性能，压测**现可以轻松支持 5000+ 节点。而 K3S 的集群管理技术尚未开源，因为无法得知 K3S 管理大规模集群的能力。小结K3S 最让人印象深刻的创新在于其对 Kubernetes 小型化做的尝试，通过剪裁了 Kubernetes 一些不常用功能并且合并多个组件到一个进程运行的方式，使得一些资源较充足的边缘节点上能够运行 Kubernetes，让边缘场景下的用户也能获得一致的 Kubernetes 体验。然而通过上面的性能对比数据**现，K3S 的资源消耗还是比 KubeEdge 要高出好几倍，而且动辄几百 MB 的内存也不是大多数设备边缘节点所能提供的。最重要的是，Kubernetes 最初是为云数据中心而设计的，很多边缘计算场景特殊的问题原生 Kubernetes 无法很好地解决， K3S 直接修改 Kubernetes 的代码甚至基础实现机制（例如，使用 SQLite 替换 etcd）的做法仍值得商榷。关于什么能改，什么不能改以及怎么改？每个用户根据自己的实际需求有各自的观点，而且也很难达成一致。另外， K3S 这种侵入式的修改能否持续跟进 Kubernetes 上游的**展也是一个未知数。KubeEdge 和 K3S 走的是另一条道路，KubeEdge 是一个从云到边缘再到设备的完整边缘云平台，它与 Kubernetes 的耦合仅仅是 100% 兼容 Kubernetes 原生 API。KubeEdge 提供了 K3S 所不具备的云边协同能力，开**了更轻量的边缘容器管理 agent，解决了原生 Kubernetes 在边缘场景下的离线自治问题，并且支持海量异构边缘设备的接入等。KubeEdge 最近捐献给 CNCF，成为 CNCF 边缘计算领域的第一个正式项目，就是为了和社区合作伙伴一起制定云和边缘计算协同的标准，结束边缘计算没有统一标准和参考架构的混沌状态，共同推动边缘计算的产业**展。最后，边缘计算还有广阔的**展前景，KubeEdge 和 K3S 都是非常年轻的优秀开源项目，我相信未来他们会在相互学习的过程**同进步，更好地解决边缘计算用户的需求。

SCADA(Supervisory Control And Data Acquisition)系统，即数据采集与监视控制系统。SCADA系统是以计算机为基础的DCS与电力自动化监控系统；它应用领域很广，可以应用于电力、冶金、石油、化工、燃气、铁路等领域的数据采集与监视控制以及过程控制等诸多领域。系统架构：SCADA实例—中央空调监控系统数据采集·下机位功能：数据 采集：下位机配置的各种输入设备（DI、AI等）进行数据采集。控制：下位机配置的各种输出设备（DO、AO等）对现场设备进行控制。下位机接收上位机的监控，并且向上位机传输各种现场数据。RTU的功能：RTU的主要作用是进行数据采集及本地控制，进行本地控制时作为系统中一个独立的工作站，这时RTU可以独立的完成连锁控制、前馈控制、反馈控制、PID等工业上常用的控制调节功能；进行数据采集时作为一个远程数据通讯单元，完成或响应本站与中心站或其它站的通讯和遥控任务。工业物联网通信终端：智能仪表：在一些侧重数据采集、信息集中管理与远程监管的应用中，远程控制功能要求较低。在这类SCADA系统中，大量使用各种现场仪表做下位机，如智能流量计量表、冷量热量表、智能巡检仪等。数据采集上机位：上位机系统通常包括SCADA服务器、WEB服务器等，这些设备通常采用以太网联网。根据安全性要求，上位机系统还可以实现冗余，即配置两台SCADA服务器，当一台出现故障时，系统自动却换到另外一台工作。上机位的功能：数据传输处理：通信网络实现SCADA系统的数据通信，是SCADA系统的重要组成部分。与一般的过程监控相比，通信网络在SCADA系统中扮演的作用更为重要，这主要因为SCADA系统监控的过程大多具有地理分散的特点，如无线通信机站系统的监控。系统优势：SCADA系统属于典型的分布式计算机应用系统，在这样的系统中，体系结构是软件系统中最本质的东西，良好的体系结构意味着普适、高效和稳定。由于体系结构是对复杂事务的一种抽象，良好的体系结构是普遍适用的，它可以高效地处理多种多样的个体需求。同时，体系结构在一定的时间内保持稳定。当需求**生变化时，程序员可以不用修改系统的体系结构。 

https://bbs.huaweicloud.com/videos/ff688537836a440ba5ef3b13a50fe052往期回顾链接第一期：驻足10分钟，轻松掌握开发全流程Link第二期：驻足5分钟，轻松掌握平台申请和项目创建~Link第三期：驻足5分钟，轻松掌握Profile在线开发~Link第四期：驻足5分钟，轻松掌握编解码插件在线开发~Link第五期：驻足5分钟，轻松掌握设备在线调试~Link第六期：驻足5分钟，轻松掌握应用调试指导~Link第七期：驻足5分钟，轻松掌握应用订阅功能调试指导~Link

本文旨在帮助基于使用Lierda NB86-G模组进行OpenCPU开发的用户，文章概述了以OpenCPU方案开发OneLight示例，以Lierda EVK上LED为硬件实现设备端开发到平台应用创建以及设备调试从打开一个灯开始。为了直观的表示此例程，此例程就取名OneLight。1、方案概述以OpenCPU的方案开发OneLight示例，设备硬件采用Lierda NB86-G EVK，设备定时上报光照强度至IoT平台，IoT平台下发开关灯的指令来控制EVK的LED。 NB86-G EVK操作方法请参考《Lierda NB86-EVK操作使用手册》文档NB86-G EVK参考资料下载地址：Lierda NB86 EVK相关资料2、测试结果2.1.        数据上报2.1.1.设备端log 2.1.2平台端 2.2.        命令下发2.2.1平台端 2.2.2设备端 3、IoT平台应用创建及设备注册见附件文档4、测试固件及代码分析见附件固件和文档5、编解码插件及Profile见附件附件1：OneLight Profile附件2：OneLight测试固件附件3：OneLight编解码插件附件4：OneLight说明文档

如何从iot平台上下载队友上传的数据呢

发送一次之后就没反应了，调试时也是第二次就卡住了，编译烧录都成功。如果不往平台上发送只是在用LCD显示倒是没问题、以下是代码。char Wendu_send[4]={0};VOID data_collection_task(VOID){    UINT32 uwRet = LOS_OK;     ds18b20_init();    while (1){     float t;     t = ds18b20_read();     //printf("温度 = %05.1f", t);     sprintf(Wendu_send,"%04X",(int)t);      uwRet=LOS_TaskDelay(2000);     if(uwRet !=LOS_OK)     return;} }VOID data_report_task(VOID){UINT32 uwRet = LOS_OK;UINT32 msglen = 0;    UINT32 msgid;    while(1){msgid=01;sprintf(s_report_buf,"%02d", msgid);memcpy(s_report_buf + 2, &Wendu_send, sizeof(Wendu_send));msglen = sizeof(Wendu_send); los_nb_report((const char*)(&s_report_buf), (msglen+2) / 2); //发送数据到平台 memset(s_report_buf, 0, sizeof(s_report_buf));uwRet=LOS_TaskDelay(5000);if(uwRet !=LOS_OK)return;}}这是代码，用其他传感器明明都可以正常发送的。。

各位大大，Iot-platform 和 OceanConnect 分别是干嘛的？在测试Iot基础版时 ， 这2个平台都用到了 ， 这两平台间有啥联系么？   

hi ， 今天在Iot基础版的基础上 ， 调用了 AgentLiteDemo ，报了如下的错使用的Iot基础版提供的IP信息 ， 我是参考 https://bbs.huaweicloud.com/forum/thread-13160-1-1.html 弄的 ，用的Idea工具麻烦各位大大指点一下

使用Iot基础版，调用 初始化资源的方法时，报了如下错误：麻烦各位大大帮忙解答下~

1、问题描述部分客户出现发送命令或数据时出现 error 的现象，或者在做高低温测试的时候发AT指令出现返回error 的现象，一般出现这样的问题先确定是否为波特率不匹配造成的。确认 MCU 的实际波特率。 对比读取的模组波特率范围是否能够匹配。例如：某系统板 MCU 波特率为 9506，而 NB 模组的波特率范围为 9520-9930。因此可能 导致发送命令或数据时出现 error。2、解决办法方法一：可将 MCU 的波特率调整至合适的范围之间。方法二：可根据 MCU 的波特率将 NB 模组调整至合适的波特率范围。（利用AT指令个更改模组AT串口的波特率容限：AT+NATSPEED=9600,30,1,2,1,0,0）模组波特率容限对照表如下表：注意：鉴于海思 Hi2115 芯片对串口波特率的容限范围较小，我们强烈建议用户在 设计应用时使用外部 32768 的晶振作为 MCU 与 NB-IoT 模组通信的串口时钟源，保证 MCU 串口波特率在较大范围内的准确性。

请教各位大大 ， 试过在postman 调用鉴权成功么？？ 调用情况如下却发现如下情况：

2019年6月3日，华为云技术沙龙.边缘计算专场来到了江南名城杭州，尽管当天天气炎热，气温高达34度，但仍有近300+开发者和合作伙伴冒着酷暑前来，挤满了杭州十六铺咖啡还算不小的会场，还未到活动的正式开始时间，会场已经呈现了爆满之势，这在技术沙龙活动中实属罕见。华为云IEF成就边缘开发者的“不凡”在有着海量数据的未来，将有数十亿部设备连接到互联网，因此更快更可靠的数据处理将变得至关重要。近年来，云计算的整合与集中化性质被证明具有成本效益和灵活性，但物联网和移动计算的兴起所带来的海量的数据处理和传输要求却给网络带宽带来了很大的压力。最终，并不是所有的智能设备都能够通过利用云计算来运行。而且在某些情况下，这种数据的传输也应该被避免。由此，边缘计算应运而生。边缘计算实现数据按需分流到近端侧的边缘，并可以减少端云之间数据来回传输，也为一些实时性需求提供了一定的支持，因此，边缘计算被认为是未来最重要的技术趋势之一，在世界知名咨询公司Gartner公布的2019十大技术趋势中，边缘计算赫然在列。然而，当开发者想要进行边缘计算相关应用开发时，却发现并没有一个合适的开发平台可以适用，或者说即使有，也只是一个孤立的开发平台，无法实现云边协同，而云边系统对于边缘计算非常重要。因为边缘计算实质上是云计算架构的补充或延伸，连上云的边缘才有强大的能力和灵活性，连上边的云才有数据引流上云和应用服务落地点。针对此种情况，华为云推出智能边缘平台服务IEF，以华为云作为智能数据底座、基础AI平台，通过智能边缘平台服务IEF将智能推向边缘，从而为开发者打造了一个轻松进行边缘应用开发的平台。华为云IEF服务产品经理Ryan在沙龙上介绍说，IEF原生支持Kubernetes与Docker生态，着力于构建云原生的边缘计算，其在边缘场景下应用治理、Serverless等做了大量的探索，具有轻量级的边缘函数和容器引擎以及边云一致的生态。IEF最小可支持运行在128M内存的边缘设备上，满足大部分客户的应用场景。最后，IEF可以将华为云AI能力、大数据能力延伸到边缘，并与云上服务完成数据协同、任务协同、管理协同、安全协同，实现真正意义上的”边云协同”。IEF正在通过第三方边缘硬件认证和边缘应用市场等计划促进边缘计算生态系统，开发者可以在边缘应用市场发布优质应用，并通过”许可”的方给客户使用。同时，系统集成商SI根据需要项目的要求选择边缘应用快速创建边云协同解决方案，无论对应用开发者还是系统集成商都是双赢的局面。同时，脱胎于IEF服务的KubeEdge开源项目是全球首个加入CNCF社区的智能边缘项目 ，已开放给广大开发者，帮助开发者可根据自身需求进行定制开发。为了帮助开发者能够更直观的感受IEF为开发者带来的便利，Ryan还在沙龙现场演示了如何基于华为云IEF服务和人脸识别服务结合快速构建边云协同的解决方案，解决在园区视频监控场景中低时延、大数据量的痛点。华为MEC助5G开发者打造“不凡”众所周知，5G是除了边缘计算以外最为令人兴奋的技术，5G具有颠覆社会的能力，能够使全行业数字化转型成为可能。从VR/AR、蜂窝无人机到无线机器人、车联网、智慧医疗都离不开5G，5G将会率先满足4G流量难以承载的高清视频、VR/AR等高流量业务。智能安防、物联网的部署节奏也将随后跟上，无人驾驶等低时延的业务需求也将稳步推进，工业机器人等实时性要求较高的低时延的应用场景的标准化也在逐步实行。5G时代，开发者需要围绕着5G的应用场景，着力发展相关开发技能，就目前发展阶段而言，首当其冲的是VR/AR、智能安防等相关的开发技术。然而，开发者进行VR/AR、智能安防等相关领域开发时，实际上面临着很多困难和挑战，例如，软硬件市场混乱，让开发者们无所适从。因为没有统一的标准，所以各家都在构筑自己的开发平台等。这些因素很大程度上阻碍了5G领域技术的创新和生态发展。而华为5G MEC的出现，则为开发者开发5G相关应用提供了一个非常完善和成熟的解决方案。华为MEC产品解决方案高级工程师徐建鹏表示，华为5G MEC具有联接+计算最佳匹配的智简边缘能力，可以提供分流策略自动化、QoS保障、计费等网络能力开放，满足丰富的应用场景。它还具有超强计算能力、极致转发能力、兼容虚拟机和容器的异构平台，集成多种计算芯片，支持GPU加速，应对5G时代流量激增的处理需求等功能。华为5G MEC支持虚机容器生态，支持App、**和深度API集成，也支持远程分层运维以及DNS、LB、NAT等协议的一站式服务预集成。开发者通过华为的MEC平台API接口，可以结合位置信息、QoS信息优化用户体验，并开放自身服务，反哺边缘生态。这些都为开发者开发“不凡”的5G应用提供了有力的支持。目前，华为MEC已经成功应用于北京世园会无人机VR直播、宁波镇海炼化智慧工厂、江阴智慧码头等项目，验证了华为5G MEC平台的成熟度与便利性，及赋予开发者的强大能力。在沙龙现场，Insta360产品技术总监王鹏、中盛益华产品开发总监王升旭还为到场的数百名开发者分别演示了如何基于5G MEC快速构建Cloud AR/VR以及智能安防应用。令现场的开发者大呼过瘾。华为技术专家和第三方合作专家的精彩演讲吸引了众多开发者聚精会神的聆听，现场的互动环节也热烈非常，众多开发者争相提问，演讲讲师从容作答，现场气氛一度达到高潮。2019华为开发者大赛全栈开放，引爆无限可能华为开发者大赛是华为公司最顶级的开发者大赛，是华为公司面向全球开发者的创新大赛，为您提供一个耕耘梦想、实践创新的平台，鼓励更多开发者基于华为平台和能力进行产品与方案的创新，并获得商业推广。从创意落地到应用实践，尽在华为开发者大赛！华为开发者大赛边缘计算赛道-奖项设置参赛团队有机会和业界优秀行业伙伴交流碰撞、联合创新，从商业和影响力方面获得收益，获奖作品将直接入选华为智能边缘应用市场，获华为云销售&渠道推广机会、线上联合促销等机会。高校或个人获奖团队开发者将获得华为公司实习或合适岗位推荐。获奖者将获得上海华为全联接大会HC2019 Day3门票、往返机票，并担任后续开发者活动的嘉宾，入决赛者将获得在东莞华为松山湖欧洲小镇决赛路演免费往返机票；商业落地一等奖作品将入驻：2019年华为全联接大会、边缘计算产业联盟峰会、工业互联网产业联盟峰会；IEF智能边缘平台参赛团队及获奖作品其他权益：获奖者将获得IEF智能边缘平台免费使用权限；一等奖，12个月；二等奖，8个月；三等奖，4个月；报名地址：https://developer.huaweicloud.com/competition/competitions/1000000102/introduction