1 前言
近些年来，随着科技的更新迭代，IoT行业迎来了一个快速膨胀发展的窗口期，我们随之可见的是，越来越多的智能化产品进入到了我们的日常生活中，包括发展比较早的智能家居类产品、智能家电类产品，还有近些年非常火热的智能穿戴类产品，这些都得到了市场很好的反馈。
科技不仅能给人们带来幸福感的提升，而且随着智能设备越来越发达，在某些特定的场景下，它往往还能救人于危难之时。
本文要讲述的正是这样一套智能的IoT系统在家庭环境下的部署应用，它能够帮助人们解决一些危险难题。
2 项目简介
2.1 项目名称
基于N32G457和RT-Thread全新打造的私有化定制家用式智能告警系统
2.2 设计思路
主体思路采用N32G457芯片作为终端侧的主控MCU，搭载国产实时操作系统RT-Thread，外接ESP8266 Wi-Fi模块，以及若干用于检测的传感器，比如烟雾传感器、酒精传感器、天然气传感器、空气质量传感器等，将检测的信息转换成可能产生的告警数字信号，通过板载告警指示灯和告警警报器本地输出告警信息，同时通过Wi-Fi的网络能力，将告警信息透过网络直接推送到关注告警信息的相关人员，实现相对实时的安全解决方案。
2.3 主要解决的问题
主要的解决的问题场景是普通家用环境下的危险因素告警检测，这其中包含最基本的烟雾检测（对应明火燃烧）、酒精检测（对应易燃液体）、天然气泄漏检测（对应易燃易爆）、空气质量检测（对应不明物品烧焦产生有害的气体充斥在家庭环境中）。
还有一个家庭环境中，上述的危险因素会成倍放大的场景是，家中只有独居老人的时候。比如，我的家人就很经常做饭忘了关天然气，但是我们年轻人会经常发现并及时提醒他们，才不至于酿成悲剧。但是，独居老人就是很大的问题，因老人们年纪上来了，嗅觉、味觉、听觉、视力等多项身体机能指标都下降得很厉害，面对上述场景，也难快速地发现危险并做出有效的解决措施，那么这就需要一套更加智能的解决方案及时发现这些危险，以最现眼最宏观的方式告知独居老人，及时接触风险。
我这个智能解决方案能够很好地解决这个场景问题，一方面它自带了多种探测传感器，能够及时发现危险；同时当危险发生时，通过告警指示灯闪烁和警报器盛宴告警，最大程序地提醒独居老人，危险已经发生，应尽快解除危险；另一方面，这个智能系统支持独居老人的子女订阅关注告警系统推送的危险信息，通过微信的及时性，直接传达到子女手中，这也能够保证危险发生的第一时间能够得到子女的关注和提醒，得以顺利协助老人解除危险。
2.4 项目创新点
轻量化的终端设计，板载RT-Thread操作系统，方便应用功能开发，可快速横向扩展功能；
终端设备部署可实现分布式，不局限于具体的部署环境；
整套IoT后端系统完全私有化部署，不受限于任何IoT云平台；数据安全能够得到很好的保证；
报警推送消息的内容可完全自定义配置，设计非常灵活；
接收报警推送的人员支持可配置，可远程实时推送告警消息到多个人员；
面对独居老人的相关安全问题，能够很好地提供高效的解决方案。
3 系统架构介绍
3.1 系统核心架构图
整个系统的核心架构图如下所示：
从上面这个核心架构图中，我们可以看到整个IoT系统组成，包括智能设备终端侧、WEB配置前端侧、智能IoT系统平台后端侧，同时还有手机移动端。下面就整个系统的几大重要组件，我会一一进行简要讲解。
3.2 终端侧
终端侧主要承载的是现场环境要素的检测，同时做一些边缘侧的应用逻辑处理，还需要具备对外网络的通讯能力，能在第一时间把紧要消息通过网络通道传输出去。
终端侧包括的核心组件有：国民技术的 N32G457，搭载的是国产实时操作系统 RT-Thread，同时外设板载有 ESP8266 Wi-Fi通讯模组、告警指示灯、声音告警器、烟雾传感器、酒精传感器、天然气传感器、空气质量传感器、若干按键等等。
终端侧不仅包含设备硬件，还需要对应的固件软件，两者相辅相成，共同完成终端侧的功能逻辑。
3.3 后端侧
这里的后端侧，从细分来看，总有4部分：
EMQ：「随处运行，无限连接，任意集成」云原生分布式物联网接入平台，一体化的分布式 MQTT 消息服务和强大的 IoT 规则引擎，为高可靠、高性能的物联网实时数据移动、处理和集成提供动力，助力企业快速构建关键业务的 IoT 平台与应用。它就一个MQTT的Broker，消息的中转站，终端侧的上报消息能够有序、高效、稳定地传递给 Domoticz，它是功不可没。
Domoticz：Domoticz 是一个开源的智能家居系统，通过它你可以监测和控制各种设备比如：灯、开关 ，各种传感器、仪表比如： 温度、雨、风、紫外线、电、气体、水 等等。 还可以向任一移动设备发送通知或警告。
SQLite: SQLite 是一个软件库，实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。SQLite 是在世界上最广泛部署的 SQL 数据库引擎，在我们的系统中，它承载的是整个系统的数据、配置、产品等核心数据的存储，具有举足轻重的地位。
Wechat服务后台: 这部分并不是我开发的，也不是我所能控制的，罗列在此，只为了表示后端系统组成的完整性。
3.4 前端侧
前端侧包括的是开源智能家居系统 Domoticz 的配置前端，通过这个前端页面，可以快速地创建虚拟的智能产品，通过对接数据协议，实现对智能设备的管理和展示。
同时这个前端页面可以兼容到PC端浏览器和移动端浏览器，带有用户登陆管控功能，有利于维护数据和产品的安全。
当它在移动端使用时，可以实现无APP，直接使用手机浏览器就够了，不会过多地消耗手机的存储空间，很轻量化，依赖相对较少。
它与后端的 Domoticz 是典型的B/S网络架构模型，与之相对应的有C/S网络架构模型。
B/S网络架构，指的是Browser／Server(浏览器／服务器)架构，就是只需要安装维护一个服务器，而客户端采用浏览器的方式来运行软件。它是随着Internet技术而兴起的，是对C／S结构的一种变化和改进。主要利用了WWW浏览器技术，结合多种Script语言和新技术，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。它是一种全新的软件系统构造技术，它只需要安装一个浏览器和数据库，就可以让浏览器通过Web Server同数据库进行数据交互。
C/S网络架构，它是一种网络体系结构，其中客户端是用户运行应用程序的PC端或者工作站，客户端要依靠服务器来获取资源。C/S架构是通过提供查询响应而不是总文件传输来减少了网络流量。它允许多用户通过GUI前端更新到共享数据库，在客户端和服务器之间通信一般采用远程调用（RPC）或标准查询语言（SQL）语句。
B/S网络架构的基本特征：
B / S架构的优点：
（1）该架构不需要安装客户端，可以直接运行在Web浏览器中；
（2）B/S架构可以直接放在Internet网络上，从而达到通过某些特权来控制多客户端访问的目的以及交互方式；
（3）B/S架构由于不需要安装客户端，因此不存在更新多个客户端以及升级服务器等问题。
B / S架构的缺点：
（1）在跨浏览器中，B/S架构不是令人最满意的架构，时常容易出现页面兼容显示的问题；
（2）在速度和安全性方面，仍然需要花费巨大的设计成本，这是B/S架构中最大的问题；
（3）客户端服务器交互是请求响应模式，通常需要刷新页面，这是不愿意看到客户的。但是这个缺点在Ajax受欢迎之后该问题得到了一定程度的缓解。
网络C/S架构的基本特征：
（1）客户端进程包含特定于解决方案的逻辑，并提供用户与应用程序系统其余部分之间的接口。服务器进程充当管理共享资源（如数据库，打印机，调制解调器或高性能处理器）的软件引擎。
（2）前端任务和后端任务对计算资源有着根本不同的要求，例如处理器速度，内存，磁盘速度和容量以及输入/ 输出设备。
（3）客户端和服务器的硬件平台和操作系统通常不相同。客户端和服务器进程通过一组明确定义的标准应用程序接口（API）和RPC进行通信。
（4）C/S架构的一个重要特征是可扩展性，它们可以水平或垂直缩放。水平扩展意味着添加或删除客户端，工作站只会对性能产生轻微影响。垂直扩展意味着迁移到更大更快的服务器计算机或多服务器中。
WEB端的显示配图如下所示：
3.5 移动端侧
这个移动端侧，包括两个部分，一个是前面已经提及的 Domoticz 在手机移动端浏览器依然可以保持很好的显示兼容性，也能够完成PC浏览器一模一样的功能；但能放在移动端，它的便捷性就一下子提升了一个级别，并且无APP模式，大大提高了客户使用的意愿。
另一个部分就是我们的国民APP微信，微信凭借着 10 亿月活、8 亿日活的运营数据牢牢控制住社交APP的头把交椅，几乎可以说是人人离不开微信，它确确实实地人们的生活带来了便利。
通过对Domoticz系统的改装，使得它在原本的事件通知上也支持推送消息到微信客户端，这也将大大提升系统产品的易用性和可落地性。
4 系统设计说明
下面就系统的各个组件的设计，做简要的说明。
4.1 硬件部分
硬件部分主要分为四大部分：MCU主控、Wi-Fi模组、各类传感器、输出设备。
MCU主控：N32G457
本次使用的MCU主控来自国民科技的32位高性能MCU，以下是它的板载资源介绍：
在我设计的这个系统中，我主要使用其UART1（debug功能）、UART2（连接ESP8266）、UART3（连接语音播报模块）、还有6个GPIO（用于接入各类传感器的输入及告警信息的输出）。
我的硬件实物连接图如下所示：
Wi-Fi模组: ESP8266
我这里使用的搭建ESP8266 Wi-Fi芯片的模组ESP-12F，它是由安信可科技开发的，该模块核心处理器 ESP8266 在较小尺寸封装中集成了 业界领先的 Tensilica L106 超低功耗 32 位微型 MCU，带有 16 位精简模式，主频支持 80 MHz 和 160 MHz，支持 RTOS，集成 Wi-Fi MAC/ BB/RF/PA/LNA，板载天线。
各类传感器：MQ系列烟感、燃气等传感器
这里主要包括系统中使用的烟雾传感器、酒精传感器、天然气传感器、空气质量传感器，这几个都是MQ气体类传感器。
MQ气体传感器使用的气敏材料是在清洁空气中电导率较低的二氧化锡（SnO2）。当传感器所处环境中存在可燃气体时，传感器的电导率随空气中可燃气体浓度的增加而增大。使用简单的电路即可将电导率的变化转换为与该气体浓度相对应的输出信号。MQ气体传感器对甲烷的灵敏度高，对丙烷、丁烷也有较好的灵敏度。这种传感器可检测多种可燃性气体，特别是天然气，是一款适合多种营养的低成本传感器。
输出设备：DY-SV17F语音播放模块
DY-SV17F是一款智能语音模块，集成IO分段触发，UART串口控制，ONE_line单总线串口控制，标准MP3等7种工作模式；板载5W D类功放，可直接驱动4Ω，3~5W喇叭；支持MP3,WAV解码格式，板载32Mbit（4MByte）flash存储音频文件，可通过USB数据线连接电脑更新音频文件。
4.2 软件部分
软件部分主要分为两部分：终端固件部分和Domoticz消息推送定制部分。
4.2.1 终端固件开发
终端固件主要包括四大部分：N32G457的原厂BSP、RT-Thread实时操作系统、ESP8266相关的配置代码使能、个性化的应用逻辑代码。
其中N32G457的原厂BSP基本不动，原厂和相关开发者已经适配好了；通用的RT-Thread操作系统的代码也不在此处的修改中，直接复用已有的代码，这里使用的版本是4.0.2。
ESP8266相关的AT、网络组件代码也是现成的，使能配置之后就可以直接用了，还是非常的方便。不过这里其实我也是踩坑了，下面的项目复盘会讲到。
所以这里重点讲一下，应用逻辑的代码：主要包括几个传感器的检测驱动、告警指示灯的控制逻辑、音频播放模块的驱动、按键触发功能的处理等。
整个应用软件部分的程序框架如下图所示：
其中：
Main-Thread：执行整个应用的初始化，负责管理各个子线程的同步和衔接，比如告警信号产生时，触发告警信号的对外上报，正是由Main-Thread来执行的。
System-Config：用于完成整个系统相关的属性配置，比如传感器探测的周期设定、传感器接入的GPIO设定、UART口的分配、EMQ后端定制的配置、Domticz后端传感器编号的配置等等；这里的配置项都是全局生效的。
MQTT-Thread：承载整个应用对外发送和对内接收的网络数据通道，告警信息的上报和传感器数据的上报，都深度依赖这个线程。
WiFi-Thread：本线程主要用于定时探测Wi-Fi网络的有效性，通过对网络设备节点的判断，为应用的其他逻辑功能提供一定的参考。
Sensors-Thread: 由于所选用的几种传感器都是同一类传感器，且都是IO类的传感器，所以通过列表的形式把他们定义在一起，方便轮询管理；主要的工作就是定时采集数据，判断是否有对应的传感器触发了告警。
Alert-LED-Thread：本线程要做的是事情就是在Sensors-Thread产生某一种或某几种告警信号后，里面通过LED的闪烁，达到以视觉冲击的告警目的。
Alert-Sound-Thread：本线程与Alert-LED-Thread线程类似，同样都是处理告警信号的对外传递，只不过它用的是声音的听觉冲击来达到告警的目的。它与Sensors模块通过邮箱来传递播报哪一条报警信息，这与Domoticz后端绑定的通知信息是对等的。
Key-Scan-Thread：这个线程需要做的事情，主要是当产生告警信号后，灯亮铃响时，可以通过按键来消除LED告警和声音告警，使得系统检测恢复到初始状态。
在软件设计过程中，所有涉及到线程间同步的机制，均采用信号量和消息队列来实现，主线程在这其中起到承上启下的作用。
总结一下，本次在使用RT-Thread操作系统的时候，使用到了其串口设备驱动、GPIO设备驱动、AT组件、SAL 套接字抽象层、信号量、邮箱等核心模块，整体使用上还是挺顺手的。
基本代码示意图如下所示：
4.2.2 Domoticz推送定制
这里主要的软件实现就是，就是将原本Domoticz中需要通过Email推送出去的消息，转到通过HTTP接口推送到微信中，从而关注了对应微信的人员就可以收到对应的告警信息推送。这里用到了一个python脚本实现HTTP接口，然后POST消息到微信中。
基础的改动代码正如下图所示：
4.3 私有化部署的 IoT 系统
这里提及的私有化部署，主要是将IoT后端系统部署在个人云服务器上，以便于通过公网快速访问；同时，由于是私有化部署，不受限于任何的IoT云平台，这对比外面普通对接阿里云平台、涂鸦云平台、微信云平台、小米云平台、百度云平台等等，是有一个的优势的；至少在个人家庭数据的沉淀和数据安全上，没有那么地担心。
这里的系统部署，包括几个部分：
EMQ的部署：
EMQ的部署相对比较容易，基本参照官方教程就可以完成，感兴趣的可以去了解他们的github开源仓库。
Domoticz的部署：
这里其实我是踩坑了的，下文的经验总结会细讲。总之，一开始各种不顺，后面推过一系列的摸索学习，决定采用修改Domoticz的源码，借助企业微信的推送功能，打通系统告警消息推送到微信的功能。
企业微信相关的部署：
从这里我们知道，要完成Domoticz的通知推送与微信消息推送打通，我们需要借助企业微信的应用功能，企业微信开放了相关的接口来实现这部分功能，感兴趣的可以参考下 官网的文档介绍，当然也可以参考下我采用的 引路文章。
WEB访问域名的配置：
当Domiticz在私有云服务器上部署成功之后，基本就可以通过公网IP加对应端口的形式，以HTTP或HTTPS的方式访问；由于IP和端口不容易记忆且容易拼错，所以才衍生了配置域名访问的需求，之前我配置过类似的功能，比如使用 http://yyds.recan-li.cn就可以访问我的CSDN主页，之前我写过类似的教程，基本参考教程一步步做可以完成相关的配置功能了。配置完的效果就是，我可以通过 http://smart.recan-li.cn 就可以访问Domoticz的WEB配置前端，而不需要输入繁琐难记的IP+端口了。
5 项目实施过程
主要实施过程如下所示：
1）搭建后端系统，先把EMQ这个MQTT broker搭建起来，使得终端和后端的数据通道得以建立起来；
2）部署安装Domoticz，可选用zip包解压安装或源码编译安装，但由于要定制化告警消息推送到微信，这里强烈建议使用源码级编译安装；当Domoticz安装运行起来后，其对应的SQLite数据库也是同步在工作的；这时WEB端的访问服务也是同步开启了；
3）通过Domoticz的WEB端配置，建立MQTT类型传感器，同时在平台建立与终端一一对应的虚拟传感器；这一步完成之后，便可以使用MQTT.fx等MQTT调试工具模拟对Domoticz上的虚拟设备进行状态推送，看其对应的状态是否会发生改变；
4）搭建企业微信的环境，包括创建一个企业微信账号，再在企业微信下创建一个应用，取得企业ID、应用ID和应用私钥；有这个要素之后，就可以使用微信推送的HTTP接口做消息推送的模拟测试；
5）再在Domoticz源码上集成应用HTTP接口推送（告警）消息到微信客户端的功能代码；
6）开发终端的固件，调试Wi-Fi通讯，MQTT上下行，以及各个传感器的工作；
7）需要关注微信推送消息的人员扫码关注企业微信中对应的应用，同时打开微信客户端的通知显示权限，这样当新的消息通过企业微信应用推送下来时，手机端就会弹窗提示；
8）终端工作起来，尝试触发一些告警状态，观察终端的处理逻辑和状态上报到Domoticz的数据更新，同时观察告警消息往微信客户端的推送情况。
通过上述一系列的实施之后，整个私有化部署的家用式智能告警系统就跑起来了，enjoy it !
6 项目效果显示
相关的展示图片和演示视频，见下文：
【项目展示图片】
【项目演示视频】见 B站视频。
【项目开源代码】n32g457_esp8266_smart_home
7 项目复盘
7.1 项目踩的那些坑
RT-Thread Studio的配置项摸索半天，想去搜索一下配置项，又不知何从做起，我是深度Linux环境开发者，平时一个grep能解决的事情，我不知道在Windows下有什么好的替代方案，慢不慢先不说，先得有。之前在Linux都是menuconfig，我始终觉得那个更亲切。知其然，也知其所以然。
ESP8266的固件烧录耽误老半天，上次RDC大会抽中的ESP-12F开发板，默认出来的lua版本，而非AT版本；由于RT-Thread的组件是需要AT版本的，于是找个好几个教程，费了好大劲才把AT调出来，期间各种下载失败（还是下载到90%才失败的那种），各种下载工具折腾，下载速度也慢；本来想偷下懒用ESP8266省事的，硬是折腾得想临时换模组。
ESP8266的AT是通了，但是编译个N32G457固件使用UART2带ESP8266，死活work不起来；无奈求助于RT-Thread，很快找到了论坛好友 crystal266 的 基于RT-Thread和N32G457的智能家居demo ，看到他已经完成了全部流程，应该可以为我所有，所以我借用他的配置代码，果然ESP8266的通讯能力一下子就拉满了。那种感觉好像，项目马上就可以结项了，丝滑地很。
Domotics的邮件通知功能，在最新版本上就是各个渣渣，还特意阅读了一个国外同行遇到的同样的问题，看了他们的issue沟通，然后依然没有任何思绪。一路执行，我放弃了stable版本的Domoticz安装版本（zip包直接拉起bin文件）转向源码自行编译编译，重新操刀在发送邮件通知的地方，把通知重定向发往微信里面。再次，感慨，开源大法好，任何字节细致都逃不过你的法眼！你想怎么玩就怎么玩！
具体如何修改相关的代码，可以参考上面的4.2.2小节。
Domiticz是我目前遇到编译开源软件，最蛋疼的一次，各种问题，真正的是走一步出问题一步，然后解决一步再前进一步，期间过程遇到各种奇葩问题，编译慢也是知道吐槽一下，所幸最后还是编译出来了，能够把它跑起来。
之前在配置Domoticz的邮箱通知功能失败之后，我考虑过使用它的SMS短信通知功能，无奈Domoticz的大神们都是国外的，给出的接口都是国外公司的，我想注册一个账号体验下，居然死活注册不成功！说好的技术无国界呢？放弃！
接下来各种搜索推送通知方案，短信、邮件、HTTP、语音等，了解了阿里云、腾讯云的各种相关服务，无奈要不是接口做的相对我来说复杂了些，要不就是功能不能很好地满足我的功能需求（提供的功能需求限制太多）；差点放弃了，后面被我检索到一篇关于企业微信支持开发者推送消息的文章，让我眼前一亮，心想这才是我想的为所欲为，这个太棒了。一个python脚本配置一下就可以轻松搞起来，你还能找到比这个更简单的吗？
微信推送算是搞定了，接下来的Domoticz的域名网址配置，又出问题了；之前我配置过使用http://yyds.recan-li.cn就可以访问CSDN主页的方法，我使用该方法依葫芦画瓢，设置了http://smart.recan-li.cn的域名访问Domoticz，结果却出现了nginx返回http502. 真是无可奈何。
终端侧的槽点倒是没多少了，但这样需要重点吐槽下 N32G457在RT-Thread Studio下使用pyocd.exe，时好时坏，有些郁闷。
好像N45G357这板子还有点脆弱，差点焊废了，差点芯片就起不来了！
最后一个不算是坑的点：使用RT-Thread开发IoT应用这种量级的代码，用起来还是倍儿爽，希望RT-Thread能把这份爽继续发扬下去。
7.2 项目带来的启发
DDL是第一生产力
我始终觉得我是一个无形之中在不断践行这个slogan的开发者，虽然我知道这个习惯真的很不好，每次在DDL之前总是付出比平常多几倍的时间和精力去努力完成既定的任务和计划，其实这个投入和产出是非常不正常也不科学的。所以，当我深刻意识到这点之后，我也会努力克制住平时的惰性，争取把时间计划做得更细致，把有限的时间最大化地利用，做一个生活和技术都自律的人。
优先解决主要矛盾
我刚入行的时候，带我的师傅经常跟我们说一句话：“先解决有没有的问题！”其实，跟这里说的优先解决主要矛盾是一样的，比如你搭这个智能化 IoT 系统，如何能快速搭建好产品原型，把终端侧的数据和后端打通，那首先你必须得解决终端侧联网的问题，这个就是优先级最高的，后端系统到可能不是最先的，你有网络之后，你可以先用一个本地的MQTT broker一样可以看到终端侧的数据上报，而数据端的采集、处理逻辑，我倒认为是最次要的；因为你在此之前，你完全可以模拟数据，你想要什么数据就有什么数据，但是最终在整个数据传到链条打通之后，终端侧数据的准确性及多样化的业务逻辑往往可以起到锦上添花的效果。
努力把你当那些 TODO 消灭掉
我相信每个人都有自己很多的TODO，但是往往程序猿的TODO又好像代码里的注释写的那种，不仅骗了自己，同时也骗了别人。而项目中的TODO往往就是那些需要优化，需要沉淀，需要突破的地方，就好像我这个项目一样，比如如何做好更好的用户体验？比如如何快速、准确地完成私有化部署？比如如何快速地迭代新的终端侧功能？比如这个产品有没有更大的潜在商业价值？这一系列的TODO往往才是核心竞争力的体现，只有把它们踏踏实实消灭了，才有可能带来新的台阶。
审核编辑：郭婷