物联网喊了多少年了，总是雷声大雨点小，厂商多应用少；在电商里也可以看到，智能硬件呈现三多三低的尴尬境地：品种多，厂商多，卖家多，销量低，价格低，评价低；产业见都没有见过蓝海，就已经在红海搁浅了。究其原因，无法实现智慧互联，联而不慧是主因。物联网的中心思想在于连接之后的智慧，而现有产品，多呈现出孤岛状态，顶多同一个厂商的产品之间，勉强实现互操作。

我在这篇博文“http://blog.csdn.net/djyos/article/details/46363593”中提到，物联网中有两道很难绕过去的坎，一是物体识别，二是物体沟通。正是这两道坎，导致了智能硬件之间互联而不智慧的问题，并初步提出了局部的解决方案，所谓局部，就是说，该解决方案并不能解决全部问题，只能部分地化解问题。在这里，我将进一步细化该解决方案。

识别和沟通，都没有标准，而且在可见到的将来，也不可能有标准。这使得网络中的物体，各自自言自语，无法沟通对话，更加无法互操作，物联网要实现智慧互联，路很长，很艰难。

虽然难，但不能不走，各开发工具厂商，都盯上了这块肥肉，各自推出了其解决方案。下图为一个典型的解决方案示意图：

    各家的方案，共同的特点是，在智能设备端，提供一个操作系统，以及联网所需的基本组件，高端些的，还提供脚本语言支持。在手机端，提供一个sdk包，该sdk包提供手机与智能硬件端互操所需要的api，自定义一套命令和数据格式。由于各厂家定义的命令和数据格式并不一致，导致其开发的产品，只能保证同一个厂家开发的产品互联互通。要所有智能硬件互联协作，这能一个厂商就包揽了网络中的所有产品，号称为一揽子解决方案，只用你一家的产品就可以了。这实质是限制了用户的选择权，用户不可能为了让智能家居运转起来，家里所有电器都选购同一个厂商的的吧，生产电冰箱的厂家，也不太可能生产跑步机吧；又比如智能工厂，要求用户的所有智能工业设备，使用同一个厂商的，也不可能；智能交通，要求路网中的所有设备和汽车来自同一个厂商，更加天方夜谭了。不同的厂商，即使用相同的开发工具，所开发出来的APP和智能硬件，也是不能互联互通的。以现在最火的智能家居为例，如果你家里安装了海尔的智能冰箱，美的的智能微波炉，西门子的智能热水器，创维的智能电视，格力的智能空调，还有各种智能开关，温度、湿度传感器等等。请问，你手机中需要安装多少APP，会不会烦死用户。

    物与物之间的识别和沟通，解决起来很困难，我们能不能退而求其次，先解决物与人之间的沟通呢？

    物与人之间，无非是通过人机界面，通过人机界面，不同厂商间设备不能互通，问题在哪里呢？问题在于，开发工具想多了，把简单问题复杂化了。比如空调，一个“温度下降”按钮，无论哪家的设计，用户都能一眼就认出来，用户按下该按钮后，开发平台开始不安分了，把“按下降温按钮”这个事件，翻译成一个特定的命令码，例如0x80，发下去给空调。空调如果是同一个厂商开发的，就知道代码0x80代表温度下降。如果是别的厂家开发的呢，天知道0x80代表什么意思，说不定就关机了呢。进一步地，如果你在空调本身的人机接口界面上直接按按钮，还会有问题么？立马脑洞大开，只要你不翻译，让用户的界面远程显示在手机上，用户按手机上的按钮，就像按空调上的按钮一样，互通的问题，不就被绕过去了么？这，不就是远程桌面么？原来，远程桌面能解决物联网中缺乏标准的情况下的物与人之间的协作问题。

标准包含了巨大的利益，标准之争是政治斗争，就是无赖扯皮，物联网中物体的的识别和沟通标准，不要说不可能有，即使能定出来，也是猴年马月的事。与其企图制作标准，或者等待标准，还不如绕过去，不需要标准，也能实现功能，这就是远程界面。

远程界面把复杂的联网开发，变成简单的单机开发。原来需要同时开发智能硬件和手持设备（通常是手机）端的应用程序，现在只需要开发智能硬件端的了。

远程界面的实现方案，有两个，HTML和远程桌面，具体的论述，已经在这篇博文中了一些，http://blog.csdn.net/djyos/article/details/46363593，在该文中讲过的，这里就不重复了，在这里进一步细化一下HTML5和远程桌面各自的特点和适用范围。

HTML5：智能硬件端需要webserver，技术相对复杂，很灵活，编程难度较大，CPU资源要求高，且容易引起不兼容的问题，网银以及很多网站挑浏览器的问题，大家都知道的。HTML5在动画等动态显示方面有无可比拟的优势，适合于界面要求很花哨的消费品。对于工业物联网应用，要求高可靠性和高实时性，遵循简单可靠的原则，一般仍然使用c语言开发，不太喜欢HTML5这样复杂的技术的。本地有LCD时，需要独立设计本地UI，难于保证本地UI和远程UI一致性。

远程桌面：直接使用djygui即可，或者使用其他支持远程桌面的rtos，技术简单可靠，编程难度低，CPU资源需求低，没有兼容性问题，无论本地有没有LCD都可以自动适应。流量中等，如果是WiFi本地通信，动画也不成问题，远程则比较消耗流量。非常适合工业控制场合，例如智能工厂内部。

如果使用HTML5，在页面设计时，必须如实地把用户的操作“告诉”智能硬件，而不能自作聪明地做编码转换，例如把用户的控制命令翻译成编码命令。例如用户按下空调向下的按钮，你就告诉智能硬件，用户按了向下的按钮，不要用诸如03表示降温，04表示升温这样的编码。这是许多用户都容易犯的错误，远程桌面则没有这个问题。

 

	HTML5	远程桌面
复杂性	需要webserver，复杂度高	直接使用djygui，或其他支持远程桌面的rtos，简单可靠
兼容性	很灵活，容易引起兼容性问题	无兼容性问题
易用性	Webserver，编程比较复杂	按本地有UI设计，非常简单
硬件需求	高，内存要求M级	低，几十K内存即可
本地UI设计	本地有UI时，需要独立设计，难于保证本地UI和远程UI一致性	本地有UI和无UI，设计方法完全一样，本地UI和远程UI天然一致
通信带宽	低	中，播放动画时要求带宽高
界面质量	高，可以做很花哨的界面	中，带宽高的话也可以做动画
适用场合	硬件强大，需要很花哨界面特别是有动画的消费品。	硬件要求低，简单可靠，适用于界面不复杂的消费品，以及工业物联网

 

    远程界面，还是打破巨头垄断的利器，你想，巨头们布下一张网，网中设备，都按他们的SDK开发，例如腾讯的QQ物联，他们会定义好所有的接口，你只要按照接口实现功能，中小创业者几乎没有任何创新空间，只能沦为替腾讯搬砖。即使如此，不同厂商之间的设备，依然无法互通。而如果是远程桌面，因为手机仅仅充当智能硬件的显示器和触摸屏，具有天生的开放性，任何厂商的设备，只要支持远程界面，都可以自由接入，完全自己定义自己的功能，不受APP预设的功能限制。

    加速物联网产业的发展，物体识别和沟通的问题，是阻碍物联网发展的两大门槛，远程界面方案，虽然没有解决物与物之间的沟通问题，但解决了物与人之间的沟通问题，必定会促进物联网产业的发展。

主页：www.djyos.com

djyos是国内唯一由大企业出资开发的、类bsd许可证发布的，功能完整的RTOS，欢迎关注。