-
【功能建议】IOT产品管理 已实现问题描述： 这三个点显示上感觉不是很好，如果没有创建的时候，可以提示用户创建新资源，这三个点可以省掉 [图片] 建议方案： 问题描述： 这三个点显示上感觉不是很好，如果没有创建的时候，可以提示用户创建新资源，这三个点可以省掉 [图片] 建议方案：
- 问题描述： 我在测试消息通知服务，协议为短信，订阅终端为中国电信手机号码，执行请求订阅操作后，用户收到的短信内容如下图所示，短信中的链接被拆分成为多个短信，导致用户无法点击链接确认订阅。 [图片] 建议方案：与中国电信短信发送服务联系改正。 问题描述： 我在测试消息通知服务，协议为短信，订阅终端为中国电信手机号码，执行请求订阅操作后，用户收到的短信内容如下图所示，短信中的链接被拆分成为多个短信，导致用户无法点击链接确认订阅。 [图片] 建议方案：与中国电信短信发送服务联系改正。
- 问题描述： 设备接入-产品-修改命令-修改参数后，确认按钮无效 点击关闭和取消也无反应，不能关闭修改窗口 建议方案： 修改此功能存在的问题 问题描述： 设备接入-产品-修改命令-修改参数后，确认按钮无效 点击关闭和取消也无反应，不能关闭修改窗口 建议方案： 修改此功能存在的问题
- 问题描述： 网址：https://console.huaweicloud.com/iotdm/?agencyId=08e8a7ad4a00f2d41f5bc00a59e8fe52®ion=cn-north-4&locale=zh-cn#/dm-portal/rule/newDataForward?appId=6ea94db6997541399e7ed73700004bcf&appName=DefaultApp_hw03426922_iot 如图： [图片] 建议方案： 去掉多余句号。 问题描述： 网址：https://console.huaweicloud.com/iotdm/?agencyId=08e8a7ad4a00f2d41f5bc00a59e8fe52®ion=cn-north-4&locale=zh-cn#/dm-portal/rule/newDataForward?appId=6ea94db6997541399e7ed73700004bcf&appName=DefaultApp_hw03426922_iot 如图： [图片] 建议方案： 去掉多余句号。
- [图片] 看了HDC 2020 关于华为IoT方案的介绍，感觉这个方案只适用于目前智能设备数量在家庭中占比还比较小的情况。这种基于类似列表式的对各个设备平行管理（见上方截图）在家中设备数量比较少的时候还可以维持效率，想象一下之后如果智能设备占比提高到一个很大的数量，甚至每个水杯每个盘子都成为智能设备之后（这并不是不可能，比如智能化水杯检测温度、液体成分等等），一个家庭中可能存在上百个甚至数百个智能设备，此时这种列表式的管理将会变得极为低效，即使提供搜索功能，也并不能很好的解决问题，因为这可能需要手动设置各个设备的索引等等，对用户很不友好。例如用户点开客厅的选项卡，里面可能有好几十个设备，这就非常麻烦。同时，每个设备接入时都需要一些设定例如输入所在位置等也是很不方便的，且很粗略。仅仅像上图以静态物理空间来划分设备只对那些移动相对较少的设备有效，像之前提到的可能出现的智能水杯、盘子这类可能频繁移动的，就很难按照物理空间来归类。提出这些仅仅是冰山一角，个人认为在这种超大量设备的场景需要一种彻底的新的智能设备管理方案，仅仅对目前这种列表式的管理方案进行修修补补可能不能很好的解决问题。 现在有一些空间建模的技术，不知道能否帮助解决设备管理的问题。目前华为提供了设备间互联的方案，并且看起来不错。但是这只是设备之间的互联，但并未与应用场景发生互联！可以通过设备之间的互联结合室内空间数字建模，形成一种基于场景的动态的设备互联，从而可能催生出更多方便快捷的应用。例如如果可以用某些设备的功能，对用户的室内空间进行大致的数字建模（如手机的拍摄，扫地机器人搭载摄像头拍摄以及雷达感知，每次扫地都可以更新建模），之后新购入的智能设备可以自动识别出在用户家庭中的定位并接入（不仅仅指物理空间的定位，而且物理空间的定位精确度也并不一定是最重要的，个人感觉是从增强用户体验出发的定位），这就使得超大数量IoT的第一步---接入 变得顺畅，解放用户自己手动设置大量设备的烦恼。然后是管理。可以提供一个3D可视化界面，让用户直接对自己的室内空间模型进行交互，会提高不少效率。但这仍然不能彻底解决设备过多带来的繁杂。这可能需要华为的工程师们来进一步考虑了。希望产品可以越来越好！ 上述方案是很naive的，并不是说华为要按这个做，只是想表达当超大量设备接入后，需要新的更好的IoT管理方案，虽然现有方案在当前设备数量较少的情况下还是适用的，但个人认为在搭建底层环境时，可能需要更加general一些的解决方案，而不是现在搞一个够用的，过两年发现不够用的时候措手不及。 [图片] 看了HDC 2020 关于华为IoT方案的介绍，感觉这个方案只适用于目前智能设备数量在家庭中占比还比较小的情况。这种基于类似列表式的对各个设备平行管理（见上方截图）在家中设备数量比较少的时候还可以维持效率，想象一下之后如果智能设备占比提高到一个很大的数量，甚至每个水杯每个盘子都成为智能设备之后（这并不是不可能，比如智能化水杯检测温度、液体成分等等），一个家庭中可能存在上百个甚至数百个智能设备，此时这种列表式的管理将会变得极为低效，即使提供搜索功能，也并不能很好的解决问题，因为这可能需要手动设置各个设备的索引等等，对用户很不友好。例如用户点开客厅的选项卡，里面可能有好几十个设备，这就非常麻烦。同时，每个设备接入时都需要一些设定例如输入所在位置等也是很不方便的，且很粗略。仅仅像上图以静态物理空间来划分设备只对那些移动相对较少的设备有效，像之前提到的可能出现的智能水杯、盘子这类可能频繁移动的，就很难按照物理空间来归类。提出这些仅仅是冰山一角，个人认为在这种超大量设备的场景需要一种彻底的新的智能设备管理方案，仅仅对目前这种列表式的管理方案进行修修补补可能不能很好的解决问题。 现在有一些空间建模的技术，不知道能否帮助解决设备管理的问题。目前华为提供了设备间互联的方案，并且看起来不错。但是这只是设备之间的互联，但并未与应用场景发生互联！可以通过设备之间的互联结合室内空间数字建模，形成一种基于场景的动态的设备互联，从而可能催生出更多方便快捷的应用。例如如果可以用某些设备的功能，对用户的室内空间进行大致的数字建模（如手机的拍摄，扫地机器人搭载摄像头拍摄以及雷达感知，每次扫地都可以更新建模），之后新购入的智能设备可以自动识别出在用户家庭中的定位并接入（不仅仅指物理空间的定位，而且物理空间的定位精确度也并不一定是最重要的，个人感觉是从增强用户体验出发的定位），这就使得超大数量IoT的第一步---接入 变得顺畅，解放用户自己手动设置大量设备的烦恼。然后是管理。可以提供一个3D可视化界面，让用户直接对自己的室内空间模型进行交互，会提高不少效率。但这仍然不能彻底解决设备过多带来的繁杂。这可能需要华为的工程师们来进一步考虑了。希望产品可以越来越好！ 上述方案是很naive的，并不是说华为要按这个做，只是想表达当超大量设备接入后，需要新的更好的IoT管理方案，虽然现有方案在当前设备数量较少的情况下还是适用的，但个人认为在搭建底层环境时，可能需要更加general一些的解决方案，而不是现在搞一个够用的，过两年发现不够用的时候措手不及。
- 问题描述：早起在研究azure和华为云物联网方面差异时在设备管理IoTDM云服务中发现有用的架构图，后来发现点击设备管理 IoTDM就跳转到设备接入服务了，再也找不到想要的架构图设备接入服务， 建议方案：建议要么将IoTDm删除，要么恢复或者合并IoTDM文档设备接入 问题描述：早起在研究azure和华为云物联网方面差异时在设备管理IoTDM云服务中发现有用的架构图，后来发现点击设备管理 IoTDM就跳转到设备接入服务了，再也找不到想要的架构图设备接入服务， 建议方案：建议要么将IoTDm删除，要么恢复或者合并IoTDM文档设备接入
- 问题描述： 定义了IoT接入设备后，有时候会出现想知道移动设备到哪儿去了这一个场景。比如智能物流，车到哪里了。又比如想知道安装在华为大学传达室门口的那几个鲜花养的好不好。所以希望结合IoT设备的GPS传感器的定位属性，加上设备安装位置的定义属性，能够正向或者反向查找到设备。 建议方案： 云端编解码器支持GPS属性的字段定义 支持在云端对设备的位置进行定义（如有GPS属性可取GPS的位置，如没有GPS的位置，可让用户自行输入或者导入位置信息，位置信息包含 经度，维度，精度等——可参考微信公共号地理位置消息的相关字段）。 提供基于地图的查询功能，可以根据选择的设备，查找设备的位置，并在地图上显示其位置和状态（在线离线故障等），也可以通过输入位置+范围，查找在这个位置范围内的设备（或者设备清单）。点击地图内的设备图片，可以查看设备状态或者下发命令给设备。 如果再引申一下，可以考虑由客户自定义地图（如室内平面图等），让客户在自定义地图内定义设备的具体位置。然后根据地图来展示用户设备的全貌信息，以及点击自定义地图内的设备图片，查看设备状态或者下发命令给设备。 问题描述： 定义了IoT接入设备后，有时候会出现想知道移动设备到哪儿去了这一个场景。比如智能物流，车到哪里了。又比如想知道安装在华为大学传达室门口的那几个鲜花养的好不好。所以希望结合IoT设备的GPS传感器的定位属性，加上设备安装位置的定义属性，能够正向或者反向查找到设备。 建议方案： 云端编解码器支持GPS属性的字段定义 支持在云端对设备的位置进行定义（如有GPS属性可取GPS的位置，如没有GPS的位置，可让用户自行输入或者导入位置信息，位置信息包含 经度，维度，精度等——可参考微信公共号地理位置消息的相关字段）。 提供基于地图的查询功能，可以根据选择的设备，查找设备的位置，并在地图上显示其位置和状态（在线离线故障等），也可以通过输入位置+范围，查找在这个位置范围内的设备（或者设备清单）。点击地图内的设备图片，可以查看设备状态或者下发命令给设备。 如果再引申一下，可以考虑由客户自定义地图（如室内平面图等），让客户在自定义地图内定义设备的具体位置。然后根据地图来展示用户设备的全貌信息，以及点击自定义地图内的设备图片，查看设备状态或者下发命令给设备。
-
【用户体验】产品文档链接问题 未采纳问题描述： 在IoTDM产品最下方查看的用户指南和开发指南，其实是IoTDA的。 只有在帮助中心才能搜到IoTDM产品指南。 [图片] [图片] 建议方案： 在IoTDM产品最下方查看的用户指南和开发指南，链接入正确的IoTDM的产品文档。 问题描述： 在IoTDM产品最下方查看的用户指南和开发指南，其实是IoTDA的。 只有在帮助中心才能搜到IoTDM产品指南。 [图片] [图片] 建议方案： 在IoTDM产品最下方查看的用户指南和开发指南，链接入正确的IoTDM的产品文档。
- 问题描述： 目前小熊派连接云端常常出现设备早已离线，但是云端仍以为是在线的情况。 经过询问客服，说现在是以下原则: NB-IoT设备上报数据后为状态为在线，距离上次上报数据25小时内未上报数据，会刷新状态为离线。 MQTT设备连接到平台后状态为在线，断开连接后平台1分钟内会自动刷新状态为离线。如果手动点击状态刷新按钮，则可实时刷新为离线状态 感觉目前这种情况特别不合理。特别是25小时的间隔是出自于什么考虑？完全不清楚。这样很可能设备被盗了都不知道，还以为设备在线呢。 其实完全可以通过下发命令获得响应来随时获取设备的状态，也没必要非要设置25小时。 建议方案： 取消设备25小时未上报数据的这种严重影响客户体验的规则，改为较为人性化的规则。 允许用户通过定期上报信息或命令下发的方式随时获取设备端在线状态。 允许用户针对不同的场景设置不同的探测在线的时间间隔。比如设置每隔1小时监测设备是否在线，就可提供内置的标准探测现在的服务（echotest）。 如果在一段时间内收不到设备上报信息，应允许用户设置主动从云端发起在线监测报文，以及时获取设备状态。避免造成设备故障甚至偷盗后还以为设备在线的情况， 问题描述： 目前小熊派连接云端常常出现设备早已离线，但是云端仍以为是在线的情况。 经过询问客服，说现在是以下原则: NB-IoT设备上报数据后为状态为在线，距离上次上报数据25小时内未上报数据，会刷新状态为离线。 MQTT设备连接到平台后状态为在线，断开连接后平台1分钟内会自动刷新状态为离线。如果手动点击状态刷新按钮，则可实时刷新为离线状态 感觉目前这种情况特别不合理。特别是25小时的间隔是出自于什么考虑？完全不清楚。这样很可能设备被盗了都不知道，还以为设备在线呢。 其实完全可以通过下发命令获得响应来随时获取设备的状态，也没必要非要设置25小时。 建议方案： 取消设备25小时未上报数据的这种严重影响客户体验的规则，改为较为人性化的规则。 允许用户通过定期上报信息或命令下发的方式随时获取设备端在线状态。 允许用户针对不同的场景设置不同的探测在线的时间间隔。比如设置每隔1小时监测设备是否在线，就可提供内置的标准探测现在的服务（echotest）。 如果在一段时间内收不到设备上报信息，应允许用户设置主动从云端发起在线监测报文，以及时获取设备状态。避免造成设备故障甚至偷盗后还以为设备在线的情况，
-
【功能建议】IoT的设备管理问题 未采纳问题描述： 目前IoT设备（以小熊派为例），是以 开发板+采集板（如智慧农业，智慧路灯，智慧交通等）+通讯板（如2G，HLink，NBIoT，WiFi）组成。NBIoT的设备定义取决于通讯板的IMEI号，WiFi的设备定义取决于用户自定义的号码。 这样，试想一种场景，如果一旦用户的通讯板因等损坏原因发生更换，烧录的代码如果仍然是这个设备定义逻辑，那么IoTDA端将认为这是一个全新的设备。第二种场景，如果将两个通讯板对调，而开发板和采集板都不变，那么IoTDA端认为两者的设备已经对调，但其实两套设备采集的内容并没有变。第三种场景，假设仅仅是采集板更换（比如由智慧交通板改为智慧路灯板），开发板和通讯板都不变，IoT设备认为设备并没有变。这几种场景均跟实际的场景使用不符合。 [图片] 建议方案： 建议对小熊派的设备命名规则以 开发板+采集板+通讯板三者的序列号结合定义的方式进行。这样，首先云端IoTDa可以知道设备全套是由哪些模块组成。增加对这些模块的序列号定义，支持用硬件的方式读取芯片序号（可以要求小熊派升级，内置类似的支持功能），模块的组件本身也可以在云端做定义或组合成整体设备。在设备端VSCode烧录代码时，也不必每次重新编译和重新烧录不同的代码，这样也可以解决批量烧录的问题，甚至今后的云端下发自动更新开发板的版本的问题。 问题描述： 目前IoT设备（以小熊派为例），是以 开发板+采集板（如智慧农业，智慧路灯，智慧交通等）+通讯板（如2G，HLink，NBIoT，WiFi）组成。NBIoT的设备定义取决于通讯板的IMEI号，WiFi的设备定义取决于用户自定义的号码。 这样，试想一种场景，如果一旦用户的通讯板因等损坏原因发生更换，烧录的代码如果仍然是这个设备定义逻辑，那么IoTDA端将认为这是一个全新的设备。第二种场景，如果将两个通讯板对调，而开发板和采集板都不变，那么IoTDA端认为两者的设备已经对调，但其实两套设备采集的内容并没有变。第三种场景，假设仅仅是采集板更换（比如由智慧交通板改为智慧路灯板），开发板和通讯板都不变，IoT设备认为设备并没有变。这几种场景均跟实际的场景使用不符合。 [图片] 建议方案： 建议对小熊派的设备命名规则以 开发板+采集板+通讯板三者的序列号结合定义的方式进行。这样，首先云端IoTDa可以知道设备全套是由哪些模块组成。增加对这些模块的序列号定义，支持用硬件的方式读取芯片序号（可以要求小熊派升级，内置类似的支持功能），模块的组件本身也可以在云端做定义或组合成整体设备。在设备端VSCode烧录代码时，也不必每次重新编译和重新烧录不同的代码，这样也可以解决批量烧录的问题，甚至今后的云端下发自动更新开发板的版本的问题。
- 问题描述： 在物联网平台进行模拟设备在线调测时，应用模拟器的收发信息不能按顺序显示，导致查找数据接受和命令发送信息困难。如图：10点14分接收的信息显示在10点12分和10点01分之间。 [图片][图片] 建议方案： 增加一个清空按钮，可以清除模拟器显示区域内容，便于观察。 模拟器显示区域消息按时间顺序排列，最新消息显示于最上方或最下方。 问题描述： 在物联网平台进行模拟设备在线调测时，应用模拟器的收发信息不能按顺序显示，导致查找数据接受和命令发送信息困难。如图：10点14分接收的信息显示在10点12分和10点01分之间。 [图片][图片] 建议方案： 增加一个清空按钮，可以清除模拟器显示区域内容，便于观察。 模拟器显示区域消息按时间顺序排列，最新消息显示于最上方或最下方。
- 问题描述： 在物联网平台产品模型插件进行图形化开发时，无论数据上报还是命令下发，当数据类型选择为“string”时，在长度输入框，手动输入长度值，“偏移值”会随动调整；长度输入框用右边上下调整按钮调整数据长度时，“偏移值”不能自动调整。 如图，两种方式输入长度值“3”，“偏移值”会有两种结果。 [图片][图片] 建议方案： 当“长度”值用上下调整键操作时，“偏移值”也可以自动设定。 问题描述： 在物联网平台产品模型插件进行图形化开发时，无论数据上报还是命令下发，当数据类型选择为“string”时，在长度输入框，手动输入长度值，“偏移值”会随动调整；长度输入框用右边上下调整按钮调整数据长度时，“偏移值”不能自动调整。 如图，两种方式输入长度值“3”，“偏移值”会有两种结果。 [图片][图片] 建议方案： 当“长度”值用上下调整键操作时，“偏移值”也可以自动设定。
- 问题描述： 5G智慧银行营业厅解决方案 有错别字 建议方案： [图片] 问题描述： 5G智慧银行营业厅解决方案 有错别字 建议方案： [图片]
上滑加载中
推荐直播
-
HDC深度解读系列 - Serverless与MCP融合创新，构建AI应用全新智能中枢2025/08/20 周三 16:30-18:00
张昆鹏 HCDG北京核心组代表
HDC2025期间，华为云展示了Serverless与MCP融合创新的解决方案，本期访谈直播，由华为云开发者专家(HCDE)兼华为云开发者社区组织HCDG北京核心组代表张鹏先生主持，华为云PaaS服务产品部 Serverless总监Ewen为大家深度解读华为云Serverless与MCP如何融合构建AI应用全新智能中枢
回顾中 -
关于RISC-V生态发展的思考2025/09/02 周二 17:00-18:00
中国科学院计算技术研究所副所长包云岗教授
中科院包云岗老师将在本次直播中，探讨处理器生态的关键要素及其联系，分享过去几年推动RISC-V生态建设实践过程中的经验与教训。
回顾中 -
一键搞定华为云万级资源，3步轻松管理企业成本2025/09/09 周二 15:00-16:00
阿言 华为云交易产品经理
本直播重点介绍如何一键续费万级资源，3步轻松管理成本，帮助提升日常管理效率！
回顾中
热门标签