Cloud Of Smart Home

来自Jack's Lab
2015年1月15日 (四) 11:25Comcat (讨论 | 贡献)的版本

跳转到： 导航, 搜索

目录

1 概述

专为智能家居而生的物联云

服务于各类爱好智能家居的宅男宅女，他们爱动手、爱思考、对隐私和家居安全敏感

1.1 HOME

一个 Home 下可有多个设备 (device) 和多个家庭成员 (member)

Home 用一行描述，当前状态用一个 JSON 结构，包含所有member，controller，sensor 的状态，写在 stat 域里

家里新加的传感器、控制器、成员，可在APP里直接选择用 Home 的 UUID push 数据和状态，在参数里，写上name，type，数据等，云端首先遍历下级node列表，识别是否已有同名的设备，没有则为其创建新 node，并加到 node 列表里


家只关心，成员、控制器和传感器的状态，因此都写在 stat 域里即可。各下级node更新状态时要记得更新其在上级node之stat 域中的数据值 

name, type, up_nodes, down_nodes, state, uuid, meta:{}

meta: {
    mac:"aa:bb:cc:dd",
    ip:"123.11.1.1",
    activate:1,
}



1.2 Device

设备是传感器 (sensor) 和 控制器 (controller) 统称。客厅大灯是一个设备，当然他只是一个控制器，因其主要响应用户的控制行为。客厅的温湿度检测也是一个设备，实际他是一个传感器，因其主要负责收集数据。贴于门窗上的门磁也是一个传感器设备。

但悬挂于天花板的火灾烟幕报警器和安装在厨房的燃气泄漏报警器也是设备，但他们就既是传感器也是控制器


传感器的值、控制器的状态都写在 stat 域里，方便设备 check 以实现远程控制。每次push 的数据或状态则写在 datapoints 表里，带时间戳，方便呈现和日志检查

同时带有多个感应和多个控制的设备，也用一行描述，当前状态用一个 JSON 结构，写在 stat 域里


设备新加的传感器、控制器，可在APP里直接选择用 Device 的 UUID push 数据和状态，在参数里，写上name，type，数据等，云端首先遍历下级node列表，识别是否已有同名的设备，没有则为其创建新 node，并加到 node 列表里 


name, type, up_nodes, down_nodes, state, uuid, auth:{}, meta:{}, trigger:{}

meta: {
    product: "camgo",
    activate: 1,
    rom: {
        version:"1.0.2",
        latest_version: "1.0.5",
        url: "/v2/roms/camgo.1.0.5.bin"
    },
    mac: "XXXXXXXXXXXX"
}

auth:{"pubkey":"XOIO1234", "algo":"xx", "seed":"12345" }

trigger: {
    wexin:{root:wx_user1, users:[wx_user1, wx_user2...]},
    "166745":{msg:"家里大门开了", wexin:{root:wx_user1, users:[wx_user1, wx_user2...]}},
    "139225":{msg:"客厅阳台门开了", weixin:{root:wx_user1, users:[wx_user2, wx_user3...]}}
}

state: {
    value: {x: 12, y: 12, z: 12, k: 22, l: 33},
    deliver_to_device: 0
}



1.3 Member

对于一个家庭成员追踪设备，则各人智能手机为感知端（用户可选择是否定时上传 GPS/GSM 数据），加一些虚拟控制器，比如 weibo 推发器


stat 描述有 member 的坐标、体重、心率、运动量等等数据。如新买一血氧的设备，想要关联到 member，可用member的 UUID 生成 Token 来 push 数据，在参数里，写上name，type，数据等。云端会首先向 datapoints 记录一条记录，然后取 member 行（位于 Node 表）的 stat，解析后，将新数据域加入。


微信可以抽象为控制器；微博也可以抽象为控制器

手表/手环的消息提醒，振动提醒等也可以抽象为控制器 


name, type, up_nodes, down_nodes, state, meta:{email, password, weixin, weibo, mobile, imsi}, uuid, pub_key

state:{
    coords:{lat:123, lng:234}, cell:{mcc: 460, mnc: 0, lac: 123, cid: 456}
}



1.4 Trigger

每次 push 一个 state，云端检查一下相关的触发器，条件满足则执行相应的动作

注意：作为一个安全的云的必要设计，改控制器状态由家庭设备或家庭成员的手机完成，加密过后的数据，云端无法解读，因为加密在家庭设备端用私钥完成，云端无法解密，也就无法更改控制器状态


一个 Trigger 描述为： 

trigger: {
    "default":{msg:"默认消息", wexin:{root:wx_user1, users:[wx_user1, wx_user2...]}, alarm: 1},
    "166745":{msg:"家里大门开了"},
    "139225":{msg:"私房们开了", weixin:{root:wx_user2, users:[wx_user3]}, alarm: 1},
    "fun":{cond:"x>1 && y>3", action:[{weixin:{}},{controller:""}]}
}




1.5 Action Sets 

id, timestamp, action, processed

action: {
    msg: 客厅阳台门开了，
    weixin: [u1, u2, u3 ...]
}



1.6 Node

HOME, Device, Member 统一编号，皆可抽象为 Node （节点）

每个 Node 都有唯一的 UUID，用来与云端交互

每个 Node 带有 id, name, type, stat, up_node, down_node, uuid, ext1, ext2


Home 类型 为 0x10

Member 类型为 0x20

Sensor 类型为 0x40

Controller 类型为 0x80

Device 类型为 0xC0





2 框架

首先在 Web UI 下创建 Home，生成密钥对（界面自动生成一对，也可本机开源工具生成，然后将公钥填入Web UI，此为社交需求，可授权云端解密给家庭信任的用户，也可不上传公钥，这样云端永远无法知道家庭的状态）


云端只存储家庭成员加密过的控制器状态、传感器值（可加密可不加密）和家庭成员定义的任务事件（触发器，外网相关，比如发微博，发微信，发邮件，发短信等。改控制器状态由家庭设备或家庭成员手机完成），加密过后的数据，云端无法解读，因为加密在家庭设备端完成，云端无法解密，也就无法更改控制器状态

家庭私钥只有用户自己保存，私钥不在公开的网络上传输，云端也不存储。没有私钥就不能产生加密的状态值，控制器也就无法改变状态


控制器设备只要每 1s 去取一下云端的控制器状态值，回来解密，检查是否需要响应家庭成员的要求


---

设备、感知端、控制端 之间的关系为松耦合，即：一个设备可以只有一个感知端（只作数据呈现），或者只有一个控制端（只接受控制指令）；一个感知端可用于多个设备，一个控制端也可为多个设备所用


简单如一个体重称，可作为只有一个传感器的设备

一个家庭灯光设备，可以有多个环境光强传感器，声控传感器（亦可作为其他设备的输入，比如窗帘控制设备），甚至手势传感器，控制器则对应各房间灯的开关




3 Open API

3.1 Activate

激活就是告诉云端：生产的设备已经联网并能正常工作了


CamGo 的设计：(X1)
方案一：

每个设备都有一个唯一的串号 SN，写在二维码里

扫描二维码，APP会获取 SN，APP自动生成一个密钥对，用私钥将 时间戳和SN 加密后，作为调用 Activate API 的一个参数，另一个参数是生成的公钥 x-key


方案二：

设备的串号 SN、KEY 和 MAC 写在 eeprom 里

update state 时，用 SN + KEY 生成动态 token，云端检查 token 验证合法身份

用户关注公众号绑定看门狗后（扫描二维码或手工关注后绑定），视为激活，此过程可从 weixin agent 调用 Activate 接口 


{"weixin":"userid"}

云端收到后，首先解析设备node_row 的meta->activated域，为1视为激活，再解析 trigger 域，
有 weixin->root 则视为激活过，此时添加的 weixin 用户，置于 weixin->user 列表里


---

mini 的设计是这样：(M1)
方案一：

启动 APP，APP自动断开原WiFi的连接，搜索 miniCamGo 的AP，自动连接（内置密码)，最好能做到将用户手机里存的AP直接配置给mini

配好后，APP自动生成一个密钥对，发给 mini，mini 收到后，保存，向用户返回 SN，APP用此生成一个微信二维码，供用户向家人分享

APP 断开和 mini 的连接，用私钥将时间戳和SN 加密后，作为调用 Activate API 的一个参数 Token，另一个参数是生成的公钥 x-key


方案二：

用户启动 APP，APP自动断开原WiFi的连接，搜索 miniCamGo 的AP，自动连接（内置密码，可以设计为无密码)，将 AP 的 SSID 和密码配给 miniCamgo

miniCamgo 能通过 wifi 第一次访问激活接口，就视为激活 

{"activate":1}


---


首次调用activate接口的，拥有设备的最高权限，用户设置一个分享码（不设系统默认生成）

随后扫描的，需输入分享码，才能拥有这个设备的使用权（APP 如检测到其和拥有者使用相同的 AP 热点，可不用输入分享码）


激活时以路由的MAC地址为关键字，创建HOME且与SN关联；以用户手机的imsi为关键字，创建USER且与SN关联 


/v2/node/activate

# cat post-activate1
POST /v2/node/activate HTTP/1.1
Accept: */ *
nodid: BFEB5E8E2BD9A79531Q
token: 15F7E14203AD318B0AB05514A6BD5B072830A076267C66E2X
Content-Length: 19
Content-Type: text/html
Connection: close

{"weixin":"comcat"}

# cat post-activate2
POST /v2/node/activate HTTP/1.1
Accept: */ *
nodid: BFEB5E8E2BD9A79531Q
token: 15F7E14203AD318B0AB05514A6BD5B072830A076267C66E2X
Content-Length: 17
Content-Type: text/html
Connection: close

{"weixin":"gaga"}

# cat post-activate3
POST /v2/node/activate HTTP/1.1
Accept: */ *
nodid: BFEB5E8E2BD9A79531Q
token: 15F7E14203AD318B0AB05514A6BD5B072830A076267C66E2X
Content-Length: 14
Content-Type: text/html
Connection: close

{"activate":1}

# cat get-activate
GET /v2/node/activate HTTP/1.1
Accept: */ *
nodid: BFEB5E8E2BD9A79531Q
token: 15F7E14203AD318B0AB05514A6BD5B072830A076267C66E2X
Content-Length: 0
Content-Type: text/html
Connection: close

# cat post-deactivate
POST /v2/node/activate HTTP/1.1
Accept: */ *
nodid: BFEB5E8E2BD9A79531Q
token: 15F7E14203AD318B0AB05514A6BD5B072830A076267C66E2X
Content-Length: 14
Content-Type: text/html
Connection: close

{"activate":0}




3.2 Node State 

/v2/node/state


Input: 

{"value":123}
{"value":{"x": 12, "y": 12, "z": 12, "k": 22, "l": 33}, "deliver_to_device": 0}
{"coords":{"lat":123, "lng":234}, "cell":{"mcc": 460, "mnc": 0, "lac": 123, "cid": 456}}

# cat get-state
GET /v2/node/state HTTP/1.1
Accept: */ *
x-key: daxuexeprs
nodid: BFEB5E8E2BD9A79531Q
token: 15F7E14203AD318B0AB05514A6BD5B072830A076267C66E2X
Content-Length: 0
Content-Type: text/html
Connection: close

# cat post-msg
POST /v2/node/state HTTP/1.1
Accept: */ *
x-key: daxuexeprs
nodid: BFEB5E8E2BD9A79531Q
token: 15F7E14203AD318B0AB05514A6BD5B072830A076267C66E2X
Content-Length: 16
Content-Type: text/html
Connection: close

{"value":139225}



3.3 ROM Update 

/v2/node/rom/version
/v2/node/rom/update?version=xxx



3.4 Manufacture 

/v2/nodes

{"type":"device", "state":"{}", "uuid":"", "auth":{"pubkey":"XOIO1234", "algo":"xx", "seed":"12345" }, "meta":"", "trig":"{}"}



4 DB Structure

状态性控制器状态和数值型传感器的值分开，因其需不停查询也

对于状态性控制器最新状态，直接在 device/light 表里放着即可，查询每次到这来，一次完成，每次的操作记录在 controller 表中



5 性能测试

5.1 http_load

官网：http://www.acme.com/software/http_load/ 

$ http_load -rate 5 -seconds 10 http://t.tt
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
5916 mean bytes/connection
4.89274 fetches/sec, 28945.5 bytes/sec
msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
HTTP response codes:
  code 200 -- 49



5.2 ab

  • ab - Apache HTTP server benchmarking tool 
$ sudo apt-get install apache2-utils
$ ab -c50 -n3000 http://t.tt/index.html
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking t.tt (be patient)
Completed 300 requests
Completed 600 requests
Completed 900 requests
Completed 1200 requests
Completed 1500 requests
Completed 1800 requests
Completed 2100 requests
Completed 2400 requests
Completed 2700 requests
Completed 3000 requests
Finished 3000 requests


Server Software:        ARTWS/1.0
Server Hostname:        t.tt
Server Port:            80

Document Path:          /index.html
Document Length:        154 bytes

Concurrency Level:      50
Time taken for tests:   9.806 seconds
Complete requests:      3000
Failed requests:        0
Write errors:           0
Non-2xx responses:      3000
Total transferred:      1068000 bytes
HTML transferred:       462000 bytes
Requests per second:    305.95 [#/sec] (mean)
Time per request:       163.425 [ms] (mean)
Time per request:       3.269 [ms] (mean, across all concurrent requests)
Transfer rate:          106.37 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       71   81  81.2     76    3073
Processing:    72   80  19.2     78     403
Waiting:       72   79  11.8     78     326
Total:        143  160  83.4    154    3148

Percentage of the requests served within a certain time (ms)
  50%    154
  66%    157
  75%    158
  80%    159
  90%    163
  95%    166
  98%    190
  99%    207
 100%   3148 (longest request)



6 Reference






















来自“http://wiki.jackslab.org/index.php?title=Cloud_Of_Smart_Home&oldid=3646”
个人工具
名字空间

变换
操作
导航
工具箱