紧接上文，这是第三篇，主要是对MQTT-SN 1.2协议进行总体性功能描述。
嗯，这一部分可以结合着MQTT协议对比着来看。
网关的广播和发现
网关只能在成功连接到MQTT Server之后，才能够周期性的在无线个人区域网WPNs内对所有客户端广播ADVERTISE消息，便于客户端被动知道网关的存在。
在同一网络下，多个拥有不同Id的网关可有同时运行中，但会由客户端根据信号强弱决定连接具体网关，无论何时只能连接一个网关。
客户端可维护一份可用网关列表（包含网关地址），在接收到包含有新的网关id的ADVERTISE和GWINFO消息后，其列表需要添加新的网关元素进去。
ADVERTISE广播消息包含的下一次广播间隔时长Duration属性，单位秒，设为变量T_ADV，应该尽可能大与15分钟（900秒），频率降低是为了避免低速个人区域网络的拥塞。
针对接收ADVERTISE消息频率，处理能力较强客户端可以用于监督网关是否可用。eg：客户端连续N_ADV次接收不到某个网关ADVERTISE广播消息，可认为此网关经死掉不可用并且从已维护的网关列表中移除。同样的，作为备用的网关认为主网关已挂掉，此时可处于激活状态，正常发挥作用。
网关发送广播消息ADVERTISE的时间间隔很长，这对导致新加入的客户端不利，但客户端可以直接发送SEARCHGW广播消息进行查询网关。大量的新入设备会造成广播风暴造成网络拥挤，每一个新加入的客户端在发送SEARCHGW广播消息之前都需要获取一个随机的延迟发送值(0-Tsearchgw)，在延迟等待发送期间若接收到其它客户端发送的SEARCHGW广播消息，会取消掉自己的SEARCHGW广播消息发送，等待网关GWINFO消息通知。
SEARCHGW消息属性radius广播半径，记为变量Rb，1跳（1 hop）在一般密集部署下的MQTT-SN客户端基本可用。
网关接收到SEARCHGW会即刻回复包含自身id的GWINFO消息。客户端收到SEARCHGW后，若有需要延迟发送的SEARCHGW会取消掉，若自身维护一份多个可用网关列表，在等待T_GWINFO时间内没有收到GWINFO消息，会从列表中取出一条网关信息组装成GWINFO消息并广播出去。这就要求客户端已运行多时，并且维护多个可用网关列表。
GWINFO和SEARCHGW所包含半径radius属性值一致，这就要求底层网络在传输时进行决定是否需要传输到其它类型网络中。
若没有接收到响应，SEARCHGW消息可能被重新传输。两个连续的SEARCHGW消息重传间隔应该呈指数形式增加，避免太密集传输。
客户端的连接建立
无论是基于哪一种传输协议，TCP or UDP，客户端都需要建立连接，并且保持心跳，逻辑上和服务器端保持一条不断线的双向通道。下面一张图，演示了客户端建立连接的过程，并且设定客户端在CONNECT消息中标志位字段中遗嘱WILL属性为true，然后就有了遗嘱主题/消息的请求过程。
很多情况下，连接CONNECT是不需要遗嘱支持的，网关会直接返回CONNACK消息，但网关会因为拥塞或不支持一些CONNET特性，CONNACK所包含返回代码字段ReturnCode中包含拒绝代码，要求客户端检查是否连接成功，区别对待。比如：
CONNACK消息返回状态码为0x01（Rejected: congestion，因拥塞被拒绝），客户端需要在T_WAIT时间间隔后进行重试。
已经连接的客户端断线后，若之前在CONNECT中没有设置过会话清理（Clean Session）标识，那么之前的订阅等信息在网关处将会持久存在。相比MQTT，MQTT-SN中的&Clean Session&标识被扩展到遗嘱特性中。在CONNECT消息中，CleanSession和Will组合将会产生以下效果：
CleanSession=true, Will=true: 网关将会删除之前对应的所有订阅和遗嘱，新的遗嘱主题/消息稍后即将重新处理
CleanSession=true, Will=false: 网关将会删除之前对应的所有订阅和遗嘱，返回CONNACK消息
CleanSession=false, Will=true: 网关将继续持有之前对应的所有订阅，新的遗嘱主题/消息稍后即将重新处理
CleanSession=false, Will=false: 网关将会继续持有之前对应的所有订阅和遗嘱等数据，并返回CONNACK消息
更新遗嘱流程
CONNEECTION中标志位Will中设置是否需要更新遗嘱主题/消息
空WILLTOPIC（两个字节）消息将会促使网关删除对应遗嘱数据
WILLTOPICUPD/WILLMSGUPD可以更新/修改遗嘱主题、遗嘱消息
空白WILLTOPICUPD（两个字节）消息意味着请求网清空对应已有的遗嘱数据
主题注册流程
受限于无线传感器网络的有限带宽和微小消息负载，PUBLISH消息中不能够包含完整的主题名称topic name。这就需要客户端和网关之间通过注册流程，获取主题名称对应的（16位的自然数）topic id，然后塞入PUBLISH消息的topicId属性中。
客户端发送REGISTER消息，网关返回REGACK消息，其所包含的ReturenCode属性决定注册成功与否：
ReturnCode = &accepted&，topicId可以很愉快的使用在稍后的PUBLISH消息中
ReturnCode = &rejected: congestion&，客户端需要稍等一段时间（T_WAIT表示，大于5分钟）再次重新注册
ReturnCode = &rejected: invalid topic ID/not supported&，客户端需要稍作调整，再次重新注册
任意时间，只能执行一个REGISTER消息，有没有完成注册流程，需要等待。
网关-&客户端方向，网关发送REGISTER消息给通知客户端指定topicId对应某个主题，以便后面发送PUBLISH消息使用。若客户端在订阅SUBSCRIBE消息时使用了通配符（#/+），那么与之相匹配的topic name也将被一一通知到。因此不建议使用通配符，较为低效。
客户端发布流程
客户端一旦获取到topic name对应topic id，就可以直接发送PUBLISH消息了。这和MQTT协议相比，PUBLISH消息中Topic Name被替换成Topic Id，除此之外，还要注意ReturnCode：
ReturnCode = &rejected: congestion&，客户端需要稍等一段时间（&5分钟）后再次重试
ReturnCode = &rejected: invalid topic ID&，客户端需要重新注册topic name获取topic id，然后再次重新发布
QoS 1和 QoS 2在任一时间，都必须等待已有PUBLISH消息完成，才能进行下面的PUBLISH消息发布流程。
预定义topic id和两个字符的topic name
预定义的topic id已提前指派好对应的topic name，需要客户端和网关在代码层级支持，省略了中间注册流程，在连接建立之后可以马上进行PUBLISH消息，但这需要在PUBLISH标志Flags字段中设置TopicIdType值为0b01（0b10表示两个字节长度的短topic name）。虽然可以快速发送PUBLISH消息，但客户端想订阅预定义的topic id，接收对应的PUBLISH消息，一样需要发送SUBSCRIBLE消息请求进行订阅。若乱指定预定义topic id，会收到ReturnCode=&Rejection: invalid topic Id&的异常。
预定义的短topic name只有两个字符长度的字符串（也是两个字节），topic id为两个字节表示的一个自然数（0-65535），两者使用场景一致，都需要在标志位Flags设置TopicIdType具体值，0b01表示预定义topic id，0b10表示两个字节长度的短topic name，需要分清。
PUBLISH对应QoS -1值
这对仅仅支持PUBLISH QoS -1的非常简单的客户端实现而言，除此之外不支持任何特性。它不关心连接是否建立，也没有注册、订阅这一说，按照已经固化到代码中的网关地址直接发送PUBLISH消息，不关心网关地址是否正确、网关是否存活、消息是否发送成功。
下面的PUBLISH属性值依赖于QoS -1的情况：
QoS标志，被置为0b11
TopicIdType标志，可能是（预定义topic id）0b01也可能是（短topic name）0b10
TopicId字段，预定义topic id或短topic name
Data字段，需要发送的数据，没啥变化
客户端的订阅和退订
客户端对某个主题感兴趣，可以发起SUBSCRIBLE流程，携带上感兴趣的主题名（topic id），服务器一般会返回包含有指定主题Id（topic id）的SUBACK消息。订阅失败，可以从PUBACK的ReturnCode中获知：
ReturnCode = &rejected: congestion&，客户端需要稍等一段时间T_WAIT（&5分钟）后再次重试
有一种情况是SUBSCRIBLE订阅主题包含通配符，网关的处理就很简单，在SUBACK中返回的topic id为0x0000。稍后，网关向客户端发送REGISTER消息走注册流程，通知通配符匹配到的主题对应的topic id值。
来自客户端的SUBSCRIBLE消息一样支持预定义topic id，以及短topic name，这和PUBLISH消息差不多。
退订就很简单，客户端发送UNSUBSCRIBLE消息，网关返回UNSUBACK消息。
但同一时刻，客户端只允许处理订阅SUBSCRIBLE或取消订阅UNSUBSCRIBLE按照串行化顺序，下一个操作依赖于上一个操作完全成功。
网关发布流程
服务器发布流程和客户端类似，在发布之前需要检测其主题是否已经向客户端提前注册过，若无需要把主题和指定的topic id放入REGISTER消息中发送给客户端进行注册流程，然后等待客户端处理结果REGACK。注册通过，然后才能正常发送PUBLISH消息。
网关需要确保REGISTER的主题以及PUBLISH消息的内容负载都不能太长超过当前网络负载上限（比如在ZigBee环境下不能超过60个字节），取消注册/发布流程就好了。
网关发布PUBLISH消息时，客户端检测到未知的topic id，把拒绝理由封装到PUBACK后，网关遇到ReturnCode=&Rejected: invalid Topic ID&非法topic id，需要考虑删除或重新注册。
客户端或许会拒绝其注册，或许会不允许PUBLISH消息，网关如上静默处理就好了，失败就失败了，不需要告知别人。
客户端发布流程于此类似，需要在发布之前进行主题注册以获取指定的topic id，提交PUBLISH消息后，同样需要检查PUBACK所包含的ReturnCode字段是接受还是拒绝，因网络拥塞而产生的拒绝，客户端需要在T_WAIT时间后再次重试。
客户端的发布必须是串行方式，下一个需要发送到PUBLISH消息需要等待上一个发送成功被网关接受之后才能进行处理。
心跳保活流程
一般是客户端-&网关，网关-&客户端也没有问题。但要求PINGREQ -& PINGRESP 一定要单个时针循环，PINGREQ发送者不能也是PINGRESP的发送者，那样不但乱了流程，也浪费了网络资源。嗯，不允许双向互发。
客户端可基于心跳机制监测已连接网关健康与否，连续多次接收不到来自网关的PINGRESP消息后，客户端连接下一个可替换的网关。因为客户端的连接和心跳和其它客户端状态属性不同步，但这可能会带来一个问题，同一时间若有大量的客户端洪水般同时连接一个网关，网关可能毫无征兆的会被冲垮掉。这就要求网关要有批量的连接处理能力，并发特性增强才行。
客户端断线流程
客户端主动发送DISCONNECT消息告知网关需要断线之后，若有交换信息的需要可以重新发起一个新的会话连接。DISCONNECT消息之后，网关不会清理掉已有订阅和遗嘱数据，除非在之前的CONNECT消息中已硬性设置了CleanSession会话清理标识为true。网关接收到DISCONNECT消息之后会返回一个DISCONNECT消息作为响应。
有一种情况是客户端会突然接收到来自网关的DISCONNECT消息，这也许是网关自身发生了异常错误，或网关无法定位客户端的消息归属（客户端的消息和客户端无法关联到一起），此时客户端需要发送CONNECT消息重建与网关的会话连接。
客户端重传流程
客户端-&网关的消息都是单路传播的，这依赖于客户端所持有的已连接网关的单播地址。
客户端发送一个消息之后，需要启动一个重试定时器Tretry和一个重试计数器Nretry用以监督网关消息响应。定时器会被客户端在指定时间内接收到来自网关的消息后取消掉，若没有准时接收到则会触发定时器执行消息重发流程，连续Nretry次重发后，客户端会直接取消掉当前流程，判断当前网关已经断线，需要连接到另外一个可用的网关。假如另外的网关也是连接失败，会尝试重连之前的网关。
若在休眠状态下，一旦超过重试计数器值，客户端直接进入休眠状态。
客户端休眠支持策略
这里所说的客户端指的是依赖电池驱动的电子设备，你要明白一个事实，节省电池资源是多麽的重要，省电就是关键，没电了就没得玩了嘛。当不处于激活状态时为了省电就得需要进入睡眠/休眠状态，当有数据需要接收或发送时就可以醒过来。网关嘛需要追踪设备的休眠状态并且支持缓存需要发送给休眠设备的消息，在设备唤醒时一一发送。
下面是客户端的状态转换图，很清晰描述了各种状态之间的交互：&
客户端具有五种状态：激活（active），休眠（asleep），唤醒（awake），断线（disconnected），丢失（lost），每次只能是其中一种。
网关需要监督客户端的状态，开始于CONNECT消息中存活时长字段（keep alive），在大于存活时长时间内网关接收不到来自客户端消息，网关认为客户端已经处于丢失状态（lost），会激活对应的遗嘱特性若存在的话。
客户端发送DISCONNECT消息但没有duration休眠时长字段，网关这将处于没有时间监督的断线状态。一旦包含duration休眠时长字段，表示客户端需要休眠一段时间，网关这客户端被转换为休眠状态，休眠时长为duration所定义在值。超过此休眠时长的一段时间内，网关若接收不到客户端发送过来的任何消息，那么客户端会被转化为丢失状态，若已设置遗嘱特性，此时遗嘱特性会生效。客户端休眠期间需要被发送的消息都会被网关缓存。
睡眠状态下流程图会更形象的说明流程：&
毫无疑问，网关可使用一个休眠定时器维护客户端的休眠状态等，休眠定时器会被停掉当网关接收到客户端发送过的PINGREQ消息，网关从PINGREQ消息所包含的Client Id检索是否存在已缓存的PUBLISH消息，若有会一一按照顺序发送到客户端。所有对应已缓存消息发送完毕后，会随之发送一个PINGRESP消息。若没有缓存消息，网关直接返回一个PINGRESP消息。网关会重新启动休眠定时器，网关维护的客户端状态被转换为休眠状态，客户端在接收到PINGRESP消息之后，将直接转向休眠状态，节省用电。
客户端在唤醒状态下处理消息，遵守&客户端重传流程&行为，一旦达到重试计数器限制，将进入睡眠状态。
客户端从休眠状态转向唤醒状态用于检查网关是否为其缓存消息时，需要发送一个PINGREQ消息到网关；从休眠/唤醒状态转换为激活状态，需要发送一个CONNECT消息告知网关；转换为断线状态时需要发送两个字节的DISCONNECT（没有休眠时长字段duration）消息；需要重新定义的休眠时长，发送一个DISCONNECT消息（包含新的duration时长值）通知网关即可。
功能性描述介绍完了，基本上MQTT-SN协议介绍已接近尾声，最后面的篇章就是短短的实现描述了。
原文&http://www.blogjava.net/yongboy/archive//422156.html
阅读(...) 评论()数字营销云
智能多媒体服务
物联网服务
安全和管理
大数据分析
海量空间、安全、高可靠，支撑了国内最大网盘的云存储
灵活稳定、方便扩展的万量级IOPS块存储服务
高性能、低成本、可扩展的共享文件存储服务
百度自建高质量CDN节点，让您的网站/服务像百度搜索一样快
混合云存储方案，无缝衔接本地和云端环境
海量优质共享带宽，稳定安全的PCDN服务
私有部署的高可用、可扩展、强安全的海量非结构化数据存储产品
支持MySQL、SQL Server、PostgreSQL，可靠易用、免维护
提供高性能、高可用的分布式缓存服务，兼容Memcache/Redis协议
海量数据分布式数据库存储服务
简单可靠的数据库数据传输服务
存储时间序列数据的高性能数据库
一站式直播云服务，引领智能直播新时代
一站式点播云服务，让视频技术零门槛
提供高质量的音视频转码计算服务
提供百度文库一样的文档在线浏览服务
对视频内容多维度智能分析，输出视频的泛标签
六大维度视频内容审核，大大降低视频平台风险
对视频内容理解，自动截取精彩画面作为视频的封面
快速建立设备与云端双向连接的、全托管的云服务
简单快速完成各种设备数据协议解析，如Modbus、OPC等
智能、强大的设备管理平台
存储时间序列数据的高性能数据库
灵活定义各种联动规则，与云端服务无缝连接
轻松设计基于物联网海量数据流的可视化应用
提供边缘计算本地运行框架和云端管理套件
一站式智能家居设备管理平台
提供简单、可靠的短消息验证码、通知服务
对Web、Mobile APP的应用性能监测、分析和优化服务
基于海量样本用户的问卷调研服务
自动化测试、人工测试、用户评测等多维度测试服务
提供AR开发框架(SDK)、内容创作、管理、分发一站式解决方案
云虚拟主机 BCH
高可靠、易推广的容器云虚机，企业建站首选
提供百余种后缀域名注册及免费智能解析服务
自研DNS设备，单机千万级解析性能，权威DNS解析专家
安全、高效、精准的移动域名解析服务
行业解决方案
专项解决方案
可快速部署的典型应用服务框架，如Docker
集成各类常见开源／商业源码、CMS等环境
预装主机管理面板或其他业务管理系统
预装经配置优化加固的数据库系统环境
提供模版化或快速开发模式的建站服务
提供各类网站的定制化设计、开发服务
荟萃开源、商业Web/App源码，一键使用
移动端H5、Native/HybridApp设计开发
针对企业个性软件需求开发定制
提供基于百度云底层架构的网站主机服务
为您部署安装配置相应的软件运行环境架构
帮您把原有业务运行环境及数据迁移上云
代理维护服务器，数据库等各类系统架构
排查故障、定位原因、协助恢复正常运营
上云配置、架构、技术方案等问题解答
系统环境调优加固服务、保障业务稳定运行
针对主机运行环境的安全处理与优化工具
专业安全检测、漏洞扫描、渗透测试等
代理维护服务器，数据库等各类系统架构
堡垒机、准入网关等安全认证准入产品
网络安全防护产品如VPN、DD0S防护等
堡垒机、安全认证、认证审计等服务
应用层安全服务、如WAF、木马检测等
公司注册、代理记账、商标／著作权等
垂直行业或领域专用的系统平台软件
客户关系管理（CRM）、在线客服系统等
OA自动化、工作流等企业高效协作软件
企业进销存、销售跟踪、业务管理等软件
企业邮箱、即时通讯、呼叫中心、融合通信等
帮助文档 &
MQTT客户端使用指南
MQTT.fxMQTT.fx 是目前主流的mqtt客户端，可以快速验证是否可以与IoT Hub 服务交流发布或订阅消息。设备将当前所处的状态作为MQTT主题发送给IoT Hub，每个MQTT主题topic具有不同等级的名称，如“建筑/楼层/温度。” MQTT代理服务器将接收到的主题topic发送给给所有订阅的客户端。 连接IoT Hub服务登录，找到适合的版本下载并安装MQTT.fx客户端。
打开MQTT客户端的设置页面，点击“+”按键，创建一个新的配置文件。
填写Connection profile相关信息：
参数名称 说明
profile name 配置文件名称
Broker Address 创建endpoint后返回的hostname
Broker Port ssl加密连接方式，端口使用1884；tcp不加密连接，端口使用1883。
Client ID 客户端ID，支持“a-z”,“0-9”,“_”,“-”字符，且不能大于128bytes，UTF8编码。在同一个实例下，每个实体设备需要有一个唯一的ID，不同实体设备使用同一个client id建立连接会导致其它连接下线
选择User Credential，输入创建 IoT Hub 服务返回的username/password，参考。
如果您选择SSL安全认证方式连接IoT Hub 服务，需要配置SSL/TLS安全认证，勾选 Enable SSL/TLS，选择CA signed server certificate认证。
如您选择TCP连接，无需配置SSL安全认证，执行第4步骤即可。
点击“Apply”按键，完成客户端配置。
返回MQTT客户端界面，选择新创建的配置文件，点击“connect”按键连接服务。
订阅消息 注意： IoT Hub一个主题支持的层级最多是9层（也就是最多只能出现8个斜线&/&）。
成功连接IoT Hub 服务后，即可开始订阅消息。 打开Subscribe标签，填写主题topic，例如building-b/floor-5/temperature-1，选择默认的QoS 0，点击“Subscribe”进行订阅操作。 发布消息打开Publish标签，填写主题topic，例如building-b/floor-5/temperature-1，选择默认的QoS 0，点击“Publish”进行发布操作。 返回Subscribe界面，即可看到已接收的订阅消息，参见下图。
转1 24小时售前咨询
cloud.baidu.comMQTT远程控制方法
发布于 10:53
浏览:1607 回复:0
是IBM为物联网设计的消息传递技术，旨在为低带宽、不稳定网络环境中的物联网提供可靠的网络服务。目前已经被国际标准化组织采用，成为物联网行业的一个标准。
MQTT协议特点
　　●　使用发布/订阅消息模式，提供一对多的消息分发。
　　●　使用TCP/IP提供基础网络连接。
　　●　轻量传输，协议交换最小化，以降低网络数据流量。
目前，常见的云平台有百度天工，阿里物联网云，中移OneNet等等，这里以百度云为例介绍。
首先，在使用百度云之前，需要注册一个百度账户，如下图：
& & & & & & & & & & &图1& 注册百度账户
接下来，进入物接入页面，首先创建一个实例，接下来创建设备，在创建设备的时候，需要先创建身份，每个身份可以绑定一个策略，策略里包含了主题的命名，以及发布，订阅的权限。更详细的介绍请阅读官网文档。
& & & & & & & & & & 图2& 百度云平台配置流程
3网关+客户端的控制方式
& & & & & & & & &图3& 网关+MQTT客户端软件
网关选用北京浩联迅通科技有限公司(&HL-GPRS-MQTT系列，通过MQTT网关连接百度云服务。通过消息发布的方式上传数据；PC或手持终端上的客户端软件通过消息订阅机制可以接受到这些数据；反之，客户端软件也可以通过MQTT网关向设备发送信息。
& 3.1 网关配置参数
& & & & & & & & & & & & & & 图4& 网关配置参数
l服务地址：endpoint.mqtt.iot.gz.baidubce.com
Endpoint: 创建的实例名称
l服务器端口：1883
l用户名：实例/设备名称
l密码：与设备绑定的身份的密码
l设备ID：设备的唯一标识，由用户自行定义，如plc001
l订阅主题：网关接收使用的主题，例如myAPP
l发布主题：网关发送使用的主题，例如plc001
l心跳间隔：默认60
& 3.2 客户端软件设计要点
l软件的服务地址，服务端口，用户名，密码，都和网关一致
l设备ID：要区别于网关，如APP
l订阅主题：网关发送数据使用的主题，可以接收远程设备数据
l发布主题：发送给网关的主题， 也就是发送给远程设备的数据
4点对点控制方式
通过两个MQTT网关，分别连接传统的组态软件和设备，通过云服务建立一个透明通道。这样，就可以利用原有的组态软件实现远程监控设备的目的，不必去重构图形化的客户端软件。
& & & & & & & & & & & & & 图5& 点对点控制方式
&&&&&&&& 网关的配置要点：
l软件的服务地址，服务端口，用户名，密码，都一致
l设备ID：要不一样，如分别为APP，PLC
l订阅主题：对方发送数据使用的主题
l发布主题：对方接收数据使用的主题
& & & & & & & & & & & & & & & 图6& PC端网关的配置
& & & & & & & & & & & & & & 图7& 设备端网关的配置
连接实际设备前，可以先用串口调试助手观察通信过程，网关的串口连接串口调试程序，观察和上位机软件数据传输的过程；如果是点对点的传输方式时，两个网关都可以接串口调试软件进行模拟调试。
8& 串口调试助手调试MQTT协议说明_图文_百度文库
您的浏览器Javascript被禁用，需开启后体验完整功能，
享专业文档下载特权
&赠共享文档下载特权
&10W篇文档免费专享
&每天抽奖多种福利
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
MQTT协议说明
&&MQTT协议说明
阅读已结束，下载本文需要
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，同时保存到云知识，更方便管理
加入VIP
还剩47页未读，
定制HR最喜欢的简历
你可能喜欢MQTT网关使用方式
物通博联MQTT网关主动采集设备数据，并进行协议解析，解析后数据经过标准化后，用MQTT协议作为上行链路接入协议，通过消息发布服务器上的相应主题上，用户自主开发的软件系统/云平台通过订阅消息该主题而获取数据。当软件系统/云平台要向设备发送指令或者写入数据，应用软件系统/云平台就发布一条消息到相应的网关上，然后网关在把数据传送给设备；从而实现软件系统/云平台和现场设备的数据上报和控制。
1、购买一台物通博联MQTT网关
&&&如果使用4G、3G上网方式，需要购买物联网卡（可以联系物通博联物联网卡销售工程师或者直接找运营商购买）
2、自己构建MQTT服务器，并根据物通博联该文档开发软件系统及构建云平台。
3、有资金预算的，可以直接购买物通博联数据云平台，然后通过Restful API,快速开发。
物通博联提供两种开发方式：
&&&&（一）、用户采购物通博联MQTT网关，直接对接自主开发的云平台，用户自主搭建MQTT服务器并开发属于自己的云平台。其中物通博联MQTT网关可以实现对各种现场设备的数据采集、解析并标准化后上传到云平台。
&&&&&（二）用户采购物通博联MQTT网关和物通博联WIOT-DCloud物联网数据云平台，直接通过Restful
API快速开发云平台系统；其中物通博联WIOT-DCloud物联网数据云平台提供优化的MQTT服务端功能、提供工程配置和设备管理功能、提供时序数据库和关系型数据库，用户只需要通过HTTP
API接口直接获取数据，进行数据分析和数据展现。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}