前言
当年装修选购中央空调的时候，JS号称是可以用APP远程控制的，于是就入了个坑。在安装的时候发现这个设备非常的坑，这个空调网关有两种连接方式，一种是直接通过家里的内网直连，不需要任何鉴权(安全性堪忧，只能祈求家里的内网不被入侵了)，一种是需要注册账号密码绑定到远程服务器，可以通过APP远程操控设备。
然而代理商的师傅安装现场调试的时候发现，如果不注册可以通过内网来控制。如果注册了远程账号，则内网、远程都挂掉了，还没有任何解绑的方法....
后来代理商师傅请来了大金官方的师傅，大金师傅说这设备要想解绑只能回厂冲刷。结果，愉快地注册死多个设备之后，大金师傅说不要注册了，不要远程控制了，就内网将就这用吧....据说这网关兼容性很差，有很多华为路由器用户连内网都是用不了....
这个神级的控制系统叫做DS-AIR。最近APP更新了一个版本，似乎解决掉了上述问题。不过，为了实现智能家居的统一控制，集成全硬件的自动化，为了少安装一个APP，还是决定将空调接入到HA中。在网上关注了很久，HA官方有集成大金的组件，但似乎不支持我家的这个设备，于是决定自己开发个组件，折腾的历程就这么开始了....
这个APP的网络连接基于TCP，传输协议是二进制的，单纯抓包无法解析报文结构，于是决定尝试反编译apk，通过代码解析辅助抓包来分析。
折腾过程
反编译apk
反编译一般使用ApkTool、dex2jar和JD-GUI三个工具。
ApkTool用来提取apk中的资源文件，由于我只是需要解析代码，不需要资源文件，所以没有用这个工具，直接unzip解压apk提取代码文件了。dex2jar用来将apk的dex文件还原成class文件打成jar包。JD-GUI则将jar反编译为java文件。
反解出来的代码目录结构如下，整体的反解质量还不错。
不过某些文件的代码比较奇怪，有语法错误，还有大量重复的语句，像是做了混淆。还有一些文件的部分代码没能成功反解出来，以注释代替了。另外变量名不能够还原，代码分析起来比较痛苦，不过可以借助IDE很方便的rename变量名。
报文分析
消息报文格式如下所示：
Bit | 0 | 1 2 | 3 4 | 5 | 6 | 7 8 9 10 | 11 | 12 13 14 15 | 16 | 17 18 | ... | last |
Hex | 02 | 10 00 | 0d 00 | 01 | 00 | 01 00 00 00 | 00 | 00 00 00 00 | 00 | 01 00 | ... | 03 |
Dec | 2 | 16 | 13 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | ... | 3 |
Desc | start | length | res | subbody | res | increased | device | device | need | cmd | subbody | end |
| | | | version | | ID | type | ID | ack | ID | content | |
报文格式为小端序，起止符号分别为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格式为：
02 00 00 03
早些时候反解老版本DS-AIR，做了一个node版的实现，地址为daikin-dsair。后来DS-AIR出了新版，于是决定使用更易接入HA的Python来编写组件。
HA Component开发
开发HA组件主要参考了官方的开发文档，组件基于原生的climate组件开发platform，目前组件仍在开发中，地址为ha-dsair，后续开发完成后再补充组件的实现细节。