谈一谈做嵌入式物联网设备端的心路历程~

前言

之所以想起这个话题，是因为2021年刚开始的时候一个朋友在微信里找到我，问起我最近所做的事情以及帮忙协助调试一些设备的问题，想起来也有好长一段时间没有做这个了。但是物联网行业的动态我却是一直在关注着，并且坚持着自己的爱好，也希望通过后面的一年时间里，自己能够培养动手能力，抽时间出来逐渐试试做做物联网小模块的整体方案，并且重新捡起画PCB、做3D打印模具、深入理解做物联网设备，尝试着去做一个物联网智能家居的整体方案的设计。

起源

起因就是因为16年智能家居这个话题非常的热闹，经过了互联网一波一波的浪潮的冲击之后，慢慢的风向开始转向实体的事物，那一年VR火起来了，谷歌眼镜也热门了一把，各种智能硬件仿佛可以让人们瞬间感受到科技即将给人们的生活带来非常炫酷的体验。那年我也买了一个8266的wifi模块，居然如此的便宜，而且还能够连接wifi上网，通过手机控制灯的熄灭和设备的动作。我觉得挺有意思，于是坚定的想要去做这样炫酷的东西。于是买了一些开发板自己玩，玩的挺开心，但是真正的找工作却发现没有什么公司做这个，大家还是做工业控制、做消费电子、做非联网的东西。为了工作、也只能把这份热爱留在心里。但是在那一段时间里，也在不停的关注WiFi、zigbee、nbiot模块等等，也会买一些过来自己玩一下。但实际工作中几乎没怎么用过。

后来，真正在工作中接触到物联网的一点东西是在18年左右，做智能锁需要用到zigbee模块，于是在调试zigbee的使用过程中，也慢慢的对物联网的产品有了一个基本的框架性的认识，包括数据的处理、数据的流向、以及各种低功耗模式的处理流程、模块与主控之间的协作流程，模块和网关之间的通信、网关又与服务器之间的交互，手机APP和设备的交互流程等等。通过这一段调试的经历，我学到了一个实际的物联网产品的业务逻辑，交互逻辑和效果优化设计的方法。同时也更加让我对物联网设备有着更加浓厚的兴趣。

由于主要做zigbee设备端、数据的流向顺序、接口的完整实现细节、以及服务器业务的数据分发、界面展示。这些其实并未向我完全透明出来，我在zigbee设备端上和网关之间建立起一定的联系。所以我也觉得这个是我的兴趣爱好，也是我一直想要去弄清楚弄明白的事情。

智能水表项目

由于一些不可预知的因素和巧合，我去做了一个智能水表的项目，这个项目实际上是做智慧运维的朋友让我去做这个项目。并且服务器和协议实际上是和智慧运维一致的协议和服务器。最开始是做智慧运维，运维就是对环保项目进行监控以及一些数据指标上传到服务器，并且可以APP去开启阀门或者水泵等等。

当时我记得接手这个项目的时候，是一堆的bug，各种控制失效、死机问题，定时控制也做不了。我看了一下代码，提出要改协议层的框架，因为我发现驱动和业务是混在一起的，所有的系统业务都是为了实现功能而拼凑起来的，我认为这是做物联网设备端程序的大忌，因为联网模块随时会变、现在用gsm，可能后面又会用4g模组，或者用nbiot等等，这样模块更换，代码又要重构，工作量大、而且效率也很低。上来就先做协议框架、按照黑盒模型、关注的只有输入、输出、暴露出来的都是函数回调接口，这样，当我需要去使用协议的时候，实现这个回调函数即可。通过这种方式，将协议重构了一下。

而后就开始做智能水表项目了，智能水表项目是新的需求，从确定要做开始，做选型、到方案评估、到软件评估、到编码、到测试、到交付、中间其实也就一个月时间。当时做的是在stm8l主控芯片上，外接一个移远的bc26模块，外接干簧管、驱动电机。当时的要求就是做到1ua以下，用干电池供电。最开始板子打样还没出来，我就用开发板做原型验证，写各种驱动，做低功耗、做bc26 nbiot方案的调试，查询信号、联网、数据发送、断电、低功耗唤醒。前期的原型验证做到差不多了，开始集成业务了，其实只需要把协议控制做到很好，业务逻辑其实跟着协议接口来就可以了，这部分已经积累了一些经验，所有也算是得心应手。这个项目中最难的是低功耗和服务器联调。低功耗的难点在于如何想办法将板子的功耗降低到最低，那段时间，一发现低功耗模式电流过高就需要请做硬件的拆电容或者电阻，做测试，拆下一个看能够降低多少，不断的尝试gpio的模式，这样才能将低功耗降低到最佳模式。而服务器的联调是没法沟通的，每次都要说一堆，做服务器的不懂嵌入式这边做什么，让他看一下连接上了没有，而做服务器的关注的是有没有数据。这个就很麻烦，沟通成本太高。所以干脆自己在本地搭建一个测试环境，自己发测试数据测试联网、断线、重连机制。没有问题后在对接服务器和端口。

一直到设备上线、到app可以控制为项目完成，智能水表做完后，实际的放到水表上进行测试，水流通过旋转齿轮，从而让干簧管的靠近磁体，引发计数操作。然后app可以控制水阀的开关。虽然这个项目只做了第一阶段的功能评测阶段，后面推广和销售我没有关注，我就去度假去了。但从整体的项目做下来，给我的最大的体验是设备端和服务器的沟通其实是有一些障碍的，物联网设备的业务逻辑，应该主要的放到服务器上去做，而设备端的响应其实大部分都是根据服务器给的具体的指令进行操作的，或者主动上报数据，给我的感受是，物联网项目的服务器业务量是要比嵌入式端复杂许多、并且多设备的并发量要能够处理的了才行。

智能标识项目

在19年时候，可以说我几乎是各种尝试的阶段、我认为我可以做的事情，我都觉得可以试试看。于是我尝试着入职了一家做物联网的公司，我记得我当时面试的时候问了一句话，我说公司做这个物联网项目是否真的可以盈利。当然得到的结论也和我预测的差不多，其实并不能盈利多少，只不过坚持着，物联网设备起来的那一天。

记得入职后的第二天，我就去了北京，因为当时有个大兴机场的智能标识项目，目的地就是北京大兴机场，去做项目做这么高端的项目刚去之前还是有点兴奋。对于智能标识，其实就是物联网项目中一个非常典型的应用场景，通过远程监控、远程控制、定时控制、数据统计来量化和控制电流、电压以及故障报警。一方面这个可以解决无人值守的问题，另外一个方面也能够将用电的数据量化，从而节省电量的消耗和使用。

调试程序的过程主要是做设备的协议控制，另外就是传感器数据的上传，由于用的是三相电，并不需要关注低功耗问题。另外这个项目的重点和难点在于ota方案与协议的扩展。当时做该项目、配合的人员挺多、有做设备端的、做服务器的、做app的、做前端的以及做运维的。每个人或者两三个人负责一块业务，大家由于都是刚毕业不久，所以休息的时候，就一起约出去去北京逛吃逛喝，虽然工作幸苦，但是有玩有乐足以。

业务的配合调试是一个连环的过程，设备端数据发送过来后，服务器需要有数据处理，然后交给另外一个服务端，这时app和前端通过服务器给定的端口，去按照指定的格式获取数据，获取到后做解析和显示。这部分容易掉链子。前端说没有数据，服务器可能会说是设备没有上传，结果设备上传了，服务器一查是数据阻塞了。反正这种问题每天都在发生，好在工作氛围很好，大家也非常的配合。而实际上我负责的云、端、管、台、这之中的设备端来说，关注的就是具体的传感器的参数的获取和上传，以及服务器下发指令的处理，另外就是ota方案，以及断线重连机制，这一部分耗费我大量的时间和精力去设计。而后有了更加稳定的程序输出。

总结

写这篇文章主要回顾一下自己做物联网的时候的心路历程，其实物联网的设备技术难度比我做的一些项目难度要低一些，但是我还是觉得这个是很有意思的一件事情。技术的高低并非是衡量一个事物好坏的唯一标准，其实真正的是一个东西给人带来的便利以及其蕴含的文化价值和社交属性。技术固然重要，我认为程序员也应该关注是自己的眼界和处理事情的能力，也需要时刻培养自己的动手能力，切忌眼高手低。

做了几个物联网项目，给我的感觉比较深刻的有以下几点：第一就是设备端的联网模块要处理好，断线重连机制要很完善。第二就是协议层框架要很清楚，一个协议做一件事，不要耦合太多业务。第三就是设备要绝对的稳定可靠长时间运行。第四与服务器的对接要有应答机制。第五物联网设备端的业务尽量的精炼简单。

物联网设备在当今的发展也没有想象中的那么热门，也没有普及到千家万户，但是也可以慢慢的看到其逐渐的出现在生活中了。车联网、物联网、智能家居等等，万物互联其实也并非什么难事。事物有着自身的属性、用传感器去检测和量化数据，通过数据去分析事物的规律。