Home Assistant 折腾记：先别动主路由

8 月底，我又盯上了家里那台一直开着的 TR3000。

网络已经由它来管，家里也有空调等联网设备，电视和灯光的控制也在我的考虑范围里。如果顺手在路由器里装一个 Home Assistant，把家电都放到一个界面里，再接上小爱语音，看起来是一件挺顺理成章的事。少一台主机，少一份电源，也不用再找地方放设备。

带着这个想法，8 月 31 日我打开了 OpenWrt 后台。先看概况，再看软件包和正在运行的服务。查了一圈之后，我暂时放下了安装的念头。这一天没有改配置，也没有装 Docker 或 HA，但对下一步要做什么，倒是清楚了不少。

那些“看起来还空着”的资源

先说这台机器。Cudy TR3000 256MB 版里的“256MB”指的是闪存，它的运行内存是 512MB。后台实际显示的总内存约 485 MiB，扣掉系统占用后，当时看起来还有一些余量。

我把那次打开后台看到的几个数字记了下来：

这张表里，最先让我犹豫的是存储。剩下的一百多 MiB，不仅要装程序，还得容纳运行数据、日志，以及之后更新时的临时内容。把一个日常要保存设备状态的服务塞进去，空间很快就会变成需要反复操心的问题。

内存也不能只看空闲数字。TR3000 本身还要处理路由、DNS、DHCP、防火墙这些事情。后台有 OpenClash 和 Adblock 的菜单，不过那次检查没有发现 Clash 或 Mihomo 进程，我也没有测过代理和 HA 同时运行时的负载。

所以“当时还剩多少”只能算一张快照。它不能告诉我，家里正常上网、HA 加载集成、数据库写入或软件更新恰好撞在一起时，这个小盒子还会不会从容。

我没有真的安装 HA 来测极限，也不能据此断言它一定启动不了。只是到这里，我已经不太愿意拿主路由去试这个极限了。

接一块硬盘，会不会就够了？

我也考虑过外接 SSD。把容器和数据搬到外置盘，内部闪存紧张的问题确实能缓解，而且以后要留更多历史记录，也比挤在路由器的系统分区里宽裕。

但硬盘补不上内存。容器、HA、各个集成，仍然要和网络服务分享这不到 512MB 的 RAM。用 swap 可以把一部分内存压力转移到存储，却不会让机器突然多出同样速度的物理内存。

随后冒出来的是维护问题：外置盘没挂载成功怎么办？系统升级后容器环境要不要重新处理？HA 出问题时，如果最直接的排查动作是重启机器，家里的网络是不是也得跟着停？

这些问题单独看都有办法解决。只是把它们叠起来，为了省下一台主机，我反而得照顾更多相互牵连的事情。

我希望路由器是家里最不需要被记住的设备：开着，正常转发流量，大家照常用网。HA 则是一个我很可能不断加功能、改配置、尝试新集成的地方。它们的使用节奏本来就不太一样，分开放更符合我的习惯。

联上 Wi-Fi，还远没到“都能控制”

确认了硬件思路之后，我又梳理了一下现有和准备添置的设备，看看哪些值得接入。

那次在路由器里能看到美的、海尔设备的网络记录，但这还不足以回答我最关心的问题：能不能开关空调，能不能调温度，状态改了以后会不会同步回来？网络记录只能说明设备出现过，剩下的还得看具体型号、使用的 App 和它开放的能力。

查资料时，HA 的 Midea 集成文档就把支持范围分到了设备类型和协议版本，还提醒新设备可能采用不同 API。同样挂着美的标志，接入方式和可用功能也未必一样。海尔也得先弄清楚使用的是哪一套 App 和账号体系，不能只凭品牌去套教程。

准备购买的电视更直观。我原本只是笼统地想着“以后把 TCL 电视加进来”，仔细看才发现，完整型号和系统版本都很重要。能不能配对，待机后还能不能连上，音量、方向键和开机能不能正常用，可能是几件不同的事。

Android TV Remote 文档还专门提到，部分 TCL 设备关机后会不可用，需要检查电视上的 Screenless service 设置。对我来说，这比“支持 TCL”四个字有用得多：以后真接入时，不能只按两下遥控键就算完成，至少还得把待机和唤醒走一遍。

灯光则要先回到家里实际的开关和回路。几盏筒灯如果本来就在同一路上，换一个智能开关，通常也还是一起开、一起关。想分别控制，或者给灯带调亮度和颜色，需要的设备就不同了，不能指望装上 HA 后由软件自动把它们分开。

这让我把顺序往前挪了一步：先记清型号、App 和自己真正想做的动作，再决定买什么。涉及开关和线路的部分，也得交给电工确认，不能一边照着教程装软件，一边顺手猜家里的接线。

我想用小爱，但还要再走一步

我最初想象的使用方式其实很简单：平时不用打开几个不同的 App，对着小爱说一句话就行。

不过，设备能出现在 HA 里，并不代表小爱就能看见它。空调怎么接进 HA，是一个问题；小爱通过什么方式获得控制能力，又是另一个问题。前面顺利，不会自动带来后面的结果。

如果设备本身就支持米家或小爱，当然可以先看原生方案是否够用。对必须经过 HA 的设备，则要另外确认暴露方式和支持的动作。我不想把“HA 页面里有一个开关”，直接当成全屋语音已经有了着落。

Matter 也没有把这一步变成万能捷径。HA 的 Matter 文档说明，HA 在其中是控制器，并不会自动把已有实体全部变成可以向外分享的 Matter 设备。某些厂商网桥能做一部分转换，仍然得看网桥自己的范围。

到这里，最初那个“装一个软件，把所有东西串起来”的想法，已经变成了几件需要分别解决的小事。反而这样比较踏实：哪台空调能接，电视能做哪些动作，小爱能控制到哪里，都可以一件一件确认。

如果继续折腾，我会给 HA 单独找个位置

我的倾向是找一台有线连接的独立设备，把 HA 放进去。TR3000 继续管网络，HA 负责设备状态、自动化和控制界面。以后我折腾某个集成，至少不必先担心把家里的网络一起折腾掉。

硬件不一定要复杂。我给自己预留的方向是 64 位设备、至少 4GB 内存和 SSD。这是为了后续增加集成、保留记录和减少搬家的余量，不是 HA 官方的最低门槛。如果只是少量设备，也可以从更轻的配置开始。

安装方式上，我会优先看 Home Assistant OS。官方安装页把它列为大多数用户的推荐选择。对一台主要用来跑 HA 的机器，我更希望更新、备份和附加应用都沿着一条比较集中的路径走。

如果手头已经有一台维护得不错的 Linux 主机，Container 也有吸引力。只是宿主系统、容器更新、额外服务和 USB 设备映射，都要自己管理；它也没有 HA OS 提供的 apps。会用 Docker 和愿不愿意长期维护这套组合，是两回事。Linux 安装说明里这些细节需要一起看。

Matter、Thread 或无线网关也先不急着买。到底要不要它们，应该由现有设备和目标决定。尤其是 Matter，官方目前支持的是 HA OS 上的 Matter app；如果自己维护其他部署方式，就还要接下额外的支持和排障工作。

至于摄像头录像、视频识别这类更重的任务，我会另算需求。不能因为机器被叫作“家庭服务器”，就把所有想做的东西都当成没有成本的附赠功能。

先接好一台，再谈全屋

下一次真正动手，我想先挑一台最容易确认的设备。

如果是空调，就试温度、模式和状态回传；如果是电视，就试待机、唤醒和常用按键。设备断开一会儿再回来，HA 能否恢复，也比首页上多了几个漂亮图标更值得关心。这些目前还是后续计划，我没有把它们写成已经完成的结果。

等一台设备用顺了，再加第二台，再考虑它们之间的联动。语音同样往后放一点：先确认设备本身控制可靠，再试着把一句指令完整地送到目标上。这样出问题时，也更容易知道是设备、集成还是语音入口出了状况。

我也会给这台主机留一个恢复办法。备份能不能导出，重启后能不能回来，HA 停机时家里是否仍然能照常上网、照常用原来的开关，这些都需要在正式依赖它之前试一试。

8 月 31 日，那次操作最后停在了路由器的概况页。TR3000 继续做它原来的事，HA 还没有安装，家电也没有接进来。原本想省一台设备，查完之后，我更愿意把这两件事分开。

这次先记到这里。等真的给 HA 找好落脚的地方，再来写第一台设备是怎么接进去的，以及那些在文档里看起来顺利、到自己家里又会冒出来的问题。