《基于Blynk物联网平台的社区智能健康系统》
作品说明
一、背景分析与设计要求
摘要:针对疫情期间人工逐人测温耗时费力、手持测温枪存在交叉感染风险的痛点,本作品设计并制作了一台面向社区、养老院与医院的"智能健康管理终端"——魔镜。作品以掌控板 2.0 为主控,用哈仕奇 AI 摄像头识别人脸后自动启动测温,以 GY-906 免接触红外传感器获取体温、用 MAX30102 采集心率与血氧,数据经 MQTT 上传 EasyIoT 云平台,并同步写入 Blynk 虚拟引脚,手机 Blynk App 与管理中心可实时查看体征曲线;行空板端提供本地界面显示。造型上,作品用 PET 单向透视薄膜与内置平面镜构成镜面结构——未测温时它就是一面镜子,测温启动后有背光透出显示画面,把"测温"这个动作悄悄融进了照镜子的日常习惯里。
关键词:无接触测温;人脸识别;Blynk 物联网;单向透视魔镜;社区健康管理
1.1 作品背景
从 2019-nCoV 到 Delta、Omicron,新型冠状病毒肺炎的主要症状是发热、干咳、喉咙痛、头痛、乏力、鼻塞等,体温筛查始终是疫情防控的第一道关口。
在医院里,护士每天要逐床给病人测量体温。这个环节耗时、耗人,效率不高,而且做不到随时检测——一旦有患者体温异常,往往要等到下一次查房才被发现。更现实的问题是:手持测温枪需要贴近患者,对医护人员和其他病患都存在传染风险;而通常的测温方式只测手腕、额头皮肤温度,受环境影响较大。
从生理上讲,人的口腔温度最接近实际核心体温,而且相对稳定,不容易受环境因素干扰。但医护人员逐一给患者测口腔温度,在实际操作中是一件非常尴尬、也难以持续的事。
经过细致的观察调研,团队形成了一个判断:让住户/患者自主检测、全程无接触、精准测量口腔附近温度,是一个更适宜的技术路径。这样的终端产品,在养老社区、医院、封控区等场景都可以部署安装。
另一个容易被忽略的现实是:疫情之下人们对"被测温"这件事本身是抗拒的。排队做核酸时突然被查出体温异常,会引起周围人的恐慌。因此团队在设计中给自己加了一条要求——作品必须"不打扰":它不应该是一个让人紧张的检测仪,而应该是一件愿意被摆在家里的东西。正是这条要求,最后把作品的外观从"医疗设备"推向了"家居魔镜"。
1.2 作品主体结构
整个管理系统由终端、服务器、管理中心三部分组成,各司其职又相互联通:
- 终端(本作品·魔镜):安装在居家、病房或社区门厅,负责识别住户、采集体征、语音交互与本地显示;
- 服务器:搭建云端服务(EasyIoT / TinyWebDB / Blynk Server),处理住户信息与体温监测数据,并把数据提供给管理中心;
- 管理中心:显示屏可显示人员体温变化情况,管理人员还能通过手机向终端推送提示信息。
数据的流动是双向的:终端向上把体征数据经 WiFi 发布到云端主题,管理中心与手机 App 从云端读取;管理中心向下可以把文字提示推送到终端,由终端语音播报并在屏上显示。本次参赛作品重点实现的是管理终端(魔镜)这一部分。

图 1-1 社区健康管理系统网络示意图(终端—服务器—管理中心三层结构)
1.3.1 实现功能要求
- 镜面与氛围灯:测温没有启动时,魔镜可当镜面使用,可悬挂、也可放置于桌面,还可以作为氛围灯使用;
- 自动识别与测温:当 AI 摄像头识别到已录入住户的人脸时,自动启动测温,并语音提示信息;
- 数据上云:掌控板通过 WiFi 将测量数据上传到云端数据库;
- 信息回传:语音播报管理中心发送的信息,同时在显示屏上显示;
- 环境信息:魔镜上部的点阵屏显示日期、时间、室外温度与湿度。
1.3.2 工程结构要求
- 造型家居化:外形不能有医疗器械感,要能自然地挂在玄关或放在桌面上,与家居环境协调;
- 尺寸适配:成品控制在 300 mm × 300 mm × 40 mm 左右,既能容纳镜面与电路,又方便挂装与搬运;
- 免接触、更安心:测温全程不与人体接触,用户只需站在镜前;
- 材料可加工:结构件选用椴木板、亚克力板等便于激光切割与手工拼装的材料;
- 供电与走线可行:多模块同时工作时电流较大,结构上要留出走线与分路供电的空间。
二、设计思维导图
下图是本作品的设计思维导图,从项目定位、核心功能、硬件构成、软件逻辑、创新特色到应用场景,把"解决什么问题、用什么做、怎么做"梳理成一张图。

社区智能健康系统基于 Blynk 物联网平台项目定位社区防疫健康监测无接触自助测温终端核心功能人脸识别触发 · 语音问候体温 / 血氧 / 心率采集数据上云 · 魔镜显示硬件构成掌控板2.0 + I/O 扩展板哈仕奇AI摄像头 · GY-906 测温MAX30102 · SYN6288 · 灯带软件逻辑掌控板采集端:MQTT 发布行空板显示端:订阅刷新Blynk App:三路体征曲线创新特色免接触口腔测温更接近真实体温测温融入照镜子的日常场景PET 单向透视魔镜造型应用场景居家 / 养老社区医院病房 / 封控区社区健康管理终端
三、硬件选用与连接
3.1 硬件清单
主要器件清单与采购报价如下(价格为参赛申报时的实际报价):
| 序号 | 设备 | 型号 | 连接针脚 | 测量数据 | 单位 | 备注 | 单价(元) | 数量 | 金额(元) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 开发板 | 掌控板 2.0 | 主控 | 系统主控 | 99 | 1 | 99 | ||
| 2 | I/O 扩展板 | micro:bit 掌控双兼容 | — | 转接传感器与执行器 | 89 | 1 | 89 | ||
| 3 | 语音合成模块 | 模块 V2.0(绿深 SYN6288 兼容) | UART P0、P1 | 发出提示音 | 语音问候与播报 | 199 | 1 | 199 | |
| 4 | AI 摄像头 | 哈仕奇 HuskyLens | P14、P13 | 人脸识别 | 住户身份识别 | 379 | 1 | 379 | |
| 5 | 免接触红外测温模块 | GY-906(MLX90614) | I2C | 温度 | °C | 免接触测温 | 115 | 1 | 115 |
| 6 | 心率传感器 | MAX30102 | I2C | 心率 | Times/min | 测心率、血氧 | 89 | 1 | 89 |
| 7 | LED 灯条 | WS2812 | P8 | 氛围灯 | 环形氛围光 | 10 | 1 | 10 | |
| 8 | 行空板 | UNIHIKER | WiFi | 联接 WiFi、显示 EasyIoT 数据 | 399 | 1 | 399 | ||
| 9 | 其它 | 杜邦线、外壳等 | 耗材 | 45 | 1 | 45 | |||
| 合计 | 1370 | ||||||||
除电子模块外,作品方案中还列入了结构材料与显示部件,它们直接决定了"魔镜"能不能立得住、像不像一面镜子:
| 类别 | 名称 | 规格 / 型号 | 作用 |
|---|---|---|---|
| 结构材料 | 平面镜 | 300 × 300 | 与 PET 薄膜形成无限反射效果,构成镜面主体 |
| 结构材料 | PET 高强度聚酯薄膜 | 300 × 300 | 单向透视:无背光为镜面,有背光透出画面 |
| 结构材料 | 亚克力板 | 300 × 300 × 3 | 透明面板与背板支撑 |
| 结构材料 | 椴木板 | 5 mm | 激光切割边框与内部骨架 |
| 显示部件 | 单色显示屏 | 0.91" 128×32 I2C | 显示时间、日期等基础信息 |
| 显示部件 | 点阵屏 | MAX7219 4×8 | 显示日期、时间、室外温度与湿度 |
| 控制部件 | 主控板 | ESP8266 D1 mini | 辅助联网与控制(扩展方案) |
| 电源控制 | 手扫感应开关模块 | 86 型 | 控制整机开机时间,缓解供电不足 |
3.2 硬件连接
终端部分以掌控板 2.0 + I/O 扩展板作为控制底座,各模块按下图接入:

图 3-1 终端硬件连接图(掌控板 + 扩展板与各模块接线)
| 模块 / 部件 | 连接引脚 | 说明 |
|---|---|---|
| 掌控板 2.0 | 主控 | 系统主控,通过 I/O 扩展板连接外设,WiFi 上传云端数据库 |
| I/O 扩展板 | — | micro:bit 掌控双兼容,转接传感器与执行器 |
| 语音合成模块 V2.0 | UART:P0(RX)、P1(TX) | 语音提示播报(sstts.begin(sstts.eV2, &Serial2, P0, P1)) |
| AI 摄像头(哈仕奇 HuskyLens) | 软串口:P14(RX)、P13(TX) | 人脸识别(huskylens.beginSoftwareSerialUntilSuccess(P14, P13)) 注:早期接线图标注为 P15/P16,程序实际使用 P14/P13,以源码为准 |
| 免接触红外测温模块 GY-906 | I2C 总线(P19/P20) | 免接触测量体温(DFRobot_MLX90614_IIC) |
| 心率血氧传感器 MAX30102 | I2C 0x57(P19/P20) | 测量心率 / 血氧,与测温模块共用 I2C 总线 |
| LED 灯条 WS2812 | P8 | 状态与氛围灯,环形布置在镜面内侧 |
| 行空板 UNIHIKER | WiFi | 联网显示 EasyIoT 数据,提供本地交互界面 |
3.3 模块角色与技术参数
| 模块 | 在系统中的角色 | 关键参数 |
|---|---|---|
| 掌控板 2.0 | 采集端主控,负责识别触发、传感器读取与数据上报 | 板载 WiFi / OLED / 加速度计,支持 Mind+ 与 mPython |
| 哈仕奇 HuskyLens | 人脸识别,判断"站在镜前的是不是已录入住户" | 内置人脸识别算法,串口通信,可学习多个人脸 ID |
| GY-906(MLX90614) | 非接触红外测温,获取体温 | I2C 接口,红外非接触测量,输出摄氏度 |
| MAX30102 | 心率与血氧采集 | I2C 地址 0x57,可读取心率(Times/min)与血氧(%) |
| 语音合成模块 V2.0 | 语音问候与播报管理中心消息 | UART 通信,支持中文文本转语音 |
| WS2812 灯条 | 环形氛围灯,测温时提供背光与状态提示 | 单总线级联,可编程颜色 |
| 行空板 UNIHIKER | 显示端,本地界面展示三项体征 | 内置 Linux + Python,支持 SIoT / GUI 库 |
供电方面需要特别说明:摄像头、行空板与语音合成模块同时取电时,扩展板的供电比较吃紧,这也是后面"调试与改进"一节要重点解决的问题。
四、结构安装与制作过程
本作品的制作分为构思定位、外形结构设计、激光切割与拼装、硬件连接、编程、调试六个环节。其中"外观"不是最后套上去的一层壳,而是从一开始就决定了作品走向的关键变量——它经历了三次完整的推翻与重定位。
4.1 设计定位的三次演进
第一次:作为医疗器具的结构设计。最初的方案是把终端做成一台小型医疗柜:正面是红十字标识与显示屏,中间是测温口与储物格,整体是医院设备的语言。方案画出来后,团队自己就先否定了它——这样的东西放进老人家里,只会让人觉得自己"是个病人"。

图 4-1 最初的医疗器具外形构想(医用柜式,含红十字标识与显示屏)
第二次:作为生活用品的结构想法。既然医疗感太重,就换个方向做"家里的东西":团队尝试过画框式(把显示屏藏进一幅装饰画里)与木盒式两种方案,希望它能自然地摆在桌上或挂在墙上。这一步解决了"不像医疗器械"的问题,但新的问题是:它仍然只是一个"摆件",用户没有理由主动走近它。

图 4-2 家居用品方向的外形方案(画框式与木盒式)
第三次:定位为家居装饰——魔镜。转折点来自一个很日常的观察:人在出门前、回家后都会照镜子,这是一个几乎不需要提醒就会发生的动作。如果把测温藏在照镜子的过程里,用户就不需要被"要求"配合检测——想测就测,不测它也是一面镜子。作品就此定型为一台"魔镜"。
4.2 外观结构与魔镜造型设计
成品外形为一块 300 mm × 300 mm、厚度约 40 mm 的方形镜面体,正面主视区是一整片圆形镜面,上方开窗显示时间与信息,下方留有传感器与走线孔位。整体造型克制、无外露电路,可壁挂也可加装底座置于桌面。

图 4-3 魔镜三维尺寸与正面布局(300 × 300 × 40 mm)
结构上采用"面板 + 边框 + 骨架 + 背板"的叠层思路:
- 面板层:外层 300 × 300 的 PET 高强度聚酯薄膜,内层为 300 × 300 的平面镜,两者叠合。PET 薄膜具有单向透视特性——无背光源时呈镜面效果,可以正常当镜子使用;有背光源时则透出清晰的画面图像。
- 边框与骨架:5 mm 椴木板激光切割成边框与内支撑,形成 40 mm 的腔体,容纳电路与走线;
- 背板层:3 mm 亚克力板做背板,兼顾强度与透光;
- 光效层:WS2812 环形灯带布置在镜面内侧,通过内置平面镜与半透膜形成无限反射的隧道光效,既是氛围灯,也是测温启动时的状态提示;
- 开窗与孔位:顶部开窗放置单色显示屏与点阵屏,底部预留传感器孔位,让摄像头、测温头、喇叭都能"藏在镜子里"。
把摄像头与测温头藏进镜面背后,是本作品在结构上最重要的一次取舍:它牺牲了传感器的最佳视场角(导致后期需要反复调整安装角度),换来的是"用户面对镜子时会自然正对摄像头与测温头"这一使用姿态——结构设计在这里实际上是在引导人的动作,这也是人机关系中"机适应人"的一种具体做法。

图 4-4 魔镜结构设计图(正面开窗布局与背面装配结构)

图 4-5 成品外观:环形灯带点亮时,镜面透出内部光效
4.3 激光切割与拼装
边框、内骨架与背板连接件用 LaserMaker 完成图形化排版后激光切割,材料为 5 mm 椴木板;亚克力面板与背板按同尺寸切割。切割件通过榫接 + 木工胶 + 少量螺钉拼装成 40 mm 厚的腔体,再依次压入平面镜、PET 薄膜、显示屏与灯带。

图 4-6 激光切割排版图(面板、背板、圆环与边框件)
4.4 硬件组装与走线
组装顺序为:先固定掌控板与扩展板的位置,再依次接入语音合成模块、AI 摄像头、红外测温头与心率传感器,最后接入环形灯带。由于各模块线缆较多,走线沿腔体内壁用扎带与热熔胶固定,避免线缆遮挡摄像头与测温头的视场。

图 4-7 环形灯带与镜面组件的装配过程

图 4-8 整机组装与初步通电检查
4.5 程序编写与联调
编程涉及的功能模块较多:作品先用 Mind+ 图形化编程完成初步设计,把"识别—问候—采集—上报"的主流程跑通;后期转为源代码,在 VS Code 中调试串口通信与网络模块。调试内容包括:人脸 ID 的学习与识别距离、I2C 总线上两个传感器(测温头与心率模块)的地址冲突排查、以及 MQTT 消息的格式约定。

图 4-9 程序调试:在电脑端同步检查采集数据与网络连接
4.6 供电与稳定性改进
联调阶段遇到的最大的问题是供电不足:摄像头、行空板与语音合成模块同时工作时电流吃紧,偶尔出现摄像头点不亮、主控运行不稳的现象。团队的处理办法是分两步:先用充电宝给高功耗模块分路供电,让系统能稳定跑起来;再引入 86 型手扫感应开关模块控制整机开机时间——不用时整机断电,需要时手扫即开,既缩短了满负荷运行时间,也让作品的使用动作变得自然。

图 4-10 分路供电后的桌面联调(手扫感应开关控制开机)
五、编程流程分析
5.1 系统数据流与通信设计
系统采用"一条 MQTT 主题 + 六个 Blynk 虚拟引脚"的简单通信方案:掌控板采集端把体征数据发布到 EasyIoT 的同一个主题上,并用数据自带的单位做区分;行空板显示端订阅这条主题,靠单位字符串(℃ / % / Times/min)判断这是哪一项数据,分别刷新到界面对应的位置;同时掌控板把数值写入 Blynk 的虚拟引脚,手机 App 就能看到三路体征曲线。这样设计的好处是——不需要为每项数据单独开主题,新增传感器时也不改动订阅逻辑。

图 5-1 EasyIoT 云端数据记录(体温 / 血氧 / 心率与住户姓名依次上报)
从上图的记录可以看到数据上传的真实节奏:监测到住户后先上报姓名"徐子涵",随后按 血氧 → 心率 → 体温 的次序循环上报,每轮间隔约 1 秒,同一秒内可见 97%、108Times/min、25.81℃ 等记录。
5.2 掌控板采集端流程
采集端承担"识别触发 + 连续采集 + 双通道上报"三件事。上电后先完成掌控板、语音合成、心率传感器初始化与网络连接,再把哈仕奇切换为人脸识别算法并进入主循环。识别到已录入住户后,先语音问候、上报姓名,然后连续采集 10 组数据(间隔 500 ms)以降低单次测量的偶然误差,最后一组数据上报完成后发送"清零"标记结束本轮。
开始(上电)初始化掌控板 · 语音合成(UART P0,P1)心率传感器(I2C 0x57)连接 WiFi初始化 EasyIoT(MQTT) 并等待就绪哈仕奇软串口 P14(RX)/P13(TX)设为人脸识别算法 · 清空 OSD进入主循环识别到已录入住户?语音问候 + MQTT 上报住户姓名循环 10 次(间隔 500 ms)读取体温 / 血氧 / 心率MQTT 发布体征数据Blynk 写入虚拟引脚 V0~V5上报“清零”,结束本轮采集是否返回主循环,等待下一位住户
5.3 行空板显示端流程
显示端程序更短,但承担着"把数据变成看得懂的画面"的任务。上电后依次完成引脚初始化、GUI 创建、本地 API 配网与 SIoT 连接,随后订阅采集端使用的主题,并一次性把标题、装饰图标与三行数值的界面元素绘制出来。真正干活的是消息回调函数:每收到一条消息,就用其中是否包含 ℃ / % / Times/min 来判断这是体温、血氧还是心率,然后只刷新对应的那一行数值。
开始(上电)初始化行空板引脚 Board().begin()创建 GUI 画布 · 本地 API 配网SIoT 连接 EasyIoT(MQTT) 服务器启动消息循环 siot.loop()订阅掌控板发布的主题 S3x2ggYnR绘制界面:标题 / 图标体温・心率・血氧 三行数值收到 MQTT 消息?按单位分类:℃ 体温 / % 血氧/ Times/min 心率刷新界面对应数值行是否返回等待下一条消息
5.4 通信协议对照表
| 数据项 | MQTT 主题 | 数据格式 | Blynk 虚拟引脚 |
|---|---|---|---|
| 住户姓名 | S3x2ggYnR | 文本(如“徐子涵”) | — |
| 体温 | S3x2ggYnR | 数值 + ℃ | V0(住户1) / V1(住户2) |
| 血氧 | S3x2ggYnR | 数值 + % | V2 / V3 |
| 心率 | S3x2ggYnR | 数值 + Times/min | V4 / V5 |
| 本轮结束标记 | S3x2ggYnR | “清零” | — |
六、参考代码
本作品采用 Mind+ 图形化编程起步、后期转为源代码调试的方式开发。为便于阅读与复现,下面给出经整理的源代码版本,并按功能逐行加了中文注释。涉及个人密码、物联网账号等敏感信息的部分已做打码处理。
6.1 掌控板采集端(C++ / mPython)
/*! MindPlus · mPython 掌控板采集端 —— 社区智能健康系统 */
#include <MPython.h> // 掌控板基础库
#include <DFRobot_SpeechSynthesis.h> // 语音合成模块
#include <DFRobot_HuskyLens.h> // 哈仕奇 AI 摄像头
#include <DFRobot_MLX90614.h> // GY-906 免接触红外测温
#include <DFRobot_BloodOxygen_S.h> // MAX30102 心率血氧
#include <DFRobot_Iot.h> // EasyIoT(MQTT)物联网库
#include <Blynk.h> // Blynk 云平台
#define BLYNK_PRINT Serial
volatile float mind_n_WenDu, mind_n_XinLvShuJu, mind_n_XueYangShuJu; // 体温 / 心率 / 血氧
void DF_ChuShiHua(); // 自定义初始化函数声明
const String topics[5] = {"S3x2ggYnR","","","",""}; // MQTT 主题(仅用第 1 个)
DFRobot_Iot myIot; // 物联网对象
DFRobot_SpeechSynthesis_UART sstts; // 语音合成(串口版)
DFRobot_HuskyLens huskylens; // AI 摄像头
DFRobot_MLX90614_IIC mlx90614; // 测温(I2C)
DFRobot_BloodOxygen_S_I2C max30102(&Wire, 0x57); // 心率血氧(I2C 地址 0x57)
void setup() { // 上电只执行一次
mPython.begin(); // 掌控板初始化(屏幕、引脚)
sstts.begin(sstts.eV2, &Serial2, P0, P1); // 语音合成:UART P0(RX) / P1(TX)
max30102.begin(); // 心率血氧传感器初始化
Blynk.config("***", IPAddress(192,168,15,1), 8080); // Blynk 指向本地服务器(凭证已打码)
DF_ChuShiHua(); // 调用自定义初始化
}
void loop() { // 主循环:一直找人
huskylens.request(); // 向摄像头请求一次识别结果
if (huskylens.isLearned(1)) { // 判断 ID=1 的人脸是否已被学习(已录入住户)
if (huskylens.isAppearDirect(HUSKYLENSResultBlock)) { // 画面里是否出现识别框
if (huskylens.isAppear(1, HUSKYLENSResultBlock)) { // 出现的框是否就是 ID=1
sstts.speak("徐子涵先生,很高兴为您服务"); // 语音问候
myIot.publish(topic_0, "徐子涵"); // MQTT 上报住户姓名
for (int index = 0; index < 10; index++) { // 连续采集 10 组,降低单次误差
delay(500); // 间隔 500ms,等传感器稳定
myIot.publish(topic_0, String(max30102.getSPO2()) + "%"); // 血氧上报
myIot.publish(topic_0, String(max30102.getHeartbeat()) + "Times/min"); // 心率上报
myIot.publish(topic_0, String(mlx90614.getObjectTempC()) + "℃"); // 体温上报
mind_n_WenDu = mlx90614.getObjectTempC(); // 体温 → 全局变量
mind_n_XinLvShuJu = max30102.getHeartbeat(); // 心率 → 全局变量
mind_n_XueYangShuJu = max30102.getSPO2(); // 血氧 → 全局变量
Blynk.virtualWrite(V0, mind_n_WenDu); // 体温 → V0(住户1)/ V1(住户2)
Blynk.virtualWrite(V2, mind_n_XueYangShuJu); // 血氧 → V2 / V3
Blynk.virtualWrite(V4, mind_n_XinLvShuJu); // 心率 → V4 / V5
yield(); // 让出时间片,保持网络与看门狗正常
}
myIot.publish(topic_0, "清零"); // 本轮结束,发送清零标记
} else {
sstts.speak("你好,请保持有效距离"); // 识别框不匹配时的提示
}
}
}
// 识别到 ID=2(第二位住户)时的逻辑与上面完全一致,只是上报姓名不同、写入 V1/V3/V5
if (huskylens.isLearned(2)) { /* 结构与 ID=1 相同 */ }
Blynk.run(); // 维持 Blynk 长连接
}
void DF_ChuShiHua() { // 自定义初始化:网络 + 摄像头 + 传感器
mind_n_WenDu = mind_n_XinLvShuJu = mind_n_XueYangShuJu = 0; // 变量清零
myIot.wifiConnect("GT-ndwz", "***"); // 连接 WiFi(密码已打码)
myIot.init("iot.dfrobot.com.cn", "***", "", "***", topics, 1883); // EasyIoT MQTT 初始化
myIot.connect(); // 发起 MQTT 连接
while(!myIot.wifiStatus()) yield(); // 阻塞等待 WiFi 就绪
while(!myIot.connected()) yield(); // 阻塞等待 MQTT 就绪
huskylens.beginSoftwareSerialUntilSuccess(P14, P13); // 哈仕奇软串口 P14(RX) / P13(TX)
huskylens.writeAlgorithm(ALGORITHM_FACE_RECOGNITION);// 切换为人脸识别算法
huskylens.clearOSD(); // 清掉屏幕上残留的识别框
max30102.sensorStartCollect(); // 启动心率血氧采集
}6.2 行空板显示端(Python)
# -*- coding: UTF-8 -*-
# MindPlus · Python 行空板显示端 —— 社区智能健康系统
from pinpong.board import Board
from unihiker import GUI
import requests
import siot
import time
def QiDongwifiSheZhi(): # 通过行空板本地 Web API 配网
print("扫描WIFI:")
r = requests.get("http://10.1.2.3/wifi/scan") # 扫描可用 WiFi
print(r.text)
r = requests.get("http://10.1.2.3/wifi/connect?ssid=MI8&password=***") # 连接热点(密码已打码)
print(r.text)
def on_message_callback(client, userdata, msg): # MQTT 收到消息时自动调用
if msg.payload.decode().find("℃") != -1: # 含 "℃" → 判定为体温
v1.config(text=msg.payload.decode()) # 刷新体温那一行
else:
time.sleep(0.2); v1.config(text="")
if msg.payload.decode().find("%") != -1: # 含 "%" → 血氧
b1.config(text=msg.payload.decode())
else:
time.sleep(0.2); b1.config(text="")
if msg.payload.decode().find("Times/min") != -1: # 含 "Times/min" → 心率
a1.config(text=msg.payload.decode())
else:
time.sleep(0.2); b1.config(text="")
Board().begin() # 初始化行空板引脚
siot.init(client_id="", server="iot.dfrobot.com.cn", port=1883,
user="***", password="***") # EasyIoT 凭证已打码
u_gui = GUI() # 创建 GUI 画布
siot.connect(); siot.loop() # 连接 MQTT 并启动消息循环
siot.set_callback(on_message_callback) # 绑定消息回调函数
QiDongwifiSheZhi() # 执行配网
siot.getsubscribe(topic="S3x2ggYnR") # 订阅掌控板发布的主题
head = u_gui.draw_text(text="社区健康系统", x=40, y=10, font_size=18, color="#CC0000") # 标题
u_gui.draw_image(image="southeast.png", x=70, y=55, w=100, h=100) # 装饰图标
v = u_gui.draw_text(text="体温:", x=30, y=150, font_size=15, color="#CC0000")
v1 = u_gui.draw_text(text=" ", x=90, y=150, font_size=15, color="#CC0000") # 体温数值
a = u_gui.draw_text(text="心率:", x=30, y=175, font_size=15, color="#CC0000")
a1 = u_gui.draw_text(text=" ", x=90, y=175, font_size=15, color="#CC0000") # 心率数值
b = u_gui.draw_text(text="血氧:", x=30, y=200, font_size=15, color="#CC0000")
b1 = u_gui.draw_text(text=" ", x=90, y=200, font_size=15, color="#CC0000") # 血氧数值
u_gui.draw_text(text="MQTT连接成功", x=62, y=280, font_size=12, color="#CC0000") # 状态提示
while True: pass # 主循环保持运行(GUI 与 MQTT 在后台线程运行)七、作品创新点
- 测温准确、融入生活:采用免接触口腔测温,更接近人体核心温度;并把测温环节融入"照镜子"的日常场景——想测就测,避免检测人员上门、或核酸检测时临时发现体温异常而造成恐慌。
- 数据与住户准确对应:对如何保证测温中采集数据的准确性做了多次修改与验证,并通过人脸识别把体征数据与具体住户信息绑定,避免"数据是人测的、却不知道是谁的"。
- 镜面与氛围一体:采用 PET 高强度聚酯薄膜单向透视——无背光源时为镜面,有背光源时透出清晰画面;与内置平面镜形成无限反射,环形灯带产生炫幻效果,既是健康终端,也是居家饰品。
- 一条主题、多个单位:通信上只用一条 MQTT 主题,靠数据自带的单位字符串区分体温、血氧与心率,新增传感器时无需改动订阅逻辑,降低了系统的耦合度。
- 连续采样取稳态:识别触发后连续采集 10 组数据(间隔 500 ms)再上报,用"多测几次"的方式抵消红外测温的瞬时波动。
八、项目应用拓展
作品当前的形态是"单台终端 + 云端 + 手机 App"。把它放到真实的社区与医疗机构中,还有几种很自然的延伸方向:

图 8-1 Blynk App 手机端:体温 / 血氧 / 心率三路体征曲线(对应 V0~V5 虚拟引脚)
| 拓展方向 | 实现要点 | 迁移能力点 |
|---|---|---|
| 养老社区健康哨点 | 魔镜安装在楼道或房门口,老人照镜即完成体征采集,异常数据自动推送护理站 | 人脸—身份绑定、体征阈值判断、MQTT 远程推送 |
| 校园 / 企业晨检终端 | 复用人脸识别与语音模块,把测温结果直接写入考勤与健康台账 | 人脸识别调用、数据表结构设计、Web 端展示 |
| 家庭健康数据看板 | 增加体征趋势分析,手机端回看一周曲线,异常时提醒家属 | 云端数据存储、曲线可视化、App 虚拟引脚配置 |
| 医院病房无接触巡检 | 强化口腔测温的稳定性与外壳消毒结构,替代护士逐床人工测温 | 传感器精度调试、分路供电设计、结构与消毒要求 |
需要说明的是,拓展方向中"多台终端统一管理"这一层,作品目前只完成到"单台终端 + 云端可视化"的程度,管理中心侧的批量管理与权限功能属于后续工作。
九、小结
9.1 创作历程与团队分工
作品的方案走向由两次团队讨论确定,两次讨论的结论直接改变了作品的定位:
| 讨论次序 | 时间 | 主要讨论内容 | 形成决定 |
|---|---|---|---|
| 第一次 (参会 2 人) | 2022-01-10 13:00–15:30 | 设计作品定位;作品使用的硬件模块 | 决定定位为医疗设备;使用掌控板做主控,加入测温头、AI 摄像头、语音合成模块 |
| 第二次 (参会 3 人) | 2022-02-06 20:00–23:00 | 作品定位调整;编程中调用的网络模块;是否开发管理端手机 App | 认同将作品重新定位为家居装饰用品与疫情防控管理助手;采用教学用 TinyWebDB + EasyIoT;手机端不再另写 APP,直接使用 Blynk APP |
按创意设计报告中的分工说明,作品的设计与制作由团队同学承担,过程中与指导老师多次交流、参考了老师的一些建议;硬件连接、激光切割与安装、编程与调试等环节由同学自行安排时间推进。从上面的讨论记录也能看出,作品并不是一开始就"想清楚了",而是两次推翻定位、反复调整之后才逐渐成型的。
9.2 反思不足
- 硬件配置偏低:受资金限制,项目使用的硬件设备属于低配,对作品造成一定影响——OLED 屏规格太小、语音合成模块人声略显呆板、点阵屏不能很好地显示中文。
- 供电不足:摄像头、行空板与语音合成模块同时取电时,扩展板供电吃紧,偶尔出现摄像头点不亮、主控不稳的现象;虽以充电宝分路供电、并用 86 型手扫感应开关模块控制开机时间缓解,但并非根本解决。
- 验证有限:作为中学生阶段的作品,功能以验证核心创意为主,在覆盖人群规模、长期稳定性与极端环境下的可靠性方面,验证仍然不足。
- 测温条件敏感:红外测温对距离与角度比较敏感,需要用户在镜前保持相对稳定的站位,这也是把传感器藏进镜面结构后带来的副作用。
9.3 未来改进
- 外形与精度:把外形设计得更美观,功能更加完善,让测量精度更高、指向性更准确,并采用更加轻便牢固的材料。
- 降低功耗、走向产品化:在网络条件有保障时,把人脸识别、数据分析等模型计算交给云端服务器(如百度大脑、科大讯飞等),减轻主控的运算强度,从而降低供电功率、缩小体积。
- 完善云端与管理端:继续使用 TinyWebDB + EasyIoT 物联网服务,手机端直接用 Blynk APP 查看体征、无需另开发 App;在此基础上进一步考虑管理端手机 App 的设计,支持多台终端统一查看。
9.4 收获
- 学会从痛点定义问题:从一开始盯着"测温枪不好用",到后来想清楚"用户不愿意被测",问题定义变了,方案也就完全不一样了。
- 走通了从图形化到代码的路:Mind+ 图形化把逻辑跑通,再转源代码解决串口、I2C 地址冲突、网络重连等具体问题,这是课本上学不到的工程经验。
- 理解了"结构也是设计":把传感器藏进镜面,看起来只是外观问题,实际上改变的是用户的使用姿态和配合意愿。
- 懂得取舍:低配硬件、有限预算下,与其追求功能堆砌,不如把一个核心场景(照镜即测温)做扎实。






优秀,很好的案例