IoT-For-Beginners 实战作业让设备对水果分类结果做出响应IoT Hub 遥测与执行器控制【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners本文是 Microsoft IoT-For-Beginners 课程《从物联网设备检查水果质量》4-manufacturing/lessons/2-check-fruit-from-device配套作业《响应分类结果》的深度技术指南。设备通过 Custom Vision 完成图像分类后会拿到每个标签如ripe/unripe的概率值——本作业的核心是让设备利用这些预测结果做点什么把数据上送到 IoT Hub 供云端系统处理、直接驱动执行器如检测到未熟水果时点亮 LED或将两者结合形成闭环。读完本文你将掌握在 PythonRaspberry Pi / 虚拟设备与 CWio Terminal两套代码栈中实现预测结果 → 业务动作的完整实战方案。作业背景预测值就是设备的决策输入在本课正文 README.md 中你已经完成了三件事给设备接上相机传感器采集图像、在 Custom Vision 门户发布分类器迭代、然后从设备端调用预测 API 拿到结果。以仓库中的示例代码为例Python 端的分类输出形如ripe: 56.84% unripe: 43.16%Wio Terminal 端通过classifyImage函数在串口监视器输出同样的内容。这些概率就是本作业的原材料——作业要求你为设备新增响应逻辑让分类结果不再只是终端里的一行打印而是真正驱动业务行为。从实现层面看设备在调用分类器之后已经握有完整的预测数据。以 code-classify/pi/fruit-quality-detector/app.py 为例results.predictions中每个prediction都携带tag_name标签名与probability01 的浮点概率Wio Terminal 的 code-classify/wio-terminal/fruit-quality-detector/src/main.cpp 则通过 ArduinoJson 解析 REST 响应的predictions数组同样拿到tagName与probability。你的响应逻辑就建立在解析这两个字段的基础之上。三种响应方案作业的技术路径作业给出了三条明确的技术路径可以单选也可以组合向 IoT Hub 发送数据把预测结果作为遥测消息上送到云端供其他系统继续处理控制执行器例如当预测为unripe时点亮 LED直接在现场给出物理反馈组合方案闭环设备把预测数据发送到 IoT Hub由一段无服务器代码如 Azure Functions判定水果是否成熟再把控制命令回传给设备驱动执行器。方案一将预测结果作为遥测数据发送到 IoT Hub这是最直接的响应方式——不要求设备做任何本地判断只需把预测值序列化后通过 IoT Hub 设备 SDK 上送。仓库的农场专题课程中已有完整可参考的实现模式2-farm/lessons/4-migrate-your-plant-to-the-cloud/code/virtual-device/soil-moisture-sensor/app.py 展示了标准流程import json from azure.iot.device import IoTHubDeviceClient, Message, MethodResponse connection_string connection_string device_client IoTHubDeviceClient.create_from_connection_string(connection_string) print(Connecting) device_client.connect() print(Connected) # ... 读取传感器 / 获取分类结果 ... message Message(json.dumps({ soil_moisture: soil_moisture })) device_client.send_message(message)套用到本作业只需把soil_moisture换成分类结果即可例如构造如下消息负载message Message(json.dumps({ tag: prediction.tag_name, probability: prediction.probability })) device_client.send_message(message)Wio Terminal 端则使用IoTHubDeviceClient的 C 版本azure-iot-sdk-c实现send_message调用将 JSON 序列化的预测结果发送到 IoT Hub。云端既可以是简单的数据收集存储也可以是后续课程中介绍的 Azure Functions 事件处理。 需要说明连接 IoT Hub 所需的connection_string来自你在 Azure 门户中创建的 IoT Hub 设备注册不同硬件平台Raspberry Pi / 虚拟设备 / Wio Terminal的 SDK 包与初始化方式不同但序列化预测结果 → 调用 send_message这一响应逻辑是通用的。方案二直接驱动执行器如果设备端希望在本地即时反应可以在解析出预测结果后直接控制执行器。作业给出的典型示例是当水果被判定为未熟unripe时点亮 LED。逻辑骨架如下Python 伪代码可嵌入 app.py 的预测打印循环之后for prediction in results.predictions: print(f{prediction.tag_name}:\t{prediction.probability * 100:.2f}%) if prediction.tag_name unripe and prediction.probability 0.5: led.on() # 点亮 LED提示该果实未熟 else: led.off()这里有两个值得注意的设计要点阈值判定分类器会为所有标签返回概率且所有概率之和为 1。因此该水果是否为未熟的判定通常取概率最高或超过 0.5的标签或为每个标签单独设置业务阈值响应的一致性评分标准中卓越Exemplary级别明确要求响应必须对相同取值的预测稳定生效consistently works with predictions of the same value也就是说同样的预测输入应始终触发同样的执行器动作不能出现偶发的不响应或误动作。这提示你在实现时要避免竞态条件例如在 Wio Terminal 的loop()中按下按钮后调用classifyImage应确保预测循环结束后再统一驱动执行器而不是在每个标签概率更新时各自触发动作。方案三IoT Hub 无服务器代码 命令回传闭环组合方案把前两者串成完整链路作业描述为设备发送预测数据到 IoT Hub → 无服务器代码serverless code判定水果是否成熟 → 向设备回传命令 → 设备收到命令后控制执行器。这条路径在仓库中有成熟的参考骨架。云端侧可以复用农场专题中IoT Hub 直连方法direct method的通信模式——设备端通过on_method_request_received注册处理方法云端调用直连方法时设备执行对应动作并回执状态码def handle_method_request(request): print(Direct method received - , request.name) if request.name relay_on: relay.on() elif request.name relay_off: relay.off() method_response MethodResponse.create_from_method_request(request, 200) device_client.send_method_response(method_response) device_client.on_method_request_received handle_method_request完整示例见 2-farm/lessons/4-migrate-your-plant-to-the-cloud/code/virtual-device/soil-moisture-sensor/app.py。在本作业场景中你可以把relay_on/relay_off换成点亮/熄灭 LED之类的设备动作设备上送{ tag: unripe, probability: 0.87 }后Azure Functions 等无服务器代码解析消息并判断成熟度若判定为未熟则调用 IoT Hub 直连方法下发命令设备收到命令后点亮 LED。这样做的好处是判断逻辑集中在云端设备端保持只采集、只执行的简单职责业务规则变更时无需重新烧录设备固件。评分标准逐项拆解从达到要求到卓越作业自带的评分表Rubric界定了三个层级是检验实现质量的直接标尺标准卓越Exemplary合格Adequate需改进Needs Improvement对预测结果做出响应成功实现了一种响应且对相同取值的预测能稳定生效实现了响应但不依赖预测结果例如仅向 IoT Hub 发送原始数据无法编写程序让设备对预测结果做出响应三档之间的本质差异在于响应是否真正由预测值驱动合格档代码确实调用了 IoT Hub 或执行器但动作与预测值无关——例如无条件把图像原始字节上送 IoT Hub或无论预测结果如何都点亮 LED。这类实现完成了通信但没有完成响应卓越档动作严格依赖预测值。例如只有unripe概率超过阈值才点亮 LED或上送的消息负载中包含标签与概率字段云端据此做出差异化处理。同时相同预测值反复出现时设备每次都应稳定触发相同动作——这正是实际产线场景对一致性的最低要求需改进档预测循环只打印不动作或代码存在编译/运行错误导致无法执行。对照 code-classify/wio-terminal/fruit-quality-detector/src/main.cpp 可以看到预测循环内部已经在逐个标签读取tagName与probability——卓越档的响应逻辑天然应该挂在这个循环里而不是循环之外。落地与验证建议先确认分类链路通畅按 single-board-computer-classify-image.md 或 wio-terminal-classify-image.md 跑通图像采集与预测打印再叠加响应逻辑避免一次排查两个问题域响应代码紧贴预测循环Python 端写在for prediction in results.predictions循环内C 端写在classifyImage的预测解析之后、httpClient.end()之前确保缓冲区释放前完成动作决策验证稳定性连续用同一张水果图像或同一场景触发多次预测确认每次触发相同的执行器动作 / 发送相同的遥测负载满足卓越档的一致性要求组合方案注意消息协议一致性设备发送的 JSON 字段名如tag、probability需与云端无服务器代码解析的字段名严格一致直连方法名如led_on/led_off也需在设备端handle_method_request与云端调用方之间统一。完成本作业后你的设备将不再是一个只会打印概率的相机而是一个具备现场决策能力的 IoT 节点——无论是向云端上报、本地驱动执行器还是接受云端命令形成闭环这套分类结果 → 业务响应的模式正是智能分拣、质量检测等制造业 IoT 应用的通用骨架可直接迁移到 4-manufacturing 后续课程的真实检测场景中。【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考