物聯網版本的水控機：可以掃碼打水（微信，支付寶，電子錢包），以及刷卡打水，最多4個出水口，具有修改掃碼單價，刷卡單價，限額，脈衝數還可以在線充值。
要解決的問題：
- 刷卡以及掃碼達到限額（單次最大出水量），不能立即返回主界面，要顯示計量消費界面，讓客戶知道爲什麼水停了。
- 達到6s，流量計未計數，此時需要顯示流量計故障，刷卡時，是實時扣費的，這問題不大，掃碼是預付的，固定金額的。如果掃碼支付2元，出水1元，報流量計故障了。此時的結算包改如何處理，我這裏的處理是消費了多少，就上傳多少，服務器如何處理，返還還是喫掉，設備端不管。
流量計故障如何消除呢，刷卡容易消除，只要消費了就有結算，說明流量計跑數了，在結算函數裏給流量計好壞標誌置位0；如果是掃碼呢，掃碼也有一個結算，沒有消費也存在一個結算，固定金額和電子水卡都會出現類似情況，在掃碼結算時加一個判斷，如果有消費才置位0。本可以狀態包105，能夠實時上傳流量計工作狀態，流量計故障就顯示不可以掃碼支付。
流量計出現故障，置位1（定時器中斷裏置位，並且儘可能發送狀態包105，告知服務器這個出水口流量計故障，掃碼支付暫時不可用）。只能通過刷卡打水，成功結算清除流量計故障狀態。
3.刷卡出水過程中，如果掃碼支付，支付會成功，需要做的是，刷卡出水，要置位（因爲之前的bug目前實現較困難），
工作狀態是在制水中；掃碼出水中，本地已經禁止刷卡了。
工作狀態很重要：忙與空閒，掃碼以及刷卡觸發階段就要改變工作狀態，掃碼刷卡消費結束立即改變狀態；工作狀態是判斷設備能夠提供服務的充要條件。何時置位，何時清置位，類似malloc與free的關係，形成閉環，設備才能工作的順暢。
觸發階段：掃碼支付成功，這裏是回覆404。
如果是刷卡呢，會發個104，服務器會比對數據，禁止打水，充值都在此階段完成。這個階段咋改變狀態呢？按灌裝鍵發送一條狀態包，結算時在發送一條狀態包。出水時間很短，這2條狀態包發送間隔是不是很短，實際上，刷卡出水中，有誰那麼無聊會去掃碼支付呢？這個問題先保留。
4.刷卡板和4g通訊板不同時供電，可能存在登錄不成功；連上服務器不代表服務器能夠與設備通信，服務器要通過一個id(唯一標識符)查找連接的句柄，登陸包錯位，就能通信不上，雖然模塊指示燈在閃爍，解決方法是：4g模塊負責聯網，並且登陸包，心跳包，校時包也交給4g模塊直接發送。這樣燈快閃，服務器就能找到設備，單片機發送心跳包，存在個時序，id在刷卡板內。
5.離線數據處理：在網絡狀況不好的情況下，需要把消費記錄保存起來，半夜主動上傳，或者設備在線的狀況下，手動獲取離線數據。
6.4G模塊發送心跳包，校時包，登陸包由設備端發送，發送完，4G模塊緩存登陸包重要信息，當網絡不穩定時，4g模塊發送登陸包，因爲網絡不穩定，連接斷了，必須有登陸包，服務器才知道是誰連接上了他，心跳包裏有設備號也不行，必須先登陸包，建立一個認證，心跳包才認可，不然，發送心跳包服務器就會踢掉。
單片機代碼是C語言：採用時間片模式，週期是1s,各個任務函數時間點間隔125ms,一共6個任務，時間一共750ms,還有250ms作爲冗餘，以備某個任務超時。優先級採用傳統的 if else if 模式。不允許任何延時函數。保證單片機高效率掃描，兼顧到所有任務函數，任務函數的最大處理時間是可以模擬出來的。其實也可以基於freertos開發，個人覺得，沒必要，框架搭建好，幾個函數來回跑 ，問題也不大。rtos優點是大部分函數都封裝好了，搞個消息隊列，當個全局管理者，下面的任務時不時上報一下，這樣系統就像處於控制之中，操作時注意中斷裏能使用的，任務裏能使用的函數，就好了，至於任務的優先級，一般是中斷裏面最低的那個裏面切換的，還要注意一個概念可受系統控制的中斷節點範圍，裏面是可以用rtos的系統函數的，其他的中斷不受系統控制的是不能使用rtos的函數的，當成單片機的裸機開發就好了。
關於區域碼：能夠修改的有，服務器下發修改，默認值，僅此2種方式。