20151212_jeffrey - silenceuncrio/diary GitHub Wiki

Index

  • 0930 survey LuCI2
  • 1010 summaries for our current IoT Platform
  • 1055 reply to mail from Pioneer: Re: [Share]issues for openHAB gateway solution.
  • 1130 reply all at mail to share IoT Protocol: Re: [Share]issues for openHAB gateway solution.

0930

一早起來看到 LuCI2 (OpenWrt web user interface)

For years OpenWrt was using LuCI, a web user interface written in Lua. It required several Lua extensions (like ubus, luci.model.uci, nixio.fs, etc.) to access system info and settings. Unfortunately this solution appeared to be quite resource consuming and didn't work well on devices with slow CPU and little amount of RAM.

This lead to developing LuCI2, a new web interface with a different architecture. It doesn't use Lua anymore, but static HTML page and JavaScript XHR method. It means building HTML pages is done on client (browser) side offloading OpenWrt device. To access any kind of system data ubus is used (with the help of uhttpd-mod-ubus to provide HTTP based API).

LuCI2 is still experimental. Its predecessor is still used by default in all builds, including the trunk.

關鍵的一句打消了我最近對 Lua 的衝動

Unfortunately this solution appeared to be quite resource consuming and didn't work well on devices with slow CPU and little amount of RAM.

塞翁失馬 焉知非福 我看到了 ubus (OpenWrt micro bus architecture)

To provide communication between various daemons and applications in OpenWrt an ubus project has been developed. It consists of few parts including daemon, library and some extra helpers.

The heart of this project is ubusd daemon. It provides interface for other daemons to register themselves as well as sending messages. For those curious, this interface is implemented using Unix socket and it uses TLV (type-length-value) messages.

To simplify development of software using ubus (connecting to it) a library called libubus has been created.

Every daemon registers set of own paths under specific namespace. Every path can provide multiple procedures with various amount of arguments. Procedures can reply with a message.

The code is published under LGPL 2.1 and can be found via git at http://git.openwrt.org/project/ubus.git. It's included in OpenWrt since r28499.

  • Command-line ubus tool

    • list
    • call
    • listen
    • send

  • Access to ubus over HTTP

    • There is an uhttpd plugin called uhttpd-mod-ubus that allows ubus calls using HTTP protocol.
    • Requests have to be send to the /ubus URL (unless changed) using POST method.
    • This interface uses jsonrpc v2.0 There are a few steps that you will need to understand.

哈哈 我糗了
現成的 JSON-RPC 2.0 Specification 就可以用了
不過影響的局面應該僅限於使用 openWrt 的 Device 的腳色
就是 IoT Platform 的 Control Center

至於處長問及的 RESTful 實現效能的部分
這應該要看 openWrt uhttpd 的效能即可

官方已經給出的解答 Nginx

Nginx is a high-performance http-server with other functions as well. It is a perfect candidate to run on OpenWRT due to the performance and memory handling.

這會產生 port issue

Of course there will be port issues if you installed LuCI before or after nginx, since LuCI package installs uhttpd, which also wants to claim port 80.
So configuring and/or portforwarding may be neccessary.
There are ways to run LuCI with another http daemon but that is not coverd here.
For a quick fix, just change the uhttpd port to something else in /etc/config/uhttpd.

不過目前應該是將 nginx 不要在 80 port 啟動
80 port 就留給原生的 LuCI(uhttpd) 來提供 web service
nginx 在 8080 port 啟動
專門服務來自 control box 的 event

至於 8080 port 的 nginx 要不要搭配 ubus 就是另外的 issue 了

80 port 的 LuCI(uhttpd) 是 Control Center 提供給 UI 的服務

1010

ubus 畢竟是 for LuCI2 用的
我們 IoT Platform 的 RESTful HTTP 就別去湊熱鬧了

幫 Control Center 做個現階段的結論

  • RESTful API for Control Box
    • nginx running at port 8080
    • using c to write cgi
    • 跟前端的服務 port 80 分開
    • nginx 效率高
    • request 採用 POST 的話效率更高
    • response 不帶 JSON 的話效率更高
  • CGI for UI(Web, Android APP, iOS APP)
    • uhttpd running at port 80
    • LuCI
      • 目前內部直接利用現有的 openWrt web, 但 lua script 是明碼
      • 量產時再改成 cgi
    • LuCI2
      • 因 lua 只拿來內部開發使用, 所以不考慮目前偏實驗性質的 LuCI2
    • cgi
      • 用 C 寫完再編譯, 保護公司智慧財產權, 體積小, 適合 CP值高的 Control Center 開發

1055

jeffrey 於 2015/12/12 上午 10:52 寫道:

Dear Pioneer,

謝謝您寶貴的建議

我先就 RESTful experiments 的部分做個說明
希望節省大家寶貴的時間

談到 RESTful HTTP 的效率問題
跟 RESTful 無關
而是跟 HTTP 有關

而談到 HTTP Server 的效率
openWrt 預設的 Web server 是 uhttpd 跑在 port 80 上

我們的 Control Center 如果要使用 HTTP 的話
建議採用官方推薦的 Nginx

Nginx  
Nginx is a high-performance http-server with other functions as well. It is a perfect candidate to run on OpenWRT due to the performance and memory handling.

我的建議

uhttpd 繼續提供跑在 port 80 上提供前端的 UI 服務
因為之後的 automation rule 也是要透過前端的 UI 服務來做新增修改套用的動作

Nginx 跑在 port 8080 上
專門用來服務來自 Control Box 的訊息

效率要更高的話
來自 Control Box 的 HTTP 的 request 也不要帶 JSON
直接使用 GET 或 POST 即可
這樣 CGI 執行效率也高
不用去解析 JSON 字串

Control Center 的 HTTP response 也不要帶 JSON
就利用現成的 HTTP error code 即可

下星期我會開始做 Nginx 的實驗

BR
Jeffrey

沒想太多就回了 email
有點上火

不過承受後續的壓力也是加速我對 IoT 的動力
繼續困在 PROSCEND 我需要的是動力
不管是好的或不好的我都要加以利用

1130

jeffrey 於 2015/12/12 上午 11:27 寫道:

Dear All,

跟各位分享這一篇文章

物聯網協議比較

文章中提到了目前關於 IoT 的 Protocol , 較為常用有下列四種

  • CoAP
  • XMPP
  • RESTful HTTP
  • MQTT

CoAP 是 UDP 的關係肯定效率最高
下面文章可以參考
CoAP學習筆記——IETF文檔和 draft文檔

openWrt 上要用 MQTT 的話, 可以用 mosquitto 連 shell command 都有

我的建議

一勞永逸的作法就是用 CoAP
效率最好

不過門檻較高
學習成本會比 我們自訂的 RESTful HTTP 來的高

如果要投資時間的話
我的建議是

Jeffrey 來看 CoAP
Jammy 來看 MQTT, 因為 openWrt 已經有套件 mosquitto

這樣的話, 二月底的 demo 就要重新考慮了

BR
Jeffrey

這個節骨眼我不能再藏私了
索性將情報丟出去吧

扛著被討厭的眼光我也要衝阿

1215

寶貝老婆看完我的日記後給了不錯的建議

第一階段就繼續用 RESTful HTTP
這樣學生們負責各自的感應器才能夠在二月底拿一個 prototype 出來

業務看到東西放心了 我一個人再來將 Control Center 和 Control Box 改成 CoAP

1355

剛剛跟寶貝老婆吃飯時也對 openHAB 有了想法

Control Center 要使用 openHAB 的代價是要有 JVM
現階段負擔太大, 非常不建議使用
老闆甚至想用 VR268(170, 579, 52xx) 的平台

目前建議就是用跟大股東一樣的 AR9531
目前我手上有 AR9331 的開發版擋著先
都是 openWrt

openHAB 不是放棄
等第一階段的 prototype 出來了
業務心比較定了
我們可以讓 Control Box 也支援 openHAB
反正 Control Center 賣一台
Control Box 賣好幾台

2010

今天一整天都蠻上火的
不過回顧了早上寫的
覺得還蠻禮貌的阿

可能是把自己寫完上火了吧
不然口氣是蠻 peace 的

不過第二段到真的是有點發散了
只是這是自己為了搶到 CoAP 和 MQTT 的情報先機
這才有的面子嘛