## 背景

在物聯網平臺的裝置資料接入場景中，開發者總是希望平臺接入的裝置資料格式標準統一，以便對資料進行統一處理。在實際情況中，由於業務需要，平臺常常會面對不同型別、不同廠商的裝置接入。即使裝置接入協議已經統一使用 [MQTT](https://www.emqx.com/zh/mqtt) ，由於 MQTT 協議中對 Payload 格式的寬鬆定義，應用開發者往往還需要針對不同裝置上報格式進行加工處理。尤其在已經出廠的存量裝置或是已經部署到現場的裝置對接過程中，平臺開發者往往無法要求裝置側按照平臺的統一標準進行資料上報。因此，平臺側對於裝置資料的統一化處理就成為開發過程中的一項重要工作。

## 裝置資料處理常用方法對比

使用全託管 MQTT 訊息雲服務 [EMQX Cloud](https://www.emqx.com/zh/cloud) 進行裝置資料接入的過程中，解決資料格式統一化通常有以下幾種方案。

### 資料透傳

透過 EMQX Cloud 接入資料後將報文透傳到應用側，在後臺業務應用中對各型別資料進行格式轉換與處理。這種方式相對最為直接，但對應用開發者最不友好。尤其在資料吞吐量比較大的情況下，後臺業務應用既要處理資料格式，又要完成業務處理，對業務端效能也會影響比較大。

### 透過規則引擎進行資料處理

EMQX Cloud 內建的資料整合規則引擎提供了基於 SQL 語言的規則定義與資料處理能力。開發者可以透過內建函式對資料格式和內容進行處理。這種低程式碼資料處理方式將資料格式與內容處理前置到訊息中介軟體層，為後臺業務應用開發提供了高效能、標準化的資料處理方式。但是受限於規則引擎的內建函式與方法，使用者無法實現邏輯相對複雜的資料處理需求，且規則引擎也不支援比較複雜的邏輯判斷。

### 最佳化方案：自定義函式

為了增強規則引擎資料處理能力，EMQX Cloud 推出了「自定義函式」增值服務。

使用者可以透過編寫基於 ECMAScript 5.1 及部分 ECMAScript 6 的語法的自定義指令碼實現資料處理邏輯，並在 EMQX Cloud 規則引擎中呼叫，這樣就可以完成更加複雜的資料預處理邏輯，並透過規則引擎將函式返回的資料按業務需求流轉至訊息消費方。

> 考慮到執行效能對整體訊息吞吐效能的影響，EMQX Cloud 提供的自定義函式會對執行指令碼進行效能檢查，指令碼執行時間**不能超過 3 秒**，否則將無法透過驗證。因此我們不建議在指令碼中編寫高耗時的操作。

## 在實際場景中使用自定義函式

下面我們透過幾個例子來看看自定義函式可以用於哪些業務場景。

### 資料編解碼

在裝置資料上報場景中，對於網路頻寬受限以及功耗敏感的裝置，在資料傳輸過程中往往會將裝置資料透過更加緊湊的十六進位制格式進行傳輸，以便節省頻寬和功耗。在平臺側，如果業務應用需要理解上報資料的具體業務意義，則需根據規約將十六進位制報文解析成 JSON 格式報文，方便應用開發。

**示例**

平臺需要接入一個智慧井蓋裝置，井蓋裝置需要定時上傳 4 個感測器資料，裝置透過十六進位制數格式上報到平臺，每兩個位元組代表一個感測器資料：

[![1](http://img.blog.itpub.net/blog/2022/12/15/49cd5f72f7b628f4.png?x-oss-process=style/bb "1")](https://www.emqx.com/zh/blog/data-codec-using-custom-functions "1")

我們透過自定義函式將十六進位制數轉換為有意義的 JSON 格式，方便後臺業務應用對資料進行消費。我們在 EMQX Cloud 中建立一個自定義函式：

[![2](http://img.blog.itpub.net/blog/2022/12/15/6f18b60507f482e9.png?x-oss-process=style/bb "2")](https://www.emqx.com/zh/blog/data-codec-using-custom-functions "2")

假如此時裝置上報資料為 00011601，Payload 作為入參進入自定義函式輸入為 { 0x00, 0x01, 0x16, 0x01}；我們以此輸入測試函式輸出，可以看到結果如下：
[![3](http://img.blog.itpub.net/blog/2022/12/15/c7c0c802adccb3f6.png?x-oss-process=style/bb "3")](https://www.emqx.com/zh/blog/data-codec-using-custom-functions "3")

這樣我們就可以透過自定義函式，將裝置上報的編碼資料格式轉化為更為易處理的 JSON 格式供後端業務應用消費。

### 資料格式處理

在裝置資料上報過程中，資料上傳通常會以比較簡單的格式進行傳輸，比如會按預設規定省略一些預設的資料與格式。但對於平臺側應用來說，一般需要能夠透過資料處理補齊相關的資料以達成資料格式的標準化。此時我們可以透過自定義函式來實現資料格式補齊。

**示例**

我們在辦公樓的機房內部署了溫溼度感測器以用來檢測環境資料，感測器透過 MQTT 協議以 JSON 格式的Payload 上報報文到雲端平臺。資料包文格式如下：

```ada
{
  "hum" : 20.0,
  "temp" : 36.5
}
```

我們希望透過自定義函式對每個上報報文進行單位的補齊，這時可以透過定義如下函式來實現：

[![4](http://img.blog.itpub.net/blog/2022/12/15/5aaab71352aa894d.png?x-oss-process=style/bb "4")](https://www.emqx.com/zh/blog/data-codec-using-custom-functions "4")

透過函式測試我們可以看到，輸出的資料被新增了相應的單位格式：

[![5](http://img.blog.itpub.net/blog/2022/12/15/8aa15fcf92eca340.png?x-oss-process=style/bb "5")](https://www.emqx.com/zh/blog/data-codec-using-custom-functions "5")

這樣，我們就完成了對上報報文的格式轉換工作。

### 資料告警

除了透過函式處理報文格式外，我們也可以透過邏輯判斷實現業務告警。雖然 EMQX 提供的規則引擎也可以進行簡單的數值判斷，但是相對複雜的邏輯判斷與資料處理更適合在自定義函式中進行。

**示例**

沿用上一個場景的裝置資料，我們可以透過判斷溫度與溼度是否在正常工作狀態來設定告警資訊。比如機房的正常工作溫度在 15 到 40 攝氏度之間，溼度在 30% 到 60% 之間。我們就可以透過在自定義函式中進行判斷後，對超過工作溫溼度的上報資料進行告警處理。

[![6](http://img.blog.itpub.net/blog/2022/12/15/f012bd5e86f27fde.png?x-oss-process=style/bb "6")](https://www.emqx.com/zh/blog/data-codec-using-custom-functions "6")

如果我們從感測器上報的實時溼度超過工作範圍，我們將得到告警資訊。

[![7](http://img.blog.itpub.net/blog/2022/12/15/66087e6c661e90f4.png?x-oss-process=style/bb "7")](https://www.emqx.com/zh/blog/data-codec-using-custom-functions "7")

這樣，後臺應用就可以透過輸出的 Warning 資訊來進行業務告警處理。

另外在 EMQX Cloud 規則引擎中呼叫自定義函式可以支援多個入參，比如 Topic、ClinetID 等。使用者可以結合各種裝置與主題資訊進行對報文的加工與處理，在此不一一贅述。

## 結語

物聯網裝置接入的業務場景紛繁複雜，EMQX Cloud 提供的自定義函式功能為廣大物聯網開發者提供了更加靈活的資料處理方式。使用者可以在自定義函式中實現相對複雜的資料處理邏輯，透過 EMQX Cloud 服務快速部署函式與裝置資料和應用對接，大大提升開發效率。

有關自定義函式的具體使用方法，請參考 EMQX Cloud 官方文件的[相關章節](https://docs.emqx.com/zh/cloud/latest/vas/codec.html)。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/data-codec-using-custom-functions](https://www.emqx.com/zh/blog/data-codec-using-custom-functions)

使用自定義函式實現資料編解碼、格式處理與業務告警

相關文章