这问题很好，一针见血，它解决什么问题？

那这得说说，在IoT应用中，我们会碰到什么问题？

和纯软件项目，互联网项目比，IoT应用项目一个比较大不同的地方，应该是它既要做软件，又要做硬件。

我并不是硬件方面的专家，我比较强的背景是在软件开发领域。

我从一个软件开发者、系统架构师、项目负责人的角度来看这个问题，IoT应用开发中，我们碰到的困难，遇到的问题是什么？

即使我从纯软件开发背景的开发者角度来看，硬件开发也并不是IoT应用的问题所在。

在我负责的IoT项目当中，我下面会有硬件团队，有硬件工程师，有嵌入式开发程序员。

我需要负责项目的整体设计，我需要跟软件开发者、硬件开发者在一起开会，做设计、核对协议、拆分工作任务、制定开发计划… …

开发硬件并不是问题所在。

团队里会有硬件工程师，嵌入式开发程序员。在物联网出现之前，在硬件开发这个领域，早就有很多硬件工程师，嵌入式开发程序员，大家每天忙忙碌碌，辛苦的做着开发了。

那让我觉得有问题的是什么？

我们需要给传统的硬件，添加通讯能力，并把它接入到互联网中去 。为何给硬件添加通讯能力，会比传统的互联网应用更加困难呢？

我们开发物联网应用时，相较传统互联网应用来说，会碰到：

多端和多协议带来的复杂性

这个问题从何而来？两个原因。

• 更多端，智能硬件和网关

  我们谈论互联网应用系统架构时，我们会说：客户端、瘦客户端、移动端，服务器端。

  在IoT应用里，这些端都还在，全都还在。

  我们还会说，智能终端、网关端。

  看上去就多了两端，应该不叫事嘛！

  问题在于，客户端、瘦客户端、移动端，服务器端，这些传统技术已经相当成熟了，我们有高性能的服务器，有功能霸道的PC机，我们还有其实是全功能电脑的智能手机。

  即使是这里边，算是新技术的智能手机技术，大家还记得第一代iPhone是什么时候发布的吗？

  那是2007年1月，从此人类进入了智能手机的时代。当然，android也不甘人后，2008年9月，第一部使用Android操作系统的手机诞生了。

  智能终端、网关端，怎么说呢，我在另一篇文章一些关于智能硬件的随想里说：是的，现在可以认为，智能硬件的计算能力，已经得到了突破。

  是的，我们已经开始进入了智能硬件的时代。

  问题在于，我们刚进入这个时代，技术虽然已经突破，但是还不够成熟。想想第一代iPhone，现在再让你使用这款手机，你会不会想把它砸掉？

  何况，我们还在疯狂追逐着、期待着，能出现更小、更轻、更便宜的智能硬件。

  多出来的这两端，并没有那么简单。

• 更多协议

  这个问题从何而来？下面我摘取LIthosphere文档当中的一段内容来说明吧

  以下内容来自Lithosphere官方文档

  在IoT的世界里，不仅仅有传统互联网和移动互联网通讯，还会涉及到各种IoT专用通讯协议。

  这是因为IoT应用的终端部署地点和部署环境，较传统互联网和移动互联网来说，更为复杂和多变。

  就部署地点来说，IoT应用的终端，不仅会部署在住宅、办公楼、商场、工厂里，还可能会部署在牧场、田野、森林、河流 … …

  不仅是终端部署地点会带来通讯的复杂性，部署环境往往也会提出特定的通讯需求。在城市办公楼里，厚厚的墙可能会阻挡通讯的信号；在现代工厂里，各种生产设备和仪表，会带来各种信号干扰 … …

  不同的的IoT应用还会带来不同的通讯需求，有些应用需要有更远的通讯距离；有些应用需要更高的通讯速率 … …

  无线和低功耗往往是IoT专用通讯协议的硬性要求。这是因为：

• 由于部署地点、部署环境的变化多端，在一些地方和场合，无法搭建供电线和提供基础网络环境。

• 很多应用的部署地点，可能会交通不便，难以频繁到现场充电和换电池。

• 在一些应用中，部署节点会数量较多，成千上万个终端节点，难以对这些节点进行供充电维护。

IoT应用节点部署地点的复杂性、部署环境的复杂性，应用通讯需求的复杂性全部加在一起后，我们就看到了下面这些：

• NFC
• RFID
• BlueTooth
• Zigbee
• NB-IoT
• LoRa
• Sigfox
• HTTP
• MQTT
• CoAP
• Z-Wave
• XMPP
• …
• …

人类雄心勃勃，尝试连接万物。

但是，却发现这事并没有那么简单哈！

注意：Lithosphere官方文档内容结束。

多端和多协议带来的复杂性，在开发中的表现是什么？

也说两个点：

• 不断的转换和翻译通讯协议

  终端和网关的通讯，由于在IoT网络中，考虑到IoT网络多是低能耗和低速率的，我们最好是使用二进制通讯协议。

  网关到服务器，上报数据得确保信息抵达，可以考虑使用MQTT哦！

  使用移动端控制查看终端设备，用JSON，用Resetful Web Service。哼！套路，完全是套路！

  服务器端服务的互相调用，能用RPC不？发布SDK包，协议对象一设置，API一调用，多愉快呀！

  当这些都放在一起后，就会发现，我们一直在不断的翻译/转换各种协议，虽然有可能它们表达的是同样的业务含义，我们却需要把它翻译成不同技术，不同格式。

• 拼凑各种技术的整体解决方案

  IoT网络里，终端和网关端，我们得用嵌入式各种技术，C/C++，汇编。

  互联网通道，Ok，MQTT，用它的API，它支持各种编程语言呢，多方便呀！

  服务器端，移动端，天啦，这不就是常规互联网开发技术嘛，这还叫事？

  于是，我们安装嵌入式开发工具，部署MQTT服务器，搭建Spring Framework框架代码，安装部署数据库，考虑如何做服务器端分布式集群。

  对了，还得开发手机App，Native开发技术，还是Hybrid开发技术，那个更好些？

  当这些拼凑在一起后，我们发现，原来开发IoT应用，需要解决这么多技术问题啊！

一个经验还算丰富的软件开发者的亲身感受

我做过不少复杂项目，从技术的角度来说，我并不觉得这IoT项目中，什么技术特别难，什么技术会卡住解决不了。

问题在于，为啥我们要不停的翻译不同协议，为啥要每个版本，都要找各端开发团队来制定和核对协议，然后不同端出不同的协议文档。

为啥我们需要安装这么多不同的基础软件、中间件、数据库… …

好麻烦啊！稍有不慎，又报错了！

解决方案，解决方案，我需要新的解决方案！！！

哈哈，技术总是在不停的进步的！

在我创业做IoT的那个时间点，还没有阿里IoT、华为IoT云呢。

当然，现在已经出现了一些解决方案，现在有了IoT云，有了一些开源IoT平台。

大家都在尝试怎样来简化IoT的开发，将IoT应用开发技术云化，看上去是一个挺不错的思路。

既然IoT开发这么麻烦，涉及到的技术太多，我们把这些复杂性，都放到云后面去，把简单的云API开放给开发者，这不就简单了吗？

不错的想法，我们都知道，云计算技术，给IT行业带来了变革，云计算技术可以简化应用开发。

还有还有其它解决方案吗？我看到有一些开源的IoT技术平台，在尝试简化IoT的开发工作

我怎么看这个问题，Lithosphere是用什么思路来解决问题呢？

我是一个经验很丰富开发者啊，我开发过基础软件，做过手机OS（定制Andriod），搞过一些相较复杂的项目。

我不想只是简单的使用别人提供的解决方案啊！对这事，我有自己的一些看法，有自己的一些理解。

好吧，我自己来动手做一个吧，按照自己的想法来解决问题。

于是，有了Lithosphere平台。

Lithosphere是什么？它解决问题的思路是什么？

基于以下的一些设计和技术，Lithosphere开发平台尝试简化IoT应用的开发。

• TUXP

  TUXP是Things Unified and Extensible Protocol。

  中文为智能物件统一和可扩展协议。

  我们为什么不在整个IoT应用开发中，在不同端，使用统一的通讯协议格式呢？

  这会不会让事情变简单？

  以下内容来自Lithosphere官方文档

  Lithosphere在IoT应用中，统一使用TUXP协议来简化多端和多协议问题。

  基于Lithosphere来做IoT应用开发，其它所有IoT相关协议都被屏蔽掉了，我们只使用TUXP。

  No LoRa，No JSON，No XML，No MQTT，No HTTP，… …

  Only TUXP。

  注意：Lithosphere官方文档内容结束。

• 全栈开发平台

  为了能在多端都使用统一的TUXP协议，看上去我们需要一个全栈的IoT开发平台。

  在所有端，我们能不能都用简单的API来调用TUXP，说实话，我连TUXP协议都不想学习，能不能给我简单调用的API用？

可以的，确实需要全栈解决方案。所以，Lithosphere提供了：

* Chalk

插件架构的XMPP客户端开发库。

* Granite

插件架构的XMPP服务器。

* Sand

IoT插件库，包括服务器端和客户端插件，支持硬件板和移动开发。

* Mud

硬件板IoT通讯C库。

• IoT组件开发

  能不能提供IoT概念层的组件来用，我觉得Actuator（执行器）、Sensor（传感器）、LoRa Gateway这种概念，比LoRa，BlueTooth、Zigbee这些概念，要容易理解好多。

  可以的，这主意提供上去不错。所以，Lithosphere提供了：

  • Edge Thing

    边缘设备组件。

  • Actuator

    执行器组件。

  • Sensor

    传感器组件。

  • LoRa Gateway

    LoRa网关组件

  • … …

• BXMPP

  什么？你使用XMPP作为基础协议？现在不是流行MQTT吗？XMPP这么重，它能用吗？

以下内容来自Lithosphere官方文档

在IoT开发中，使用XMPP协议，可能会遭到最大的质疑是，基于XML的BXMPP，通讯效率太差了，这个协议不适合用于需要高效通讯的IoT应用。

解决方案是什么？其实有一个公司，已经为我们做出了最佳示范。

这个公司是WhatsApp。它使用叫名为FunXMPP的XMPP二进制变种协议，来支撑全球20亿IM用户的使用。

Lithosphre也提供了XMPP的二进制变种协议，来改善通讯效率问题。这个二进制XMPP变种协议被命名为BXMPP。

注意：Lithosphere官方文档内容结束。

• IoT应用中的特定问题

  都这么浩浩荡荡的整了这么一套了！随便解决一下这些问题呗。

  • 设备安全注册

    以下内容来自Lithosphere官方文档

    在真实的IoT应用中，当一个IoT设备从库房中拿出来时，它并不能接通电源后立马就开始工作。

    基于安全性和利于管理的考虑，IoT设备要能够开始工作，需要经过一个“设备注册”的步骤。

    在这个“设备注册”的过程中，应用一般会：

    • 检查设备的合法性
    • 检查设备是否在此时被允许进入网络
    • 登记设备相关信息到系统中
    • 配置设备 - 例如对设备进行网络配置；发放安全token等。

    注意：Lithosphere官方文档内容结束。

  • IoT网络动态地址分配

    以下内容来自Lithosphere官方文档

    LoRa DAC是是LoRa Dynamic Address Configuration的缩写。

    中文为LoRa动态地址配置协议。

    在同一个LoRa网络中，如果想要精确控制每一个LoRa中终端节点，需要给每个终端节点配置不同的LoRa地址。

    这和TCP/IP网络很像，在本地局域网内，需要给每个主机节点配置不同的IP地址。

    地址配置，有静态配置和动态配置两种方法，在TCP/IP网络中，我们使用DHCP服务来动态分配IP地址，简化网络的配置操作。

    在LoRa网络中，目前还缺少动态分配地址的相关协议。

    Lithsphere为解决这个问题，提供了LoRa DAC协议。并内置实现了LoRa DAC协议的LoRa DAC Client和LoRa DAC Service的组件。

    注意：Lithosphere官方文档内容结束。

  • 其它… …

    Lithosphre尝试解决开发IoT应用中会碰到的各种问题，简化开发工作。

    IoT特定问题的解决方案，被封装在Lithosphere平台里，不再一一赘述。

    目前这个版本，大概就是这些东西了。

  这个开源解决方案，使用效果如何？

  用Hello，LoRa教程例子来说明一下现状。

以下内容来自Lithosphere官方文档

• 使用UART串口通讯，我们可以在Linux系统中，集成使用较复杂的外部通讯模块，例如本教程中的LoRa模块。

• IoT专用网络协议，不兼容互联网的TCP/IP。所以，我们需要使用IoT网关来帮助IoT终端连接到互联网。

• 相较于传统互联网应用，IoT应用会涉及到更多端和更多协议，这给IoT应用带来了额外的复杂性。

  为简化这个问题，Lithosphere使用TUXP协议来屏蔽其它的IoT协议。

• 在通讯协议层，由于我们使用TUXP和OXM技术，我们只需要定义协议对象，然后在开发API中直接使用它。我们定义的协议对象，从移动端App开始，通过服务器、IoT网关，最终直达IoT终端设备，这个过程不需要做任何协议翻译解析相关的任何工作。

• 使用LoRa网关插件，我们用不到100行代码，开发了一个全功能的LoRa网关程序。

• 在IoT终端，我们用95行代码，开发了LED灯终端控制程序。这其中大部分是硬件控制、协议配置、协议处理的相关代码。使用Mud库，给终端设备带来LoRa通讯能力所需要的代码数量，是4行代码。

• 在IoT专用网络里，我们使用BXMPP协议。通过简单的配置，协议包在IoT网络内被翻译成为二进制XMPP兼容协议。

  所以，我们不需要担心通讯效率问题。

• 树莓派和Arduino，都不复杂。传统的纯软件开发人员，完全可以通过使用这些硬件平台，进入到IoT应用领域。

  注意：Lithosphere官方文档内容结束。

  上面的内容有点啰嗦，简单一点说明吧：

  一个完整的IoT LoRa网络例子。手机通过服务器、网关、遥控终端硬件板亮灯、熄灯、闪灯。

• 不需要翻译任何协议，没有JSON解析，没有XML解析，也没有二进制协议解析，我们只是简单定义TurnOn，TurnOff，Flash三个协议对象（Java POJO）。

• 服务器端

  40行Java代码。

• 网关端LoRa网关

  100行Java代码。

• 终端硬件板 + LED小灯

  95行C代码。

  其中，协议配置和硬件控制90行代码。

  给硬件板带来LoRa通讯能力的代码数量，4行代码。

最后，也是最重要的

Lithosphere是开源软件，我自己会不断升级版本，给Lithosphere带来新功能。

如果你对它不够满意，fork一个来给它添加功能呗，我无比期待能有人来给Lithosphere贡献代码啊。