当年装修选购中央空调的时候，JS号称是可以用APP远程控制的，于是就入了个坑。在安装的时候发现这个设备非常的坑，这个空调网关有两种连接方式，一种是直接通过家里的内网直连，不需要任何鉴权(安全性堪忧，只能祈求家里的内网不被入侵了)，一种是需要注册账号密码绑定到远程服务器，可以通过APP远程操控设备。

然而代理商的师傅安装现场调试的时候发现，如果不注册可以通过内网来控制。如果注册了远程账号，则内网、远程都挂掉了，还没有任何解绑的方法....

后来代理商师傅请来了大金官方的师傅，大金师傅说这设备要想解绑只能回厂冲刷。结果，愉快地注册死多个设备之后，大金师傅说不要注册了，不要远程控制了，就内网将就这用吧....据说这网关兼容性很差，有很多华为路由器用户连内网都是用不了....

这个神级的控制系统叫做DS-AIR。最近APP更新了一个版本，似乎解决掉了上述问题。不过，为了实现智能家居的统一控制，集成全硬件的自动化，为了少安装一个APP，还是决定将空调接入到HA中。在网上关注了很久，HA官方有集成大金的组件，但似乎不支持我家的这个设备，于是决定自己开发个组件，折腾的历程就这么开始了....

这个APP的网络连接基于TCP，传输协议是二进制的，单纯抓包无法解析报文结构，于是决定尝试反编译apk，通过代码解析辅助抓包来分析。

反编译一般使用ApkTool、dex2jar和JD-GUI三个工具。

ApkTool用来提取apk中的资源文件，由于我只是需要解析代码，不需要资源文件，所以没有用这个工具，直接unzip解压apk提取代码文件了。dex2jar用来将apk的dex文件还原成class文件打成jar包。JD-GUI则将jar反编译为java文件。

反解出来的代码目录结构如下，整体的反解质量还不错。

不过某些文件的代码比较奇怪，有语法错误，还有大量重复的语句，像是做了混淆。还有一些文件的部分代码没能成功反解出来，以注释代替了。另外变量名不能够还原，代码分析起来比较痛苦，不过可以借助IDE很方便的rename变量名。

消息报文格式如下所示：

报文格式为小端序，起止符号分别为02和03，具体字段定义如下：

| field | description | | start | 消息起始符02 | | length | 长度为不包含起止标识和长度位本身的消息字节数，空subbody时为16 | | subbody version | 子内容版本 | | increased ID | 消息自增ID | | device type | 设备类型 | | device ID | 设备ID | | need ack | 消息是否需要ack，0或1 | | cmd ID | 控制指令ID | | subbody content | 不同命令所附加的消息子内容 | | end | 消息结束符03 | | res | 保留字 |

分析出来的主要控制流程如下： 1.发起HandShake请求，等待响应，建立握手 2.发起GetRoomInfo请求，获取房间信息 3.发起AirConQueryStatus请求，获取各个空调状态 4.发起AirConControl请求，控制空调

期间，需要每隔60秒发送一次Heartbeat，否则网关会主动断开连接。Heartbeat格式为：

早些时候反解老版本DS-AIR，做了一个node版的实现，地址为daikin-dsair。后来DS-AIR出了新版，于是决定使用更易接入HA的Python来编写组件。

开发HA组件主要参考了官方的开发文档，组件基于原生的climate组件开发platform，目前组件仍在开发中，地址为ha-dsair，后续开发完成后再补充组件的实现细节。