MQTT未接收到消息问题

根据接口文档订阅MQTT消息，没有接收到消息；

使用>花开半夏
面向物联网的21个开源软件项目有哪些,物联网开源平台搭建
admin 07-26 04:41 166次浏览
2019独角兽企业重金招聘Python工程师标准
51CTOcom直译物联网市场呈现碎片化、无定形化、不断变化的特征，其性质通常只需关注互 *** 作性。 难怪开源在这方面不俗。 ——客户犹豫不决，害怕将物联网的未来寄托在可能难以定制或互联的专有平台上。
本文介绍了主要的开源软件项目，重点讨论了面向家庭和工业自动化的开源技术。 我们忽略了专注于垂直领域的物联网项目，如Automotive Grade Linux和Dronecode。 我们还忽略了面向互联网的开源 *** 作系统发行版，包括Brillo、Contiki、Mbed、OpenWrt、Ostro、Riot和Ubuntusnappping。这次，我们将智能
这里介绍的21个项目包括由Linuxfoundation管理的两个大型项目： Allseen(Alljoyn )和ocf (iotivity )，以及物联网传感器的端点和网关我还介绍了几个专门针对物联网生态系统特定领域的小项目。 我们曾介绍过更多的项目，但越来越难分清物联网软件和普通软件的区别。 从嵌入式环境到云，越来越多的项目都带有物联网元素。
您声称这21个项目都是开源的，但请确保完整的名称不在本文的范围内。 它们至少在生态系统的一个部分运行Linux，大多数都完全支持Linux，从开发环境到云/服务器、网关和传感器端点部件。 大多数组件都有可以在Linux开发板(如Raspberry Pi和BeagleBone )上运行的组件，大多数都支持Arduino。
物联网领域仍然有很多专有技术，特别是在自上而下的企业平台上。 但是，其中也提供了部分开放访问权限。 例如，威瑞森的ThingSpace针对4G智慧城市APP应用，拥有一套免费的开发API，支持开发板，尽管核心平台本身是独一无二的。 相似的是，亚马逊的AWS物联网工具包包括部分开放的设备SDK和开源入门工具包。
其他主要的专有平台包括苹果的HomeKit和微软的Azure物联网工具包。 在拥有230个成员的Thread Group中，该组织监督基于6LoWPAN的对等Thread网络协议。 Thread Group由谷歌的母公司Alphbet旗下的Nest设立，没有提供像AllSeen和OCF那样全面的开源框架。 但是，它与Brillo相关，也与Weave物联网通信协议相关。 5月，Nest发布了名为OpenThread的开源版Thread。
介绍21个面向物联网的开源软件项目。
AllseenAlliance(Alljoyn ) )。
由Allseenalliance(asa )监管的AllJoyn互 *** 作系统框架可能是市场上采用最广泛的开源物联网平台。
Bug Labs dweet和freeboard
bugglas是从制造基于模块化Linux的有bugh的硬件设备开始的，但很久以前就演变成了与硬件无关的企业级物联网平台。 Bug Labs提供“dweet”消息、警告系统和“freeboard”物联网设计APP。 dweet使用HAPI Web API和JSON来帮助发布和描述数据。 freeboard是一种拖放式工具，用于设计物联网仪表板和可视元素。
DeviceHive
DataArt基于AllJoyn的设备管理平台可以运行在许多云服务上，包括Azure、AWS、Apache Mesos和OpenStack。 DeviceHive专注于使用ElasticSearch、Apache Spark、Cassandra和Kafka，分析大数据。 有些网关组件可以在运行Ubuntu Snappy Core的任何设备上运行。 模块化网关软件与DeviceHive云软件和物联网协议配合使用，作为Snappy Core服务进行部署。
DSA
分布式服务架构(DSA )便于集中式设备的互 *** 作性、逻辑和APP应用。 DSA项目正在构建分布式服务链接(DSLinks )库，以支持协议转换以及与第三方数据源的数据集成。 DSA提供了一个可扩展的网络拓扑，其中包括多个DSLinks，用于在连接到分层代理分层结构的物理互联网边缘设备上运行。
EclipseIOT(Kura ) )。
Eclipse基金会的物联网主要围绕基于Java/OSGi的Kura API容器和聚合平台，支持在服务网上运行的m2m APP应用。 Kura基于Eurotech的Everywhere Cloud物联网框架往往与Apache Camel集成，后者是基于Java的基于规则的路由和中介引擎。 Eclipse物联网子项目包括Paho消息传递协议框架、面向轻量级服务器的Mosquitto MQTT体系结构和Eclipse SmartHome框架。 有些项目实现名为Californium的基于Java的受限APP应用协议(CoAP )。
Kaa
CyberVision支持的Kaa项目为云互联的大型物联网提供了可扩展的端到端物联网框架。
该平台包括一种支持REST的服务器功能，可用于服务、分析和数据管理，通常部署成由Apache Zookeeper协调的节点集群。Kaa的端点SDK支持Java、C++和C开发，负责处理客户机/服务器通信、验证、加密、持久性和数据编排。SDK包括针对特定服务器、支持GUI的模式，这些模式可转换成物联网物件绑定。模式治理语义，并抽象一组迥异设备的功能。
Macchinaio
Macchinaio提供了一种“支持Web、模块化、可扩展的”JavaScript和C++运行时环境，可用于开发在Linux开发板上运行的物联网网关应用程序。Macchinaio支持一系列广泛的传感器和连接技术，包括Tinkerforge bricklet、XBee ZB传感器、GPS/GNSS接收器、串行和GPIO联网设备以及方向感应器。
GE Predix
GE面向工业物联网的平台即服务(PaaS)软件基于Cloud Foundry。它增添了资产管理、设备安全、实时预测分析，并支持不同数据的采集、存储和访问。GE Predix是GE为内部运营而开发的，它已成为最成功的企业物联网平台之一，收入大约60亿美元。GE最近与HPE达成了合作伙伴关系，HPE将把Predix整合到自己的服务中。
Home Assistant
这个作为后起之秀的草根项目提供了一种面向Python的家居自动化方法。
Mainspring
M2MLabs的基于Java的框架针对远程监控、车队管理和智能电网等应用领域中的M2M通信。与许多物联网框架一样，Mainspring高度依赖REST Web服务，并提供了设备配置和建模工具。
Node-RED
这种面向Nodejs开发人员的可视化布线工具拥有基于浏览器的数据流编辑器，可用于设计物联网节点当中的数据流。然后，节点可以迅速部署成运行时环境，并使用JSON来存储和共享。端点可以在Linux开发板上运行，支持的云包括Docker、IBM Bluemix、AWS和Azure。
Open Connectivity Foundation(IoTivity)
英特尔和三星支持的开放互联联盟(OIC)组织和UPnP论坛组成的这个组织正在努力成为物联网方面领先的开源标准组织。OCF的开源IoTivity项目依赖充分利用的JSON和CoAP。
openHAB
OpenIoT
这款基于Java的OpenIoT中间件旨在使用一种公用云计算交付模式，为开放、大规模的物联网应用提供便利。除了表示物联网物件的本体、语义模型和标注外，该平台还包括传感器和传感器网络中间件。
OpenRemote
OpenRemote为家庭和楼宇自动化而设计，它以广泛支持众多智能设备和网络规范而出名，比如1-Wire、EnOcean、 xPL、Insteon和X10等规范。规则、脚本和事件都得到支持，还有基于云的设计工具，可用于用户界面、安装、配置、远程更新及诊断。
OpenThread
这是Nest最近从基于6LoWPAN的物联网Thread无线网络标准分离出来的开源项目，它还得到了ARM、Microchip旗下的Atmel、Dialog、高通和德州仪器的支持。OpenThread实现了所有Thread网络层，还实现了Thread的端点设备、路由器、Leader和边界路由器等角色。
Physical Web/Eddystone
谷歌的Physical Web让蓝牙低能耗(BLE)信标可以将URL发送到智能手机。它针对谷歌的Eddystone BLE信标经过了优化，这提供了除苹果的iBeacon之外的一种开放技术。其想法是，行人可以与任何具有BLE功能的支持性设备(比如汽车停放计时器、标牌或零售产品)联系。
PlatformIO
基于Python的PlatformIO包括IDE、项目生成器和基于Web的库管理器，它是为访问来自基于微控制器的Arduino和基于ARM Mbed的端点的数据设计的。它为200多种板卡提供了预先配置的设置，并与Eclipse、Qt Creator及其他IDE整合起来。
The Thing System
这种基于Nodejs的智能家居“监管”软件声称支持真正的自动化，而不是简单的通知。其自学习人工智能软件可处理许多协同式M2M *** 作，不需要由人干预。缺少云组件恰恰提供了更好的安全性、隐私性和控制性。
ThingSpeak
成立五年的ThingSpeak项目专注于传感器日志、位置跟踪、触发器及提醒以及分析。ThingSpeak用户可以使用用于物联网分析和可视化的MATLAB版本，不需要向Mathworks购买许可证。
Zetta
Zetta是一种面向服务器的物联网平台，利用Nodejs、REST和WebSockets构建而成，奉行基于数据流的“响应式编程”开发理念，用Siren超媒体API连接起来。设备被抽取成REST API，用云服务连接起来，这些服务包括可视化工具，并支持Splunk之类的机器分析工具。该平台可将Linux和Arduino开发板之类的端点与Heroku之类的云平台连接起来，以便构建地理分布式网络。
转载于:>MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。我们可以从这里下载该项目的实例代码，并且可以找到一个采用PHP书写的服务器端实现。架构如下所示：wmqttjar 是IBM提供的MQTT协议的实现。你可以从如下站点下载它。你可以将该jar包加入你自己的Android应用程序中。Really Small Message Broker (RSMB) ，他是一个简单的MQTT代理，同样由IBM提供。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。SAM是一个针对MQTT写的PHP库。你可以从这个下载它send_mqttphp是一个通过POST接收消息并且通过SAM将消息发送给RSMB的PHP脚本。实例代码：Ø 采用XMPP协议实现Android推送这是我在项目中采用的方案。事实上Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。androidpn是一个基于XMPP协议的java开源Android push notification实现。它包含了完整的客户端和服务器端。经过源代码研究我发现，该服务器端基本是在另外一个开源工程openfire基础上修改实现的，不过比较郁闷的是androidpn的文档是由韩语写的，所以整个研究过程基本都是读源码。它的实现示意图如下：androidpn客户端需要用到一个基于java的开源XMPP协议包asmack，这个包同样也是基于openfire下的另外一个开源项目smack，不过我们不需要自己编译，可以直接把androidpn客户端里面的asmackjar拿来使用。客户端利用asmack中提供的XMPPConnection类与服务器建立持久连接，并通过该连接进行用户注册和登录认证，同样也是通过这条连接，接收服务器发送的通知。androidpn服务器端也是java语言实现的，基于openfire开源工程，不过它的Web部分采用的是spring框架，这一点与openfire是不同的。Androidpn服务器包含两个部分，一个是侦听在5222端口上的XMPP服务，负责与客户端的XMPPConnection类进行通信，作用是用户注册和身份认证，并发送推送通知消息。另外一部分是Web服务器，采用一个轻量级的>1Unicode是什么Unicode（中文：万国码、国际码、统一码、单一码）是计算机科学领域里的一项业界标准。它对世界上大部分的文字系统进行了整理、编码，使得电脑可以用更为简单的方式来呈现和处理文字。简单说来，就是把世界上所有语言的字，加上所有能找到的符号（如高音谱号、麻将、emoji）用同一套编码表示出来。2UTF-8是什么UTF-8（8-bitUnicodeTransformationFormat）是一种针对Unicode的可变长度字符编码。可变长度的意思在于，如果能使用1字节编码，UTF-8绝对不会使用2字节去表示。举个例子，UTF-8的1字节部分和ASCII码是相同的。所以表示'A'这个字符的时候，UTF-8与ASCII码不仅编码相同，而且都是只使用1字节。3CharacterSet和Collation是什么CharacterSet是一套符号以及编码。Collation是characterset的排序方法。在中文版的MySQL中，characterset被翻译为“字符集”，collation被翻译为“整理”。举个例子，UTF-8是characterset，utf8_unicode_ci和utf8mb4_unicode_ci就是collation。Collation的作用主要有二：字符排序与查找字符。字符排序的作用是显而易见的，不过还是要用几个例子加以说明。比如要比较a和b的大小，因为在26个英文字母里面，a在b前，所以在编码的时候，也把a放在b前面。这样就产生了第一种排序方式，通过字符编码的大小来排序。而在中文里面，“年”和“日”的排序，除了按照字符编码大小，还可以有另外一些标准。比如可以按照笔画序，“年”的第一笔是丿，“日”的第一笔是丨，而丨是排在丿前的，所以就将“日”排在前面；也可以按拼音序，“年”是n开头，“日”是r开头，于是把“年”排在前面。除此以外，还可以定义部首序、笔画数序等等，而不同的排序方法会有不同的结果。英文也有大小写敏感与不敏感的排序方式。种种不同的排序方式，就形成了不同的collations。Collation的第二个作用则是查找字符是否在一个字符集里面。既然是一个有序的集合，则可以快速地通过一个编码值确定一个字符是否在集合内。这个特性是我们在不知不觉中使用的。比如使用中文输入法，就是通过输入法找到一个编码，通过collation把它查找出来的。4Unicode再深入：Plane和中日韩越统一表意文字utf8_unicode_ci和utf8mb4_unicode_ci这两个collations都是基于UTF-8编码的，但排序方面或多或少会有差别。可是更大的差别是它查找字符的集合。这需要提到一个Unicode的概念：Plane。41PlanePlane中文译作“Unicode平面字符映射”，不过我们还是叫它plane好啦。目前的Unicode字符分为17个planes，而每个plane拥有65536（即2^16）个代码点。可以认为一个plane就是一个范围的编码。Plane0也叫做BMP（BasicMultilingualPlane，基本多文种平面），存放着世界上各种语言与标记中最常用的字符。Plane1也叫做SMP（SupplementaryMultilingualPlane，多文种补充平面），放着表情符号（emoji）、字母与数学符号、音乐符号、太玄经（太极符号）、装饰符号、扑克牌、麻将符号、箭头扩展和一些世界上各种语言不太常用的文字等等。Plane2也叫做SIP（SupplementaryIdeographicPlane，表意文字补充平面），用于存放统一汉字（见42）的一些罕用字与汉藏语系其他语言的用字（如粤语用字）。42统一汉字的分布对于统一汉字（中日韩越统一表意文字，CJKVUnifiedIdeographs）来说，BMP存放着最初的版本（也是最常用字）与扩展A区的汉字。扩展B区到即将到来的扩展E区都放在SIP中。在这些区中，除了独立字源的字，还有同一个字源或部首不同的变体或写法。比如“户”的第一笔，中国大陆与香港写作“户”，台湾写作“户”，日本则写作“戸”。这些差异也会在Unicode中用三个不同的编码去表示。所以B区到E区有不少此种字体。举些B区的例子。网络上之前流行的“不会功夫不要艹我”被写成““xx巭嫑莪”，其中“xx”这个字就是在B区。而粤语“x鸡”（阉鸡）、“x完松”（和一个人发生关系后弃之而去）两个词的首字也是在B区。5utf8_unicode_ci和utf8mb4_unicode_ci的异同这两种collations所对应的字符都是UTF-8编码的一个子集。utf8_unicode_ci最多能找到3个字节的Unicode编码，而utf8mb4_unicode_ci则能找到4个字节的编码。由于调整后的UTF-8编码格式规定最多使用4字节（原来是6字节）编码，所以utf8mb4系列可以说是覆盖了整个Unicode编码。由于utf8_unicode_ci最多能找到3个字节的编码，意味着它只支持BMP中的字符，对于SMP与SIP以及其他头一字节不为0x00、需要4字节编码的planes来说，utf8_unicode_ci这种collation是无法支持。当使用4字节的字符（如emoji与B区以后的统一汉字）对使用此种collation的字段进行增删查改时，数据库会报一个非法字符的异常。而utf8mb4则没有此问题。由此也看出，utf8mb4_unicode_ci是utf8_unicode_ci的超集。6utf8mb4_unicode_ci的优缺点utf8mb4系列的Collation在MySQL55以上开始支持。相比起utf8_unicode_ci，它有如下的特性：1)在数据表中，对于BMP中的字符（最多使用3字节的字符，最常用的字符），两种collations具有完全相同的存储特性：相同的码值，相同的编码方式，相同的存储长度。不会增加任何的存储开销。2)在数据表中，对于其他plains的字符，utf8系列的collation根本不能存储，而utf8mb4系列的collations则可以存储。3)在数据表中，对于变长的字段（如VARCHAR2，TEXT），utf8mb4最大可存储的字符可能少于utf8系列的collation。4)在索引中，对于文本类型的字段，utf8mb4可索引的字符少于utf8系列的collations。如InnoDB的索引最多使用767字节。如果使用utf8mb4，每一个字符都会预留4字节做索引，而utf8则预留3字节。故此前者是191个字符，后者是255个字符。5)由于4)的原因，加上字符集大，utf8mb4的性能可能比utf8系列的collations低。6)若升级前的字段做了索引，需要把索引字符限制在191字符或以内。7当前系统用哪个好在当前的系统，全部都使用utf8_unicode_ci这种collation。但是在存储网页标题时，标题带有SMP或者SIP的字符，如emoji、粤语字，会引发数据库写入异常。于是，就有两种解决方向：1)扔掉。11)扔掉或截断引发异常的字。采取此种方法，需要对每一个标题进行扫描。12)扔掉整条记录。可以采取扫描法，或者扔掉引发异常的记录。2)升级到utf8mb4。会略为降低数据库性能。71性能考虑首先对于写入性能，查找字体的性能损耗由于在写入前字符都已经变成编码，基本可以忽略。对于网络传输的性能，则需要继续查找相关资料继续查证。但初步估计由于目前数据库在本地，故此这部分开销的增长不太明显。而对于索引的性能，由于网页标题这一字段没有做索引，在可预见的将来也未有此计划，故此没有性能的损耗，也没有升级兼容性的担心。况且，倘若走扔掉数据的方向，若采取扫描法，则需要付出扫描的开销。若采取扔掉记录法，则会先触发事务回滚，其他记录需要下次重新写入。而且当一批记录写入时有k个记录引发异常，则需要回滚与重试k次，除非使用扫描法预先扫描出这些异常的记录。但这也会引入额外的程序与数据库开销。若不使用事务，则数据库总体写入性能会大为降低。虽然没有实测过，但从感觉上来定性判断，似乎扔掉记录比升级collation带来的性能退化要大。72存储空间考虑当前的网页标题是使用VARCHAR2存储。对于现在可用的、常见的BMP字符，不会引入额外的存储开销。BMP字符在VARCHAR的类型下不会为每一字符引入额外33%的空间开销。反之，定长的CHAR就会引入这种额外开销。73目标数据考虑网页标题作为以后特征分析的数据源。在分析需求完全没有确定的情况下，我认为扔掉任何数据都是不宜采取的法，特别是整条记录扔掉更是不推荐。因为现阶段我们没有一套标准去判定何为有效数据、何为无效数据。有可能引发异常的那部分数据确实是没用的数据，也有可能那部分人群更倾向于在我们平台上活跃使用。既然各种可能性都存在，我们主动放弃一部分可能性，似乎不太恰当。74API设计与兼容性考虑由于utf8_unicode_ci与utf8mb4_unicode_ci都是使用UTF-8编码，所以对于JAVA，使用MyBatis生成的代码是一样的，都是使用String类型。这点已经实测过。加上这两种collations在BMP中的编码完全一致，所以使用3字节与4字节的系统，对于BMP中的字符都是完全兼容、正常显示的。而对于3字节的系统，4字节的字符一般会显示成一个方框，或者在一个方框中有几个小数字，不会引发系统异常。8总结诚然，emoji对分词分析目前来说还没有什么效果，粤语词而且在SIP中也只是其中一部分，也不知道有多少日本动漫或者爱情动作片的网页会遇到这些生僻字，音乐符号也少人用，太极符号也不是每次都出现，一些数学增补的字符与箭头增补图案也不是每个人都会用。这些加起来可能不知够不够全部的千分之一。但是倘若每一两个小时就会由于字符不能写入，引发数据库的异常。通过上面的分析，我认为增加这种兼容性带来的成本是可以接受的。故此，我建议使用升级的方法，兼容所有Unicode字符。

---