2014年12月13日 (六) 21:13的版本

1 概述

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

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

1.1 HOME

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

1.2 Device

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

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

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

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

1.3 Member

1.4 Node

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

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

1.5 Trigger

2 框架

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

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

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

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

---

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

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

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

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

3 Open API

3.1 Activate

CamGo 的设计：(X1)

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

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

---

mini 的设计是这样：(M1)

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

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

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

---

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

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

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

4 DB Structure

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

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