我家里前后买过十几件智能家居设备灯、空调伴侣、门锁、摄像头、窗帘电机……光是找它们各自的App就能占满手机两屏而且这十几个设备分别来自四五个品牌互相之间谁也不搭理谁。后来我做了一个外人看来很“折腾”的决定把整个智能家居的中枢从各大云平台手里收回来放到自己家里那台绿联NAS上再配合vivo手机原生那套控制入口去指挥全屋。这篇就完整记录一下这套“绿联NASvivo”的思路、部署过程、踩过的坑以及出门在外时的远程访问方案。这套方案很适合三类人一是已经有绿联NAS、想把NAS用途榨干的用户二是智能家居设备买了不少、但受不了各种App割裂体验的人三是准备从零入手、想绕开云平台全家桶直接搭本地中枢的极客新手。整个方案跑通之后你会发现智能家居真正舒服的状态不是“App多炫”而是手机原生的语音、通知、桌面图标就能完成一切控制且所有核心指令不依赖厂商服务器。1. 为什么说全屋智能的底座应该放在自家NAS而不是云平台1.1 云平台控制的三个死穴先说说我为什么非要“把中枢拿回家里”。很多智能家居设备买回来默认走的是厂商云平台方案——设备发出的指令先上传到厂商服务器服务器再推给设备执行。听起来没什么问题但实际用起来有三个绕不开的痛点。第一个是断网清零。家里宽带一旦出故障光猫重启、运营商线路抖动云平台方案下的智能灯就连本地开关都按不了。说得夸张点这时候你的灯比拉绳的老式白炽灯还难伺候。我遇到过两次这样的情况大晚上宽带欠费停机结果客厅主灯死活关不掉只能去拉总闸非常狼狈。第二个是生态绑架。买了A品牌的开关就别想在B品牌的App里控制它。设备越多手机里App越多而且每个App都想要通知权限、定位权限、存储权限后台还得挂着保活。最后智能家居没让我智能先让手机变卡了。第三个是隐私和延迟。传感器数据、摄像头?如果是摄像头就尽量走本地但设备状态、人体传感器数据全都往厂商服务器传你没有任何选择权。延迟方面虽然一般不会高到不能忍但能明显感觉到“按了开关等半秒灯才亮”的松垮感本地中枢方案能做到几乎零延迟。所以我的判断是智能家居真正值得投入的不是买多少个“智能插座”而是架设一个属于自己、并且以本地控制为核心的统一中枢。1.2 绿联NAS当智能中枢的硬件底气光有想法还不够中枢需要一个可靠的载体。我自己用的是绿联的DXP系列机型这里就以绿联DXP4800/DXP4800 Plus为例说说为什么这台NAS适合扛起这个角色。先说性能。绿联DXP系列是x86平台处理器和内存对付Home Assistant、MQTT、Zigbee2MQTT这几个常用服务绰绰有余跑起来整机功耗也就是几十瓦的水平和一台小主机差不多。因为NAS本来就是设计成7x24小时开机的让它多承担一个智能中枢的角色几乎不增加额外电费和心理负担。再说接口和系统。绿联UGOS Pro自带了完整的Docker管理界面和Compose编排功能这意味着部署Home Assistant不需要在命令行里折腾半天然而是像装一个软件一样自然。有些NAS型号还带双2.5G网口哪怕很多设备同时上报状态带宽也完全不是瓶颈。再加上NAS本身就是干存储的HA的配置、历史数据、备份都能放在磁盘阵列里比放在树莓派的TF卡上让人放心得多。如果你手头还没有UPS我建议给NAS配一个。智能中枢最怕的不是性能不够而是突然断电后所有设备状态错乱——灯还显示“开”但实际已经灭了传感器重新配对后丢设备。有了UPS断电后NAS还能撑个十几分钟配合系统里的自动关机设置能把很多诡异问题挡在门外。1.3 放弃树莓派和软路由我为什么选了NAS在决定用NAS之前我也认真考虑过另外两条技术圈里常见的路线树莓派和软路由。树莓派的好处是便宜、功耗低装个Home Assistant系统也能跑但实际用下来有几个隐患一是SD卡容易损坏HA的数据库在SD卡上频繁读写用个一年半载就可能整卡报废二是性能上限低等设备数量上去了再挂几个摄像头画面流转树莓派就开始捉襟见肘。软路由方案更硬核但它的问题在于职责冲突。家里所有人的上网流量都要经过这台设备你要升级系统、改个插件意味着全家断网。把它既当网关又当智能中枢风险太大了一旦出问题排查起来也很让人头疼。NAS作为唯一同时具备“常开机”“性能够”“自带存储”“有UPS支持”这些条件的设备就成了最合适的平衡点。而且绿联UGOS Pro里的Docker管理、端口转发、DDNS设置都是图形化的对新手非常友好不需要懂Linux命令行也能把整套服务跑起来。2. 中枢落地绿联NAS跑起Home Assistant的完整过程2.1 为什么选Home Assistant而不是其他智能家居平台市面上的智能家居网关不少有厂商自带的也有第三方开源平台但Home Assistant我下面简称HA是目前综合来看最值得长期投入的一个。核心原因是它的设备兼容性覆盖面足够广官方支持列表里有几千款设备/品牌加上社区插件HACS的补偿几乎你能买到的正经智能设备都有接入方案。更重要的是HA的设计原则是“本地优先”——控制指令优先走局域网能不走云就不走云。这和我在第一章讲的痛点正好对上。它的自动化引擎也很自由你可以自己定义极其复杂的联动规则完全不用看厂商的脸色。2.2 在绿联UGOS Pro上通过Docker Compose部署HA在绿联NAS上部署HA非常简单。先打开NAS桌面上的Docker应用进入“项目”页面这里的Compose编排功能可以直接粘贴配置。我个人建议在NAS的共享目录里先建好docker/homeassistant/config这个文件夹用来存放HA的配置数据以后备份、迁移都方便。下面是一份可直接用的Compose配置以绿联DXP系列为例services: homeassistant: container_name: homeassistant image: ghcr.io/home-assistant/home-assistant:stable restart: unless-stopped network_mode: host privileged: true volumes: - /vol1/1000/docker/homeassistant/config:/config environment: - TZAsia/Shanghai其中/vol1/1000/docker/homeassistant/config这部分要根据你NAS里实际的路径来调整在绿联的文件管理器里能看到每个共享文件夹的绝对路径以系统显示为准。这里有几个关键点必须说明network_mode必须用host不能用bridge。HA需要向局域网广播设备发现协议比如mDNS、SSDP如果用桥接网络很多智能设备根本发现不了。host模式让HA直接复用NAS局域网IP后续手机访问、设备接入都少很多麻烦。privileged: true不是必须的如果只是接入WiFi设备可以不设置但这个选项可以避免后续USB Zigbee协调器等外设映射出幺蛾子。从省事角度我建议直接开着。如果你后面要插USB的Zigbee协调器记得在“设备映射”里把宿主机的/dev/ttyACM0或/dev/serial/by-id/xxx映射进容器否则Z2M认不到硬件。创建完成后浏览器访问NAS的局域网IP:8123首次打开会进入HA的欢迎页创建管理员账号即可。2.3 接入设备的现实路径HA装好之后真正消耗精力的是设备接入。不同品牌、不同协议的设备接入方式差异很大这里我按常见类型整理一下思路。米家/小米系设备在HA里通过“Xiaomi Home”官方集成登录米家账号后设备会自动同步。接入之后只要设备本身支持局域网协议控制指令就会优先走局域网这时就算家里的外网断了灯和开关依然能正常控制。涂鸦系设备市面上大量白牌智能插座、灯带都是涂鸦方案。接入需要去涂鸦IoT平台注册开发者账号、创建云项目然后把生成的Client ID和Secret填进HA的Tuya集成里。这个集成偶尔会掉授权需要重新扫码登录不算麻烦但要有心理预期。Zigbee设备如果是从零开始选型我会优先推荐Zigbee设备因为Zigbee协议本身就是为本地控制设计的不依赖任何云服务器。做法是在NAS上通过Compose多部署两个容器一个MQTT服务端Mosquitto一个Zigbee2MQTT再买一个USB协调器我自己用的SONOFF Zigbee 3.0 Dongle Plus就很稳。Z2M的配置里把MQTT地址写成mqtt://localhost:1883即可容器之间都走host网络互相通信不需要容器名解析。WiFi杂牌设备这类设备要看具体品牌是否被HA社区支持。有些支持本地MQTT协议有些只支持自己的App。如果你买的是完全没有社区支持的杂牌货又不想退货可以考虑刷第三方固件比如Tasmota、ESPHome。这部分属于进阶操作建议先从小品牌应用开始感受一下不要一上来就挑战硬骨头。2.4 设备命名规范提前做功课设备接入后HA里会出现一堆默认的名字比如“light.f3ab93”这种非常难认。我强烈建议在接入之后立刻统一重命名格式可以定为设备类型.房间_功能比如light.living_room_ceiling、sensor.bedroom_temp、cover.living_room_curtain。命名做好了后续写自动化或者喊语音指令才不容易出问题。提高命名效率的办法是直接从“设备”选项里逐个编辑实体虽然操作量不小但一次做完以后直接在自动化里写实体ID时都是顺手的。3. VIVO手机原生控制从Jovi语音到原子通知的落地玩法3.1 装上HA App先解决“原生感”HA部署好之后手机上要装的第一个App自然是官方客户端Home Assistant Companion。vivo手机的应用商店里不一定直接搜得到建议直接去官网下载Android安装包安装后用局域网IP登录自己的HA实例。装完之后有两件很重要的事需要立刻做。第一件是在vivo的“设置—电池—后台耗电管理”里把HA App设置为“允许后台高耗电”在“自启动”里也允许它自启动。vivo的省电策略对不常驻后台的App很激进不设置的话一会儿App就被系统休眠了通知推送全都会迟到。第二件是在HA App的设置里启用“全屏模式”和“隐藏状态栏”打开App之后整个界面铺满屏幕没有任何浏览器地址栏或者系统UI干扰观感上已经非常接近原生App了。3.2 一个图标直达全屋控制面板HA自带的前端叫Lovelace Dashboard可以在“概览”页面里自定义卡片布局。我建议先花半小时把常用设备都放在第一屏全部灯光、空调、窗帘、门锁状态、温湿度计按房间分卡片区。之后在vivo手机浏览器里打开HA的地址用“添加到主屏幕”生成一个桌面图标名称改成“全屋”或者“智能家居”。HA的前端是响应式设计的在手机浏览器里打开效果已经很接近App再加上前面提到的HA App其实也支持这种PWA式快捷方式。桌面放一个“全屋”图标点进去就是完整的控制面板比在一个个小程序里翻找设备好太多。3.3 Jovi语音自定义指令喊一嗓子触发场景vivo手机原生的语音助手Jovi在智能家居场景里最大的价值是可以自定义指令动作。做法不复杂核心是利用HA的Webhook能力——Jovi的本质动作是“打开某个网址”而HA收到这个网址请求之后执行对应的自动化。先在HA里创建一个Webhook触发器。我以“回家模式”为例在HA的自动化里新建自动化触发器类型选WebhookWebhook ID填home_coming动作就写打开客厅灯、空调设到26度、播放音乐这些自己想做的事。对应的YAML大概长这样- id: home_coming_by_voice alias: 语音回家模式 trigger: - platform: webhook webhook_id: home_coming action: - service: light.turn_on target: entity_id: light.living_room_ceiling - service: climate.set_temperature target: entity_id: climate.air_conditioner data: temperature: 26然后在vivo的Jovi语音助手里创建自定义指令触发词填“回家模式”动作类型选“打开网页”把上面的Webhook地址填进去。之后你喊一声“小V小V回家模式”系统就会自动请求这个地址HA收到后执行整套回家逻辑。这里有几个很关键的细节Webhook的URL格式是http://NAS局域网IP:8123/api/webhook/home_coming。如果是在家里喊这个地址直接可用如果人在外面需要把IP换成远程域名这部分第四章详细说。Webhook本身不需要登录认证所以Webhook ID就是这把锁的钥匙。不要把这个地址发到公开场合同时可以在Webhook URL后面带一个自定义token参数在HA自动化里做二次校验防患于未然。Jovi打开网页时浏览器会有短暂弹窗这是正常现象语音指令执行完之后锁屏即可不影响使用。实测在vivo的OriginOS上“我的指令”里能找到“打开网页”这个动作类型不同系统版本叫法略有差异但逻辑是一样的。3.4 原子通知设备消息出现在锁屏上vivo的原子通知是我认为“原生智能家居控制”最有价值的部分。它能把重要通知以卡片形式呈现在锁屏和状态栏上不需要解锁就能看到关键信息。配合HA App这套机制是这样用的在HA里写自动化当设备状态变化时调用notify.mobile_app_你的手机设备名服务推送消息。比如门锁打开了推一条“入户门已开锁时间14:32”温湿度计检测到卧室温度超过28度推一条“卧室温度偏高空调建议开启”扫地机完成清扫推一条“全屋清扫完成用时42分钟”。vivo手机会把这些推送以原子通知卡片形式显示在锁屏上。更有意思的是HA的Android推送支持“通知操作按钮”可以在推送里带两个自定义按钮比如门锁推送附带“查看监控”和“忽略”。锁屏状态下直接点按钮就能唤起HA App打开指定页面整个过程完全不需要进入某个第三方的App。后台推送稳定性的关键就是前面说的把HA App的电池策略改成不限制、允许自启动。这一步不做原子通知大概率会延时到手机点亮之后才能收到体验会大打折扣。3.5 进阶Matter桥接与系统级聚合入口如果你有精力折腾更“原生”的方案可以试试Matter桥接。HA官方有Matter Server插件可以把目前已经接入的几百个实体统一桥接成Matter设备。然后如果vivo系统的“智能家居”聚合入口支持Matter理论上扫码之后这些设备就直接出现在系统设置里了连HA App都不用打开。但我自己试用下来的体会是这条路方向对但实际体验还受限于系统版本对Matter的适配程度。一些没有经过Matter认证的桥接设备在系统里识别不完整、状态刷新不及时的情况时有发生。所以我把Matter桥接归类为“进阶尝试”主力方案还是HA App加语音加通知这套组合。HA作为一个中枢最强大的地方恰恰在于它把设备抽象成了统一实体层前端入口想换哪个就换哪个。4. 出门在外访问中枢三种远程访问方案与安全底线4.1 方案一官方远程访问零配置兜底绿联NAS自带远程访问功能用官方账户登录之后可以从手机端远程进入NAS的管理界面。对于只想在路由器外看一眼HA状态、临时触发某个自动化的人来说这个方案不需要任何网络知识登录绿联App就能用。但它的问题也很明显官方远程访问主要面向NAS自身的文件管理、系统设置对Docker容器的Web界面支持不一定覆盖到体验也比较受限。我更建议把它当作一个兜底方案真正要好用的远程控制还是得靠下面两个方案。4.2 方案二动态公网IP DDNS 端口映射这是我最推荐、长期用下来也最稳定的方案。先确认你家的宽带有没有公网IP用vivo手机开数据流量别连家里WiFi访问IP查询网站记下公网IP再登录路由器看WAN口IP如果两个IP一致说明你有公网IP。如果运营商给你的是大内网IP可以直接跳到下一个方案。有公网IP之后你需要做三件事注册一个域名。我用的腾讯云DNSPod花生壳也行看个人习惯每年几十块的域名钱完全值得花比自己记IP地址省心太多。在NAS里开DDNS。绿联UGOS Pro系统设置里有DDNS功能填上域名和服务商信息NAS会定期自动把动态变化的公网IP更新到DNS记录上。如果你手头的DDNS服务商不在系统列表里也可以部署一个DDNS-GO容器支持国内主流服务商。在路由器上做端口映射。把外部某个非标准端口比如8443映射到内网NAS的8123端口。注意只映射必要端口千万别把22端口敞开。做完这三步在外面用vivo手机访问https://你的域名:8443就能打开HA的登录页。为了观感更好可以在NAS上用Nginx做一层HTTPS转发把域名上的标准443端口转发到HA这样访问地址就变成了干净的https://你的域名不再需要记端口号。这套方案里有个非常实用的好处HA App里填远程地址后在家里和外网都能自动切换Jovi语音指令里的Webhook地址也可以直接换成远程域名这样你在外面喊“小V小V回家模式”同样有效进门那一刻灯已经亮了。4.3 方案三没有公网IP时的出路运营商死活不给公网IP的情况下还有一个成熟选择用frp这类内网穿透工具把NAS的HA端口映射到一台有公网IP的云服务器上。相当于让云服务器帮你守门流量从服务器中转回家里。这个方案需要额外买一台最便宜的云服务器但对只有手机控制需求的场景来说配置起来也很简单。frp的好处是即使运营商没有公网IP依然能获得一个稳定的远程访问入口配合域名使用效果和方案二差不多。缺点是多了一台云服务器的月租成本以及所有流量都经过这台服务器中转也就是多了几毫秒延迟实际使用几乎感觉不到。如果只是想偶尔在外面看一眼设备状态官方远程访问就够用如果需要高频控制frp域名才值得投入。4.4 远程控制必须守住的几条安全底线远程访问做好了安全防线也得跟着建起来。我总结了四条底线缺一条我都不建议把HA暴露到公网别让8123裸奔到公网。用Nginx做HTTPS转发之后至少密码是加密传输的。同时给HA开启二步验证手机App登录时用管理员以外的“用户”角色账号管理员账号只留给自己管理时用。Webhook ID就是钥匙。不要在任何平台上暴露你的Webhook地址最好在URL里附加一个自定义token参数在HA自动化里做校验。因为Webhook请求是不需要登录的一旦泄露别人就能远程触发你的回家模式。只放行必要端口。端口映射只开HA这一个入口就行其他端口一律关闭。可以再往深一层做只允许你的手机运营商IP段访问但这个对动态IP用户不友好根据自己的情况决定。备份必须自动化。HA配置目录要定期打包到NAS的其他共享文件里或者挂载到另一块硬盘上。顺便给历史数据库设置保留天数避免长期运行爆盘。5. 场景编排与避坑实录把“能控”变成“好用”5.1 三个值得复刻的自动化场景设备都接好、手机入口都通了之后下一步就是自己写自动化。我把自己用了很久的三个场景逻辑分享出来可以直接抄作业。场景一回家模式。触发方式是Jovi语音喊“回家模式”或者是智能门锁开锁触发的实体状态变化。动作方面我做了条件判断晚上6点之后客厅灯自动开到80%亮度阳台窗帘关闭空调制冷设为26度同时关闭安防警戒。如果白天回家只开窗帘不开灯避免浪费。这里用到的关键技巧是HA自动化里的condition可以给同一个Webhook触发加时间判断。场景二观影模式。这个我用的也是语音触发喊“看电影”之后客厅主灯关闭灯带调成暗橙色凯度色温调到2800K左右亮度30%投影仪打开并切换到HDMI输入窗帘缓缓关闭。HA里调用light.turn_on时带brightness和color_temp参数就能一次实现灯光氛围效果不用额外装场景面板。场景三起床模式。工作日早上7点自动执行卧室灯以1%亮度开始渐变开启大概5分钟内慢慢亮到60%模拟日出效果HA的light.turn_on里有一个transition参数用来控制渐变时长加湿器自动关闭窗帘打开15%透光同时给手机推一条原子通知内容是今天的天气和实时室温。这套逻辑跑起来之后我基本可以不用闹钟而是被灯光“唤醒”了。5.2 踩坑实录掉线、IP漂移、系统更新整个系统跑久之后真正影响体验的坑其实就那几类我一个个说。Zigbee设备掉线。现象是某个插座或传感器突然在面板里变灰、无法控制。排查思路按优先级来先在Zigbee2MQTT后台看这个设备的“Last seen”判断多久没上报心跳了如果是最近的强信号源干扰检查2.4GHz频段信道重叠问题我自己的经验是Zigbee信道默认可能落在WiFi拥挤的信道区域在Z2M配置里把channel改成25之后掉线率显著下降。另外路由设备比如常通电源的智能插座尽量多布几个电池供电的设备不要指望它们当中继。NAS重启后IP漂移。HA用的是host网络所以HA的地址就是NAS的地址。NAS IP一变手机App里的服务器地址就全废了。解决方式很简单在路由器里给NAS做DHCP地址保留让它永远拿同一个IP。顺手把Jovi语音指令里的Webhook地址也换成固定的远程域名从根源上绕开IP变化问题。系统更新踩坑。绿联NAS升级系统版本、或者Docker应用更新之后Compose项目有时会被系统重建。如果之前没把HA配置目录映射出来等于整个中枢一夜归零。所以每次更新前一定先确保config目录里的数据是完整的有条件的话做个快照。另外不要盲目点Docker里的“重新创建”按钮尤其跨大版本更新HA时先看release note再升级。MQTT断连。Zigbee2MQTT和Mosquitto这两个容器如果同时重启偶尔会出现Z2M先启动、连不上MQTT服务端的情况。解决办法是给两个容器都设置restart: unless-stoppedZ2M连不上时会自动重试等Mosquitto完全就绪后它自己就恢复了。这个坑出现一次之后基本不会再烦你。5.3 维护节奏每周五分钟好过天天盯配置完这套系统之后日常维护其实很轻。我自己的习惯是每周抽出五分钟看一眼HA的日志和“历史”页面重点看两个数据过去一周的设备掉线次数、自动化触发次数。掉线次数如果异常增多基本能提前发现某个传感器电池耗尽或者网络信号恶化不用等设备真正失效了才去临时抱佛脚。还有一件事值得说说。HA和HACS的更新非常频繁新版本偶尔会调整配置格式导致某个自动化在升级后失效。所以我从来不追新想升级的时候优先看HA的发布说明确定没有破坏性变更再操作。从我个人这段时间的使用体验来说绿联NAS加vivo手机这套组合最让人满意的地方反而不是某个炫酷功能而是稳定和可控。所有设备的状态、所有的自动化规则都实实在在跑在自己家里这台NAS上不需要为某个厂商服务器的波动买单。而vivo手机原生的语音助手、原子通知、桌面图标这些入口让全屋控制的频率大幅降低不需要再解锁手机找App也让我慢慢忘了智能家居原本还有“App割裂”这回事。如果看到这里你也想动手搭建我会建议你先从一台绿联NAS加一个USB Zigbee协调器加三五个灯泡开始先把中枢跑起来、把手机控制链路打通再逐步往里面接入更多设备。走通一次“语音喊回家模式、锁屏看到门锁通知”的完整链路之后剩下的扩展就只是时间问题了。