談一談做嵌入式物聯網設備端的心路歷程~

前言

之所以想起這個話題，是因爲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方案，以及斷線重連機制，這一部分耗費我大量的時間和精力去設計。而後有了更加穩定的程序輸出。

總結

寫這篇文章主要回顧一下自己做物聯網的時候的心路歷程，其實物聯網的設備技術難度比我做的一些項目難度要低一些，但是我還是覺得這個是很有意思的一件事情。技術的高低並非是衡量一個事物好壞的唯一標準，其實真正的是一個東西給人帶來的便利以及其蘊含的文化價值和社交屬性。技術固然重要，我認爲程序員也應該關注是自己的眼界和處理事情的能力，也需要時刻培養自己的動手能力，切忌眼高手低。

做了幾個物聯網項目，給我的感覺比較深刻的有以下幾點：第一就是設備端的聯網模塊要處理好，斷線重連機制要很完善。第二就是協議層框架要很清楚，一個協議做一件事，不要耦合太多業務。第三就是設備要絕對的穩定可靠長時間運行。第四與服務器的對接要有應答機制。第五物聯網設備端的業務儘量的精煉簡單。

物聯網設備在當今的發展也沒有想象中的那麼熱門，也沒有普及到千家萬戶，但是也可以慢慢的看到其逐漸的出現在生活中了。車聯網、物聯網、智能家居等等，萬物互聯其實也並非什麼難事。事物有着自身的屬性、用傳感器去檢測和量化數據，通過數據去分析事物的規律。