Note: Protobuf with MQTT

這幾天在寫實際的Protobuf + MQTT 的程式, 今天重新編了,  Paho C/C++ library 後, 在Windows上終於連到 broker.hivemq.com 這個公開用來測試用的Server, 目前看起來工作正常, 但是這讓我開始有一個疑慮, 如果用Protobuf這種序列化/反序列化的程式庫, 那是否會有那種隱含的安全問題?  應該只能用安全連線的通訊環境下吧? 不然光是處理檢查進來的Stream是否合法安全就搞不完了.

做Demo 還是可以用這種公開的Broker server, 實際商品化就必須採用login/password, 跟SSL的Server, 這樣的話MQTT本身的payload加不加密也就不重要了, 或是將message本身加密, 能正常解出的也代表是 Trusted ? 也應該是一種方式。

另外 hivemq 的Websocket for Browser 當message payload 不是用json/text格式的話,  應該是收不到訊息的, 不知道是底層就收不到還是上層 因為解不出 Text就是不會有反應, 所以早期開發如果要方便除錯採取json 還是一個比較快的方式

 

廣告

Note: About MQTT

本來上週末在看gRPC 想說先做單對單的設計展示之後上雲的可能性, 但是計畫趕不上變化, 老闆找了大老闆展示部門之前做的東西跟未來要做的東西後, 大老闆明顯想要的是直接上雲可以一步到位展示給終端客戶推廣的東西, 因此需要重新構思設計方向, 做了一下技術選擇, 應該還是MQTT比較合適, 而且目前有明確需要上雲的東西

目前看了一下主要就是Device 需要設計 publishes 的Topic 跟Payload, 還可以設計 subscribe topic, 讓遠端傳遞控制命令

找到一篇算是很不錯的基本文介紹 MQTT Topic and Payload Design Notes  還加上他有一篇 payload 加密文 How to Encrypt MQTT Payloads with Python – Example Code 剛好都是我能做的, 剩下就是構思實際使用的Topic結構設計 說是Topic 實際上這也是一種Service API設計

另外 HiveMQ 除了提供企業級的MQTT的各種服務外也為了推廣業務寫了一堆基礎介紹好文

MQTT Essentials

可能是我資質不夠吧 XD本來看了幾篇中文介紹跟範例都抓不到實際使用的好方法, 反覆看了幾篇實際案例後 才腦洞大開知道怎樣用才對, 下週如果沒有其他外務打擾應該可以先做一個demo 給老闆看, 然後再繼續做UI 跟著做Web Service

不過個人覺的MQTT這種用法還是有點浪費頻寬, 雖然對開發過程友善,  但是每次要把已經知道的結構都傳一次, 不能設計一種先傳 meta structure,  然後後面直接用reference 的設計嗎? 不過好像最近有MQTT 5.0 的protocol release 不知道會不會有, 不過meta struceture 設計變成後面加入的訂閱者會收不到,  但是如果加入類似Service Discovery 去跟Broker 查詢應該就可以克服, 不過這樣Broker 負擔會變重就是了

Note: Windows 10 IoT core

這個目前還是有一些工控領域有對應市場, 然後很多應用不用royalty fee 所以會有經濟誘因,

不過對於技術人員來看, 做這個image 開發有點介於以前的Windows Compact Embedded 但是大部分接近於原生Windows Embedded 的image build 工作, 簡單講就是客製化的彈性相對少很多, 會極度趨近原生Windows

需要 ADK/WDK 要一致的版本編號 確保OS API/DDI的變化, 這樣變成如果商用有不同版本需要維護會需要切換安裝版本, 應該可以透過環境變數控制, 這需要測試一下

然後 Image 這時簡單分為開發與測試用的Test, 跟實際出貨的Retail

buildimage ProductA Retail/Test

Image 的產生流程可以參考IoT Core manufacturing guide

ref.

Note: golang with docker

Docker 這幾年對於各種運維很流行,實際上在開發各種嵌入式裝置與Android BSP維護上也會遇到很多相依性問題,這一兩年也看到越來越多公司開始採用 Docker 去維護開發環境了,尤其當你需要多地協同開發時,與第三方客戶或是夥伴開發更是如此,可以透過設定好的Dockerfile 去做開發環境的維護,降低各種溝通與反覆試誤的成本。

這裡舉一個 台灣工控一哥的例子 可以看到連結內有許多不同OS版本對應的不同開發環境,這樣你開發的環境不用去管理各種不同版本的套件相依性問題,對客戶跟第三方合作廠商都可以快速的發布,對於有多樣客戶是一個相對省力的支援方式

因為IoT Era 的到來,今天測試一下Docker 做Golang 開發

底下是一個 golang with git, gcc and make 的Dockerfile,用的是Alpine distribution, 要改成其他Distribution 也可以, 官方有Debian可選 , 可以直接用Docker pull golang:$tagname 之類的方式去拉下image
下面是我新增git & make & gcc 的開發用Dockerfile

FROM golang:1.10.1-alpine

RUN apk add --no-cache git make gcc

ENV GOPATH /go
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH

RUN mkdir -p "$GOPATH/src" "$GOPATH/bin" && chmod -R 777 "$GOPATH"
WORKDIR $GOPATH

然後可以參考官方文件的Docker-compose 去結合其他service 像是資料庫PostgreSQL
這樣可以開發一些Microservice 來做一些應用,需要水平擴展時可以加上反向代理等等,做現在所謂雲端的開發

如果想放像DockerHub 讓大家都可以使用你的Dockerfile 也可以參考工控一哥的這篇

透過上面的Dockerfile 可以用docker build 變成image 我這裡用 docker tag 改成 mygolang
透過docker image ls 可以看到下面狀況

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
mygolang            latest              2da237294097        2 hours ago         475MB
golang              1.10.1-alpine       52d894fca6d4        5 days ago          376MB
postgres            9.6.8-alpine        b27674feae2a        6 weeks ago         38MB

然後建一個 docker-compose.yml 如下, golang 那區塊應該有點問題還需要更正

# Use postgres with golang
version: '3'

services:
    db:
        image: postgres:9.6.8-alpine
        restart: always
        ports:
            - "5432:5432"
        environment:
            POSTGRES_DB: dev
            POSTGRES_PASSWORD: IdQuivgebobr9Dra
            POSTGRES_USER: postgres
    go:
        image: mygolang:latest
        ports:
            - "8080:8080"
        working_dir: /go
        depends_on:
            - db
        links:
            - db

然後下 docker-compose up -d 這樣會出現

Starting mydocker_db_1 ... done
Creating mydocker_go_1 ... done

在接著用 docker-compose run go 重跑一次mygolang 這樣就可以開始開發相關service
透過 docker-compose ps 可以觀察到下面 container status

      Name                     Command              State            Ports         
-----------------------------------------------------------------------------------
mydocker_db_1       docker-entrypoint.sh postgres   Up       0.0.0.0:5432->5432/tcp
mydocker_go_1       /bin/sh                         Exit 0                         
mydocker_go_run_1   /bin/sh                         Up

Update: 這篇還沒整理完,參考 Where and how to persist application data 可以知道應該透過Volume/Bind 跟Host的目錄連結,這樣才能持續開發並且不增加container 需要在花一些時間整理
至於一些使用Docker 快速提示可以參考這個 docker cheatsheet

Note: MyDriving/Azure

台灣近年某些產業很喜歡跟著潮流走,一堆公司目前花各種資源投入物聯網或是車用電子,如車聯網的應用(fleet telematics),Microsoft 當然不會錯過這種議題,早在2016為了展示他的Azure 就有出現一個 Azure Samples Demo – MyDriving 用來協助展示他的Azure功能,翻了一下,它可以讓新創快速參考打造一個展示系統,可以用來展示給終端客戶去吸引合作機會,不過就是很基礎的功能實作出來,如果要實際應用在現實場景還是需要不少資源去客製化,但是可以幫助想踏入這個領域的廠商快速有個概念與做業務展示去擷取眼球爭取曝光
Update: 後來讀了他的 Reference Guide , Microsoft 的PM 也很清楚的說這是起點,然後系統架構圖等等也很清楚簡單的畫出來,這好像是台灣競爭落差的感覺

不然如果從GIS等等搭建起可能需要付出數倍資源與時間

Note: HockeyApp SDK for Mobile/IoT devices

剛注意到 Azure 目前提供一個Free servcie, 叫做 HockeyApp 他是用來管理Mobile Device上面的App, 透過它OpenSource的SDK 去整合到自有的App裡面,然後使用Azure內的Service 去做本身App的管理, 主要有下圖的功能

Distribution(Update)/Crash Report/User Metrics 算是可以再這物連網時代,幫助中小型公司快速打造自有產品的好服務,可以節省很多時間與金錢去打造原型產品,而且支援常見的Android/iOS/Windows 平台

Note: IOTA with Industry 4.0 的一些想法

最近在看IOTA 的一些東西,今天早上突然有個想法是應用IOTA 的帳本紀錄在工業4.0上面,假設有個工廠想要導入IOTA相關技術到生產管理上面,實際上需要建立一個或多個Full Node 目前IOTA提供的參考實作 IRI 是透過JAVA EE 寫的,個人覺的他有一個缺點是JAVA EE 本身需要比較大的計算資源,可能的話我個人覺的是在工廠的生產場線場景,透過各種IoT Gateway 執行這個Full Node 功能,這時選擇比較輕量架構應該是一個降低整各應用場景成本的,例如用Python/Go/NodeJS/Rust 等等語言去實現這個FullNode

而考慮應用場景的後續管理維護問題Full Node 與IOTA Devices(Wallet)也需要應用上 Neighbour Discovery Protocol,這樣才有可能達到快速佈建與減低後續維護管理的成本。

再來IOTA Deivce需要自動產生 Seed 並且隔離在應用層,這個應該可以應用目前 Trust/App OS 分離的設計,透過MPU/Hypervisor/TrustZone … 等等技術去隔離

當然以上是考量用比較小的成本去執行,昨天還看到對岸某各機器人公司用ROS做的設備那些東西的成本可以忽略執行IRI成本,但是考量後續管理維護成本其他東西還是需要補齊,考量初始裝設成本跟後續維護成本的比例實際上這裡初始裝設只佔比較小的部份