初试物联网之远程温湿度计

将 NAS 的信息显示在面板上只能帮助家人在房间内了解信息,但更重要的是如何能够在远程获取房间内的状态呢?为了实现将远程房间内物理信息传送到云端,需要以下的几个环节相互配合

  • 物联网数据平台,作为云端保存和处理数据
  • 传感器,采集环境信息产生数据
  • 家庭网关,将传感器信息收集传送到云平台
Internet of Things
Internet of Things

随着软银宣布收购 ARM 在物联网大展拳脚,Iot 这个不断翻炒的菜也在不断升温,国内除了百度物接入阿里云,流行的物联网数据平台中 Yeelink乐联网算是比较典型解决方案。他们都提供了通过 HTTP 访问的 RESTful API 将分布在各处的数据传送到他们的数据平台上,这种开发方式对绝大多数不会产生大量数据的小客户进行快速开发是非常方便的,下面的代码就能说明。不过周末尝试了好久,就是无法在 Yeelink 上成功的注册帐号,只好转战乐联网了,不过由于 API 基本类似,即便是转平台也是非常快捷的。如果有虚拟主机,也可以自己直接采用开源的 opensensordata.net 搭建一个云端的数据平台。

继续阅读“初试物联网之远程温湿度计”

Zigbee何时成为主流

一个月以前和德国同事开会的时候,我提起是不是应该考虑一下物联网IoT时代通讯协议的事情,然后就自然而然的谈起了Zigbee。比较意外的反应有两个,一个是大多数人的茫然,完全不知道我在说什么。只有一个同事低头笑了一下,苦笑着说一句:都二十年了,这个该死的协议还活着啊?

第一拨同事的表现其实在我的预想中,因为Zigbee基本上是一种工业领域碰不到的东西。开玩笑说:我们给产品命名从来都是用凶猛的动物,比如老鹰,老虎。再怎么着也不会用这么偏门的蜜蜂名字。其实来Zigbee的目标市场从来都是家住商用领域(也不能完全这么说,北京4号线延长段已采用Zigbee),和工业真是没有多少交际。

而那个同事所说的话让我思考了半天。

Zigbee协议是1990年就提出了,2004年成为IEEE 802.15.4-2003标准。算起来真是不算很短的历史了。可是,为什么这个如此被人推崇的协议,却有如此被人“唾弃”呢?

Zigbee
目标无所不包的Zigbee标准,实际中却不惹人爱

这里进行一个情景分析:如果我自己用Arduino做一个项目,我会采用什么样的协议来做模块间的通讯呢?

  • NRF24L01 2.4G 无线模块,淘宝价格10块,Arduino有现成的库
  • W5100 以太网扩展+SD扩展+Web服务, 30块
  • ESP8266 WiFi模块,15块
  • 蓝牙模块,20块,直接使用串口读写,可以和手机连接
  • XBee模块,50块,需要master+router方式将通讯转入以太网

考虑到10个节点规模的一个室内环境监测和安防物联网,如果采用XBee这个Zigbee的方案,光是通讯就比所有其他的主要器件加起来还要昂贵了。为什么主打家居市场的Zigbee如此昂贵呢,我们看到了目前主流支持Zigbee的芯片SOC供应商只有那么几个,和蓝牙,以太网控制器SOC的供应商相比简直惨不忍睹。

mesh networking
Zigbee的自组网能力是蓝牙和Wi-Fi缺乏的,但其节点类型的要求却成为设计者的难题。

开放上呢,Zigbee是不是有什么巨大的优势,可以减轻MCU侧的开发量呢?就Arduino来说,其他的协议有着非常直白清晰的开发接口——直接将这个通讯接口当作串口来读写即可,其他的收发验证,重发都无需处理。而Zigbee的难度简直就要上升到操作系统的级别。对于我提到这这个case,末端模块的工作只是每五分钟读取一下温度,湿度传送上来这样的工作,在Zigbee本身上开发的时间远远超过核心任务本身。

这样头重脚轻的样子,看来Zigbee就变成了一种不是很讨好的标准。而事实上的情况也说明了这一切。随着蓝牙4.0的推出,低功耗的优势在慢慢的退却,只有自组网这个特点还能让人有所期待。

能下的断言就是:Zigbee,你还没有为迎接IoT的到来下定决心。

比较Wi-Fi,蓝牙协议这些年的改进真是可以说日新月异。几乎每一两年就有新的标准推出,不但修正了以前的问题,还从对手那里学习到了很多新的特点。经过这几年Wi-Fi和蓝牙的不断竞争,两个协议都没有死,而且都更加健壮了。例如蓝牙不断突出自己节能的特点,而Wi-Fi也是步步紧逼,最近瑞芯发布的RKi6000就直接将功耗瞄准蓝牙4.0 LE。反观Zigbee几十年走下来,却基本上还是老样子,出生时候的毛病还都在,直到2007年才推出了PRO版本的增长型升级。

更加重要的就是作为一个协议,你需要的是参与者。恨你的人不是敌人,沉默才是你的敌人。时下做产品的,都希望有一个活跃的社区,大量的会员,众多的厂商来参与。其方法就是尽量采用更加开放的姿态,积极的鼓励这些参与者为这个协议添砖加瓦,最终营造一个摩天大厦。开放的TCP/IP 从娘胎里面就是抱着这个姿态出来的,这也是为什么基本上是全面压倒性的获得了市场地位。蓝牙在最早的时候还是很封闭的,直到被Wi-Fi的大量同类功能震撼到,感到了危机感马上也改变了策略。而Zigbee我只能说还在自己的黄粱美梦中,忘记了世界正在改变,这还真是像极了很多工业产品的特征。缺少参与者和贡献者的Zigbee变得越来越曲高和寡,开发平台和成本都成为了短板。

一个案例就是关于GPL兼容的问题。Zigbee的license和GPL等很多开源协议有冲突,这个问题经过协会的board讨论后,结论是Zigbee没有做出任何妥协。我猜测原因就是会员费基本是这个标准最大的收入来源,所以不能妥协。所以冲突的那条就是:商业用途的Zigbee软件是要收会员费的(每年3500刀)。不知道这个会员费是按什么计算到了,如果Linux集成了这个协议栈进去,到底会收谁的钱?就这样通向物联网的大门几乎可以说是Zigbee自己关闭的。最近 Google Brillo华为LiteOS还有更多的厂家纷纷推出了针对物联网的操作系统,大部分还是基于Linux和其他开源平台的,可以说封闭起来的Zigbee慢慢的缩小了自己通往成功的道路。

前有堵截,后又追兵,Z-Wave的兴起为嵌入式设备带来了一阵新风。单元这两个Z开头的标准能够在即将开始的厮杀中渐渐真正成长起来,为我们带来稳定、低价、方便的物联网通讯新标准。

USS通讯协议浅要

作为一个驱动产品的产品经理,对很多技术细节其实来了解的并不是很充分。作为一个业余项目的一部分,最近对USS协议进行了一些了解。现在总结在这里。

从客户的反馈来看,大部分认为USS是一种非常封闭的协议。但其实来这是一种西门子为变频器开发的串口通用通讯协议,广泛的用于PLC、PC、操作面板等设备和变频器之间建立通讯,常用于构建小型的自动化驱动系统。 所有的资料也可以在网络上找到。但由于这个协议应用层的内容比较复杂一些,各种资料中的介绍也各有侧重,所以即便是很熟悉的工程师在实际使用中偶尔也会忽略一些细节而导致通讯问题。

基本介绍

此协议具有如下的特点:

  1. 西门子驱动的统一解决方案,所有西门子变频器都支持此协议。
  2. 西门子调速装置上基本都包含了USS接口,无须任何附加选件即可实现,只要上位机具备RS-485通讯即可组成小型自动化网络。
  3. 通讯介质为RS-485总线,最远可达1000m。有效的减少了通讯电缆数量,降低开发、工程、维护的费用。
  4. 通讯速率可达115kbps。
  5. 总线架构,单主站,多从站的存取方式。
  6. 报文包含了参数数据、过程数据,速度快而且可靠性高。完全可替代模拟和数字信号的硬接线控制方式。
    1. 参数数据用于直接读取和修改变频器内部参数
    2. 过程数据用于连续监测和控制变频器状态,如:起停、速度、力矩等

链路层格式

USS协议对链路层是有要求的, 字节帧包含11位,包含以下数据:

  • 8位数据位
  • 1位停止位
  • 偶校验

连接层的协议格式

USS通讯的报文结构可如下表示:

STX 报文起始字 byte x 1 总是“02H”
LGE 报文长度 byte x 1 包含从地址,数据和校验字节数,其等于报文长度为总报文减2。
ADR 地址 byte x 1 0-31,子站地址
data 数据 WORD x n 数据区域
BCC 校验和 byte x 1 XOR校验前面全部字节

ARD 地址:标准报文中地址的5,6,7三位应该均为0,然后指定从站地址。

bit 7 6 5 4 3 2 1 0
特殊位 镜像 广播 从站地址

广播位为1为广播控制所有子站。

镜像位为1,表示地址指定的子站应返回原报文,不做任何改变。

应用层结构

去除连接层的信息,USS报文的核心就是数据区。报文中数据的长度是可变的,其中包含了两大部分内容:PKW(参数数值段)和PZD(过程数据)两大部分

data PKW 用户数据
PZD 过程数据

注意:PKW和PZD都是按照十六位的一个字来计算长度的。 用户数据PKW和过程数据PZD在一个报文中都是不可缺少的。但其长度均可以在子站通过参数设置来改变。

整个报文的结构可以如下表示:

从主站发送到驱动的数据 从驱动返回的响应
PKW PKE 参数读写命令和参数号的描述 操作结果,参数号码
IND 参数下标和参数号的页号 参数下标和参数号的页号
PWE1 参数数值第一字,对于U16,U8,I16整数,数据就包含在这里面 读取的结果第一字
PWE2 参数数值第二字,对于U32,FLOAT数据,和前面字构成全部数据 读取的结果第二字
PZD PZD1 过程数据1, ZSW 主控制字 STW 主状态字
PZD2 过程数据2, HIW 主设定值 HSW 实际运行值
PZD3 过程数据3, ZSW2 第二控制字 HSW2 第二状态字
PZD4 过程数据4
PZD n 过程数据 n,在MM4驱动可以最多有8个过程字

注意: 驱动的字节顺序和PC机的字节顺序1不同。

字节 Byte High Byte Low Byte High Byte Low
Word Word

其中PKW区域的总体结构如下表所示,包含了三个或更多个字(16位)的信息,长度是不固定的2

PKW 区段

这一部分报文是用来修改和读取参数数值而使用的报文。关于这一部分的信息,可以参考SINAMICS驱动的参数中的信息,进一步了解关于变频器中参数结构。

第一部分,PKE 参数编号的结构是:

15-12 11 10-0
名称 AK SPM PNU
含义 任务或者回应编号 不用,恒为0 基本参数编号

第二部分,IND 参数下表的结构为

15-12 11-10 9-8 7-0
名称 PNU page 保留 文本模式,不用 参数下标号码

请注意PNG page的计算方式不是完全按照位顺序计算的。

在IND的位置 bit 15 bit 14 bit 13 bit 12
page数值 20 23 22 21

PKE.PNU和IND.PNU page 是相互配合的两个参数。PKE.PNU的参数范围为0-1999,IND.PNU page的范围为0-15。 而参数号,是通过这两个数值运算得到的。

 Parameter ID = PKE.PNU + IND.PNU page * 2000

PKE.AK 任务标号的定义如下,用于从控制器向变频器进行操作中使用:

任务 ID 具体含义 应答 ID
确定 否定
0 无任务 0
1 读取参数值 1 or 2 7
2 改变参数值(word) [RAM only] 1 7 or 8
3 改变参数值(double word) [RAM only] 2 7 or 8
4 读取组件描述 3 7
5 改变组件描述 (MM4 不可用)
6 读取参数值(数组) 如:带有下标的参数 4 or 5 7
7 读取参数值(数组,word) [RAM only] 4 7 or 8
8 读取参数值(数组,double word) [RAM only] 5 7 or 8
9 读取数组元素的数量。如下标的个数 6 7
10 保留
11 保存参数值 (数组, double word) [RAM and EEPROM] 5 7 or 8
12 保存参数值 (数组, word) [RAM and EEPROM] 4 7 or 8
13 保存参数值 (double word) [RAM and EEPROM] 2 7 or 8
14 保存参数值 (word) [RAM and EEPROM] 1 7 or 8
15 读取或改变文本(MM4 不可用)

注意:当命令为读取驱动参数,且PWE的长度P2013设为127的时候,上位机发送的报文中不包含PWE部分。也就是说,这种情况下PKE,IND后面紧接着的就是PZD数据。

当变频器收到命令后,也会在PEK.AK的应答ID中有响应的回答:

应答 ID 具体含义 对应任务ID
0 无应答 0
1 传输参数数值 (word) 1, 2 or 14
2 传输参数数值(double word) 1, 3 or 13
3 传输组件描述 4
4 传输参数数值(array, word) 6, 7 or 12
5 传输参数数值 (array, double word) 6, 8 or 11
6 传输数组元素的数量 9
7 任务无法执行 (带有错误编号,请看下表) 1 to 15
8 无权改变参数 2, 3, 5, 7, 8, 11 to 14 or 15 (以及修改文本信息)
9 – 12 无用
13 保留
14 保留
15 传输文本 15

发生错误时的回应报文中,在PWE1字中,可得到如下的响应,进一步解释错误的原因:

ID 含义 对应任务ID
0 参数号无效 1 to 15
1 参数数值不可改变 (只读参数) 2, 3, 7, 8 or 11 to 14
2 超过参数数值范围 2, 3, 7, 8 or 11 to 14
3 下标无效。
注意(对task 4不适用):
如果变频器中此参数不是数组,在下标大于1时,报此错误。
对于 下标 = 0 或 1 ,任务将执行,并回复4或5。
4, 6, 7, 8, 11 or 12
4 非数组。
注意:
如果参数不为数组,在下标大于1时报此错。
对于 下标 = 0 或 1,任务执行,并回复4或5。
6, 7, 8, 11 or 12
5 数据类型错误 2, 3, 7, 8 or 11 to 14
6 参数只能设为零。 2, 3, 7, 8 or 11 to 14
17 驱动此状态不允许设定的任务。 2, 3, 7, 8 or 11 to 14
101 参数值此时无法立刻生效;参数在当前状态下无效(例如,闭环控制下)。 1 to 15
102 响应报文过长。 由PKW和最大有效报文长度决定
104 不允许的参数值。
变频器内没有与命令对应的功能, 或者在修改参数瞬间无法修改。
2, 3, 7, 8 or 11 to 14
106 不支持的任务 5, 10 or 15
200 新下限 2, 3, 7, 8 or 11 to 14
201 新上限 2, 3, 7, 8 or 11 to 14
203 在 BOP / AOP 无显示。
参数必须在 BOP / AOP上隐含。
1 to 15
204 参数在 BOP / AOP 无须设置访问登记。 (与参数P3950 访问密码有关) 1 to 15

 PZD 区段

这一区段用于变频器和控制器之间传输变频器运行状态,以及下达控制命令。在变频器内可以灵活的定义每一位的含义,并通过BiCo功能连接到需要的参数上。同时在控制器一侧也要作相应的设置处理这些功能。一般PZD只包含PZD1和PZD2两个字。通过参数设置3可以增加变化。

通讯方向 PZD1 PZD2 PZD3 PZD4
Master => Drive STW HSW HSW2 STW2
Drive => Master ZSW HIW ZSW2 HIW2

其中HSW为主设定值(一般为速度频率数值),为标定规格化后的数值。对应变频器的应答HIW为变频器实际输出值(一般为实际速度频率)。

规格化(normalization)对浮点数据标幺计算的方法。例如,默认频率的规格化标准为50Hz,则在USS报文中的数值应该为: HSW = 设定的频率 / 50.0Hz * 4000H 

 广播报文格式

地址ADR中第5位设为1,其它位设为0,表示这是一个广播地址。所有变频器对PZD的设定进行动作。 需要注意的是,如果进行广播操作4,PKW第一字节(PKE)必须为4字长,且位15,2,1必须为1,第二字(IND)位15,2必须为1,其它随意。 各个站点对广播不进行应答。

 时序要求

假设波特率Vbps下传输一个字节需要11位信息,则每个字节的传输速率为:tc= 11 / Vbps 秒,则在报文传输中对时间有如下的要求:

  • 报文起始后每个字节传输的间隔应小于 2 * tc 的时间
  • 报文的起始必须和前一个报文相隔大于 2 * tc 的时间(报文间隔时间)
  • 报文响应时间必须小于20ms,但是必须大于报文间隔时间 2 * tc
  • 报文(不包括STX报文头)传输的总时间应该小于 1.5 * (总报文长度 + 3) * tc

报文间隔将在主站和从站双向进行监测,超过时间的报文将被抛弃。


注释:

  1. 在Intel的处理器上,处理报文需要交换一个字中两个字节的顺序。
  2. 参看P2013参数的设置,当P2013=3则PWE只有一个字,P2013为4则包含了两个字,设为127则表示长度可变。
  3. MM4的P2012参数可以设置PZD报文的长度从0到4变化,而G120 CU230P-2可以支持最多8个字的PZD
  4. 广播操作不能进行参数读写操作,也就是说PKW段没有作用。