lando的论坛回复_云社区-华为云

首先对华为IOT平台的工作人员道声感谢，感谢你们日夜兼程的付出，换来我们日月如梭的呈现。总之，非常感谢你们为物联网事业做出的贡献。从2020年伊始，使用华为IOT开发中心进行产品开发，一下便是整个开发过程中遇到的种种问题。注：开发仍在持续中，接下来进入第三版重构阶段。1.平台对于产品的部分做的不完善。产品的组成有很多个维度。不同的集成硬件型号，固件版本，软件版本，协议版本，外形版本，批次都是可以随意组合成某个型号的。而现阶段平台的产品却没有体现出这些来。而平台上根据模板创建之类的对于开发者而言意义不大，而自定义中填写的所属行业和设备类型更是在接下来的开发中无意义。之所以在平台级添加相关维度的信息，是因为在实际应用中能够快速定位某个产品，而且各个维度之间应该有子从关系。比如型号A是由集成硬件1.3，软件版本0.2，外形版本1.1组成的。而型号A-1是在型号A的基础上对软件版本进行了调整。型号A-1实际上是在型号A的基础上进行扩展的，但是为两个不同的型号。平台也应该给两个不同的型号生成映射ID，这样服务端在调用API添加设备时可以使用映射ID将设备添加至不同的型号中。而批次又属于型号的子集，因为在实际生产中，一个型号可能会找许多家工厂代工，因此生成出来的设备会因为工厂的工艺标准参差不齐，而且每个批次的测试，使用的时间也不一样。如果某个批次的合格率未达标，还需要整个批次返厂。所以绝对不能将多个批次的设备放到一个集合中。2.产品与产品之间没有联系如果我想把产品A中的设备导入到产品B中，该怎么办呢。其实这种情况很容易发生。比如一批设备要测试，一定要将设备注册到平台上。如果测试成功，就要将这批设备从测试环境切换到正式环境上。但是现在平台没有这方面的操作。比如从产品A中的设备导入到产品B，或者说从开发中心导入到正式使用的设备接入。甚至开发中心与设备接入之间做的也不友好，我尝试将开发中心的profile文件导出再导入到设备接入中，支持的还不错。但是开发中心的编解码插件导出再导入到设备接入中时，报错。所以平台应该考虑考虑开发中心与设备接入之间应该有个非常好的兼容性。3.编解码插件开发啰里啰唆为什么就不能messageId，mid，errcode一起创建出来，使得我每次创建一个命令编解码时，要选3次。而且消息不支持复制，比如消息A与消息B内容基本一致，那为什么就不能消息A复制为副本，在消息A副本的基础上修改消息B。4.在开启软件升级功能后，自动创建出一大堆服务出来。这个之前的版本本没有，后来不知道为什么加了一个这个。其实这个应该在用户勾选开启软件升级时弹窗询问用户，是否添加所属服务。说实话，在实际OTA升级中，自己需要的功能可以自己创建，平台真的没必要创建这么一大串东西出来。5.设备管理中不够完善设备管理不支持按产品型号进行筛选，也不支持批量操作。使用API导入设备时，设备名称为空。因此在调试页面中选择设备下拉框显示不正常。其实设备名称可以用IMEI标识符代替的。6.PCP协议过于啰嗦在开发软件升级过程中，最让我印象深刻的就是那16比特设备版本号。不仅长，还总是传来传去的，真的没有必要。像这种协议最好是越简单越好。你添加一个版本号的传输，那在设备侧就要解析一次。如果对于要求低的设备还好，但是对于要求低功耗低成本的话，多一次处理，就少一分性能。还有一些结果码也是如此。其实可以再开发出一个PCP2.0协议出来，较以前的PCP而言最大的特点就是精简，把许多中间流程都省略掉。7.关于设备健康的问题思来想去，我觉得设备健康评分或者说设备健康检测由平台做是最合理的。因为平台能获取到的信息一定大于服务端能获取到的信息。平台不仅可以获取到指令下发的成功率，还可以获取到设备连接情况，甚至可以拿到运营商基站的实时信息，或者维护信息。来反映设备当前的情况。设备健康检测其实是非常有用的，不仅可以推送至服务侧进行预警，甚至在设备出现问题时。开发者可以第一时间排除一个检查的环节。最后，我想给华为IOT平台一些建议。授人以鱼，不如授之以渔。你们总是喜欢去收集问题，然后在你们的角度筛选问题。为什么你们不真正的自己搞一个产品呢？比如我开发的这款产品就是以款以STM32为MCU，特点是低成本，低功耗，小型化。以上说的问题只是冰山一角，还有很多问题。要么是太小，要么是偶发不宜捕捉，要么就是不影响流程但仍然是问题，要么就是根本就无法描述的怪问题。这些其实却是很多的，如果根据墨菲定律，这些小问题会在某个应用场景，某个时间节点，突然升级为大问题，或者引发蝴蝶效应。只有你们自己从设计，验证，开发，测试，模型，量产，测试，商用这一整套流程走下来，你们才真正知道并理解问题出在哪里。如果你不成为那类人，你就不会很好的服务那类人，因为你不知道那类人需要什么。为什么物联网已经发展了十几年了，现在仍然发展的不是很好。相比之下，他的兄弟互联网犹如井喷式的发展。其实是因为物联网现在还没有一个生态形成，物联网现在所以的条件都具备了，但是没有一口锅把所有的材料炖下。说到物联网生态，就不得不提arduino的生态。可以说arduino的生态已经是相当不错的了，它强大的库可以找到任何你想用的代码，还带示例。但是现在物联网仍然发展的不是很好，我觉得主要的原因是因为arduino虽然开发方便，但是实际投入商用却很难。如果是使用库还算是可用。但是想改库的话门槛还是不小的。而且arduino不太适合那些低成本低功耗小型化的项目，集成起来的难度大。要说集成难度小的还是属STM32系列，但是开发难度却很大。毕竟开发这个要C，深一点的话还得熟悉汇编。而且现阶段STM32没有生态。如果我要集成移远BC35，我要自己写驱动。所以整个物联网界无生态可言。其实很多人也注意到这一点了，并且慢慢开始构建。比如PlatformIO，这个软件干的就是这件事。这个软件类似maven一样，可以快速构建项目，还可以帮你下载驱动。而一些厂家的驱动也慢慢的添加到PlatformIO上来。但是现在还是属于发展阶段，并且没有中国镜像，下载和构建驱动极慢。所以我觉得，华为IOT平台如果想在中国乃至世界站稳脚跟，必须要建立一个物联网生态出来。1.要有类似PlatformIO这样的一个工具，相当于帮开发者造梯子。减少开发者集成的难度。2.或者创建一门低门槛物联网语言。最好是java或者类java的语言（因为现在java开发者的数量实在是太多了，这使得让一部分开发者可以快速转移到物联网上）。如果是java，可以使用在MCU中嵌入改造过的虚拟机。而直接用java开发过的文件，在编译过程中对代码进行优化，把优化并精简过的二进制文件烧录到设备中。如果是类java，在java的基础上进行一些内存方面的改动，保留java的开发风格。去掉虚拟机关键，使得开发文件编译后转为二进制文件，烧录到设备中。3.与指定元器件或者模组厂商合作，给他们指定标准。如果硬件能像拼乐高一样，快速集成为一个产品，那对于物联网来说一定是件幸事。并且成立一个2小时快速反应的客服机制，由平台主导解决问题。要知道用开发者去解决一个物联网问题有多难。4.开发者的开发成本问题，如果对比互联网而言，物联网的开发成本实在是太高了，什么开发板模组模块都要买。而且我不知道为什么华为不去和正点原子或者野火这些做开发板的厂家合作出教程。应该多借助他们的影响力来推进IOT平台的发展，而选择一个叫小熊派的。小熊派真可谓是行业黑心，一个开发板卖那么贵（正点原子虽然卖的也不便宜，但是有便宜的核心板或者MINI，不超过100块钱）。别以为所有的开发者都可以申请公司采购，大部分开发者都是穷人。我当初为了学NBIOT没舍得买小熊派，而使用树莓派加BC35G做的实验。平台把学习成本提这么高，这一点一定要考虑考虑。谁掌握了全域生态，谁就掌握了未来。之所以与华为IOT平台说这个，是因为我觉得建立生态这件事，必须要一个举足轻重的大公司来搞。小公司可以搭建一个IOT平台，但是却无法创建一个生态。并且既然要搞这个，为何不搞一些不一样的。我们领导常问我为什么不用阿里云IOT而用华为IOT，小优点我讲的一堆。但实际上我发现，这两个平台一样都没什么特点。此文章没做校对，如果遇上GP不通的地方，请多担待。最后祝我今天生日快乐！