噩梦开始-当我集成了难用的硬件

噩梦开始-当我集成了难用的硬件

最近在做一个智慧工地的项目，本来说好的开发周期是15个工作日，可是现在已经过去一个月了，还是有些尾巴没有收掉，我们的客户总是在怀疑我们的软件开发能力不行，可是他不知道的是他买的那些硬件有多么糟糕，对我们而言几乎就是噩梦般的存在。

首先登场的是智能空开，这个需求很简单，就是通过网络socket给空开发命令，让他控制现场的灯光的开合。拿到开发文档的时候，我就感觉不好，文档表述不清，段落不清，指令不明。上面的问题还能忍，不能忍的是当我们成功建立连接，发送指令后，成功的返回了，可是空开死活就是不动作，厂家不断地和我们强调可能是网络不通畅。我就纳了闷了，网络不通，执行成功的返回是哪里来的。最后我们的硬件工程师分析他的设备，怀疑是他的mcu单片机程序出了问题，上网搜了一个类似的开源项目，冒着设备被烧坏的风险，固件烧进去，神奇的是居然解决了。

接着是空调控制器，这个东西非常简单，就是发射红外去控制空调的各种参数，可是死机，不稳定，问题接踵而来。。。。。。最后厂家回复现场空调那边红外无法反射，有时候出现不稳定，天啊！设备就是你们自己安装了，最后告诉我这个，也是十分无语，最后没有办法，只能改成继电器控制空调的开关，然后空调自我启动，记住之前的操作。

环境监测模块，温湿度、扬尘等信息，这个厂家没有让我们直接调取他的硬件数据，做了完整的封装，直接调用SDK即可，我想着总归有个靠谱的厂家了。可是，我还是太天真了，他的接口是用Java写的，部署在Windows平台下，极度不稳定，经常给我们报访问地址无法访问，这个时候，我们就得重新启动一下他的服务。最后被逼无奈，我说我直接来解析你的设备数据吧，居然给我来了个为了安全，无法提供。没办法，网络抓包，猜，终于搞定了。

还有其他乱七八糟一堆的对接问题，搞的我们心力交瘁，犹如噩梦。

这就是为什么奔骝定位的定位系统，就算界面不是那么酷炫，但是一定要让第三方对接的平稳，API的稳定性高于一切，因为我们知道，很多集成商是有上层应用的开发能力的，我们设备厂家只要提供稳定的数据就行了。

这也是为什么，我们单独成立了飞骝传感，尽量把这些常用的传感器设备自己做，因为我们真的受够了那些不稳定的设备，时间浪费不说，还给客户造成很差的体验。