v380pro设备连接失败_UniFi 智能家居设备之调优实践

我在家中⼤量使⽤智能家居系统后，时常被设备掉线或操作延时困扰。通过 UniFi Controller 可以看到无线网络的质量评估常常低于70%, 很多设备存在高延时、高重试、甚⾄ 获取网络地址失败 的情况出现，因此才会出现设备掉线或者操作延时，尤其是 Wi-Fi 连接的灯泡和米家 Aqara 网关，糟糕的连接质量会严重影响操作，出现一台吊灯的灯泡一个的亮起或者干脆六个灯泡亮了三个的情况，会让你觉得智能家居系统的投⼊非常的不值得。

造成原因

造成设备网络质量差的主要原因在于设备时常没有连接距离最近的 AP，我家是一个带有地下室的平层住宅，使⽤ 13 个 AP 完全覆盖，图为 2.4GHz 的覆盖情况。

左边为地⾯，右边为地下，为了方便管理将两层平⾯图放在⼀起

当 AP 进⾏固件升级或者配置更改的时候，对应的 AP 由于重启服务或者设备会断开现有所有设备的连接，并在一段时间内停止广播 SSID。此时连接到这个 AP 的设备就会寻求连接同一个 SSID 下的其他 AP，当 AP 重新上线时设备只要没有断线就不会重新连接回来。这就导致了设备会连接到较远的 AP 使得信号变差。一旦信号变差，除了影响设备本身的连接质量外，还会使得设备使用更大的功率进行⽆线通讯、重发送失败的数据包。当多个设备进入这个状态后，会导致周边电磁情况劣化，影响其他设备的通讯。

对应策略

我尝试在 UniFi Web UI 下手动断开重连设备，设备被 AP 踢下线后重连，有一定的机率会重新连接到正确的 AP，但是在图形界面操作有点麻烦，如果设备数量众多会使得这项⼯作量大到让人怀疑智能家居的意义。好在 UBNT 提供了⼀个用于命令行访问 Uni-Fi API 的 Shell 脚本，可以利用脚本自动化一些工作，让生活变得美好一些。

这个脚本可以在 UniFi Blog 的版本发布更新中找到，对应到每一个版本，本⽂编写时最新的 5.9.29 发布⽇日志地址：UniFi SDN Controller 5.9.29 Stable has been released - Ubiquiti Networks Community，文中有对应脚本的下载地址：https://dl.ubnt.com/unifi/5.9.29/unifi_sh_api

将脚本下载到本地后创建⼀个 unifi_sh_env 的⽂件，⽂件内容为：

username=ubnt #登录⽤用户名

password=ubnt #登录密码

baseurl=https://$server:8443 #访问 Controller 的 URL

site=default #站点名称，如果⼀个 Controller 中只有⼀个站点，那就是 default

之后行 source ./unifi_sh_api 就可以加载脚本中的命令，然后执行 unifi_login 完成登录就可以进行后续操作了。由于脚本返回的数据均为 JSON，因此还需要安装⼀个 jq 工具来处理 JSON，大部分 Linux 发行版都可以用内建的包管理器直接安装。

假设需要连接 MAC 地址为 80:2a:a8:86:19:9f AP 的设备名称中都有 Bedroom 关键词(可以在 Web 界⾯中给设备进行重命名)，那么执⾏下⾯的命令

unifi_list_sta | jq '.data[] | select(has("name")) | select(.name |

contains("Bedroom")) | select(.ap_mac != "80:2a:a8:86:19:9f") | "Name: (.name) MAC: (.mac) AP_MAC: (.ap_mac)"'

就可以列出所有没有按照预期连接在此 AP 上的所有设备和设备对应的 MAC 地址，之后执行下面的命令( 对应设备的 MAC 地址)

unifi_reconnect_sta

又遇到问题...

就可以强制这个设备重连，我天真的认为将这样的脚本完全自动化后放在 crontab ⾥定期执行就可以解决问题了，然后现实还是那么残酷。智能家居设备大部分采用 ESP8266 的解决案连接 Wi-Fi，由于固件内集成的 Wi-Fi 驱动非常基础，在多个 AP SSID 相同的⽆线网络中常会出现直接连接上一个 AP 的情况，也就是连接之前连接过的 AP 而非同一个 SSID 中信号最强的那个。当某个连接的 AP 升级固件或者重启后，一段时间内空间中没有此 AP 的信标，那么设备才会尝试去寻找同一个 SSID 中的其他 AP 连接，一旦连上之后原先的 AP 重启完成也不会再连回去。也就是说除⾮⽤户重启当前设备连接的 AP 来停⽌ BSSID 的广播，不然设备很难切换回信号最好的 AP。

这个情况使得设备在连接 AP 的策略上变得不可控，利用脚本踢掉设备后让设备重连的方案在多次尝试后发现效果并不理想，只有 Apple TV、安卓设备等操作系统相对完整的设备才能在一次断开后连回正确的 AP。大部分采用 ESP8266 方案的设备可能要经过数十次的重连才可能连接到正确的 AP，使得这个解决方案非常的低效。

新方案...

在绝望之际，我又想到了一个更原始的方法来解决这一问题，那就是给每个 AP 开设一个独⽴的 SSID，与现有 SSID 共存。位置相对固定不需要时常移动的设备就连接到这个 AP 各自独立的 SSID 下。这个⽅法虽然看起来很蠢，但也许非常有效，当然这一方法也会随之带来不少问题，到底值不值得，只有试⼀下才知道了。

我着手准备实践这个方案的时候就遇到了第一个问题：UniFi Controller 并不支持这样的设置，每个 AP 都只能给一个频段设置⼀个 Wi-Fi Group，每个 Group 共享配置，并不能对 AP 区别对待，好在 UniFi 论坛上已经有人找到了解决方法。

我的 2.4GHz 网络和 5.8GHz 网络使⽤了不同的 SSID，ESP8266 设备都是⽤2.4GHz 网络因此只需要在 2.4GHz 的网络中进行这样的配置。首先在 Controller 的设置界⾯中找到 Wireless Networks 项⽬，选择 2.4GHz 网络所在的 WLAN Group 进⾏编辑，点击下方的 Create New Wireless Network 创建一个新的⽹，这⾥可以选择⼀个临时的 SSID比如 Per-AP-SSID 之类，然后设置好对应的密码，其他配置建议采用默认配置。

⽹络创建完毕后配置会下发到每个 AP，之后到 AP 的管理界面中可以对这个 SSID 进行配置覆盖，在设备管理界面中逐一点开需要配置的 AP，在 Config ⾯板中展开 WLAN 配置，可以看到刚才配置的 Per-AP-SSID 已经出现在列表中，点击右边 Actions 列表中的按钮就可以覆盖配置。

我在这⾥选择使用和 AP 同名的 SSID 来便于区分，对每个 AP 都进行这样的配置后网络的调整就算做好了，这是你在家中搜索网络可以发现除了主 SSID 外还能发现多个 AP 独立的 SSID，场⾯⼀度十分混乱，这是这样配置带来的问题之一。问题之二就是之前配过⽹网络的设备需要重新配⽹，⼯作量可能很大，米家的设备可以利⽤ python-miio 工具包中的配网命令直接修改连接的网络，这里简单提及一下，安装配置 python-miio，按照⽂档获取设备的控制 token，然后执行下⾯的命令：

miio tokens update --token

miio configure --ssid --passwd

第⼀⾏命令配置设备的 Token，第二条命令改写设备的 Wi-Fi 配置，执行完成后可能提示执行失败，这是由于设备已经重新联网没有返回配置成功的数据，过一会⼉观察设备是否重新联网。

成功即可，有的时候可能设备需要断电后配置才会生效，同时米家 App 会收到⼀条推送，内容是设备网络配置更新成功，所以使用米家 App 控制的设备都可以采⽤这个⽅式重新配网。

完成配置后网络的性能提升明显，所有绑定 AP 的设备控制响应都得到了提升，截图中还有一个 AP 下的设备没有调整，重试率偏高，可以通过这些指标来判断还有那些设备需要调整，进一步优化网络，根据出现问题的 AP 查看该 AP 连接设备的列表，可以看到主卧的一个智能插座连接到了门外楼梯通道 AP。

通过下⾯的操作将其 ESSID 从统一的 SSID 改为 AP 独立的 SSID 后问题解决。

将统计时间改为1小时，可以看到修改国货网络质量也得到了持续好转。

总结

首先，我不认为这种解决方式是一个很好的解决方法，如果设备能对多 AP 的 SSID 支持得更好就不会存在这样的问题，但是在现阶段想要获得良好的智能家居体验，良好的 Wi-Fi 覆盖和正确的连接关系是前提。

本文描述的这个方式并不优雅，但问题得到了解决，体验获得了提升。当然从 Uni-Fi Controller 的角度也许可以更优雅的解决问题，比如通过控制 SSID Beacon 来实现某个设备绑定某个 AP 其实也是可能的，但是在大规模的网络中可能会引发更多的问题，也许只能期待 ESP8266 的网络驱动进一步优化，并且厂商后续能提供后续升级，才能彻底解决这一问题。