物联网 command 原型设计及框架

时间：2015-10-12 17:00:04 阅读：249 评论：0 收藏：0 [点我收藏+]

标签：

在另一篇文章讲述了client API设计（IOT command （based on sip）client API设计 for java ）。

前段时间梳理了command设计及框架，其实狭义上即设备控制、管理，即可以家庭局域网内进行管理，也可以远程管理(通过开源的sip server: opensips)，当然也包含了设备联动规则的原型实现（即物联网的ITTT）.

command包含两部分：即client和server(eg. 手机上的client app，gateway上的server)

流程如下图所示：

1. 手机发送远程请求：对房间内hue开灯

2. 物联网cloud平台接收到请求转发给相应的gateway

3. command_svr接收，解析发送给hue模块，hue模块进行本设备类型协议的通信，实现开灯请求

4-5. command_svr将操作结果发送回去，由opensips转发给client, client获知开灯成功结果。

client主要功能：

1. 请求gateway的设备列表，设备功能，状态

2. 发送设备操作请求，并接收设备操作结果

3. 订阅，接收设备消息通知

sever主要功能：

1. 管理接入到gateway的不同设备类型列表，设备插件以动态库形式接入，方便第三方接入。

2. 接收client的设备操作请求，转发给相应的设备模块(eg 上图ip_camera)，由该模块进行协议转换，进行实际的设备控制，然后接收操作结果，并将其转换为command协议，返回给client response.

3. 接收设备模块的主动推送的消息，并推送给相应的client.

4. ittt功能：接收并存储client制定的设备联动规则，检查client的设备控制请求，如符合if, 则触发then的设备控制。

目前command的实现是基于sip来实现的，对sip的方法进行扩展，即增加一个定制的方法sip-command，并在其基础上实现

设备控制层，command在pjsip开源库基础上实现，而远程管理借助开源的opensips服务器，达到快速原型目的; 另外一个原因是项目中流媒体传输播放需求是基于sip/rtp来实现，统一在sip下，减少学习投入成本，尽快出原型。

下图是一个command框架图，底层是sip层，在pjsip基础上增加了command方法；cmd_mng定义了两个主要接口(cmd_send_inf, cmd_recv_inf)来和sip层进行通信, 考虑将来方便替换或兼容不同的协议，达到模块间松耦合。cmd_mng上层分别是dev_mng和iot_cmd_proc两个模块，dev_mng包含了

command server端的管理、加载设备插件，即设备的function功能和设备元数据文件解析导入（通过定义plugin_interface接口，提供给第三方开发为gateway接入新设备类型），以及供client查询设备元信息的内部接口。iot_cmd_proc模块则包含了client, server的收发command消息的处理框架，和提供给第三方开发client端的接口(即开头讲到的client API设计)。

1. 下面介绍server端的供第三方接入新设备类型开发的接口定义（第三方实现，并以动态库的方式提供给gateway command-svr）

plugin_interface接口:

typedef struct dev_func
{
 const char * funcname;
 int (* dev_method)(cmd_arg * param_list[], uint8_t plist_size);    
}dev_func;

typedef struct dev_plugin {

 char dev_pluginname[NAME_MAXSIZE];  //设备类型名称，具有唯一性
 const dev_func * pt_func_array;     //函数列表，设备实际执行函数，供command-svr回调。
 char dev_metafile[NAME_MAXSIZE];    //设备元数据文件

}dev_plugin;

typedef int   (* init_devplugin)(dev_plugin * pt_plugin, dev_cmd_interface * pt_inf);

command-svr通过init_devplugin函数，会读取到该设备插件的上面信息， gateway便知晓该设备类型具有的属性和功能。

（后续还需要有设备插件的热更新，删除，运行时加载等功能）

2. 下面介绍iot_cmd_proc模块，它是command的逻辑处理核心

以client端为例，

采用内存消息队列形式(使用mini_mq)来解耦业务层(cli_proxy)，command层(cmdhandler_proc)，承载msg的协议层(sip_proxy)

原型开发完后，总结了下开发，使用时碰到的各种问题：

1. command的设备控制设计，是以设备的动作为目标，如下test设备类型的元数据定义

<device type="test_plugin">
<method name="test1">
<param name="a" type="int" direction="IN"/>
<param name="b" type="string" direction="IN"/>
<param name="c" type="float" direction="OUT"/>
<param name="d" type="string" direction="OUT"/>
</method>
</device>

如果加入设备propery属性，可以很好的契合下个阶段command的协议采用http的restful风格，以设备资源属性为目标，简单通过

set, get来实现对设备的操作（当然正如不是所有的web服务都能完美的采用restful, 设备控制操作可以采用属性，动作均定义的方式）。

2. 正如上面描述到的，我考虑command的协议采用http，在gateway使用web服务方式，client端就采用hybrid方式，即避免command

的client, server更新问题，又使用原生来避免web的不足，目前已经在调研中。

3. 设计一个的iot_cloud原型，暂定功能主要为方便用户远程管理设备，以及存储用户设备数据，及简单的数据分析。

物联网 command 原型设计及框架

标签：

原文地址：http://www.cnblogs.com/europelee/p/4871885.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行