从 5 步到整套智能家居自动化:Home Assistant 本地中控零代码配置完整指南【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core晚上回家,你掏出手机:先开 A 应用关客厅灯,再切到 B 应用看门锁状态,最后用 C 应用把空调调高两度。三个 App 走下来,这件事本可以一句话解决。Home Assistant 就是为此而生的:一个开源、本地优先的智能家居自动化平台,它把家里所有智能设备收进同一个本地面板,控制逻辑跑在你自己的硬件上,断网时核心联动照常工作。本文覆盖:三种安装方式的取舍、最快启动与验证路径、设备接入的三类方式、按一天生活节奏组织的场景配置思路,以及稳定性与排障建议。Home Assistant 是什么:一个跑在自己设备上的本地中控先给判断,再给依据:适合谁:手里已有两个以上不同品牌智能设备、不想在多个 App 之间切换的人;对数据隐私敏感、希望记录留在本地的人。本地优先:自动化判断(如日落开灯)在本地执行,不依赖厂商云;断外网时,设备间联动依然可用。设备广度:核心仓库的 homeassistant/components/ 目录下内置了 1500 个集成,覆盖灯光、空调、门锁、传感器、摄像头、音箱等常见品类,主流生态基本都能直接接入,这是它区别于单一品牌中枢(只能管自家设备)的关键。交互方式:界面操作为主,自动化用可视化编辑器配置;只有少数高级用户需要手写 YAML,本文给出的片段均为最小可运行示例,可直接参照。它不是另一个品牌的中枢,而是一个跨品牌的中立层:设备数据先进入 Home Assistant,再由它统一驱动自动化。先选安装方式:镜像、Docker、源码三条路线怎么选项目为不同硬件和背景的用户提供了对应方案,选型依据只有一条:你的设备是什么、你想不想碰系统内部。方案适合人群优点代价官方树莓派/硬件镜像新手,有树莓派、Odroid 等单板写入 SD 卡即用,系统、升级、备份一体化需要一块专用硬件,受官方支持机型限制Docker 容器有 NAS 或闲置 Linux 电脑,有一点 IT 基础不占独立设备,隔离性好,便于备份需自行配置卷与网络,升级手动拉镜像源码安装开发者,要改代码或做集成开发完全可控,可打断点环境维护成本最高,不适合普通用户支持的硬件清单可以直接看 machine/ 目录,除各类 x86 平台外,包含树莓派 3/4/5、Odroid、Khadas VIM3 等。只有一台闲置 NAS 或迷你主机 → 选 Docker。愿意买一块树莓派、追求零维护 → 选官方镜像。想改源码 → 才考虑源码安装,克隆仓库:git clone https://gitcode.com/GitHub_Trending/co/core仓库根目录提供了 Dockerfile,生产与开发环境分别对应,可直接参考其构建逻辑。最快跑起来:最小启动路径,以及怎么算成功以 Docker 为例,最小部署只需要一条命令,把配置目录挂载出来、指定时区即可:docker run -d --name homeassistant --restartunless-stopped \ -e TZAsia/Shanghai \ -v /path/to/your/config:/config \ --networkhost ghcr.io/home-assistant/home-assistant:stable启动后,用浏览器访问http://主机IP:8123(默认端口定义在 homeassistant/const.py 的SERVER_PORT),完成三件事即算初始化成功:创建管理员账户——这是唯一必须立刻记下的凭据,丢了只能清库重来。填写家庭位置与时区——日出日落、地理围栏类自动化都依赖它,填错会导致日落开灯这类场景整体偏移。验证标准:进入设备与服务能看到至少一个被发现的设备(比如家里的路由器、打印机),说明网络发现链路是通的。此时你会看到一个按状态组织的主页:灯光开关、温湿度曲线、家庭成员位置各占一栏,而不是设备列表的堆砌。接入设备:自动发现、手动配置、需要中转,三类方式对号入座在配置 → 设备与服务 → 添加集成里搜索品牌名,是接入的统一入口。集成入口页会直接列出可自动发现的候选:按接入难度,设备大致分三类,对号入座能省大量排查时间:第一类:局域网自动发现,装完即用。飞利浦 Hue(按网桥按钮配对)、HomeKit 设备、部分 Sonos 音箱等。前提是设备与 Home Assistant 在同一网段;发现不到时,先确认不是被路由器划分到了访客网络或 VLAN。第二类:有账号或 IP,手动填写。小米米家、摄像头、天气数据源等多属此类。常见坑:厂商账号要求海外手机号或地区不匹配,需先确认账号体系可用;本地接入的设备,填 IP 比填域名更稳,能避开 DNS 解析波动;一个集成可能对应多种设备(如 Tuya 集成下挂了几十个白牌品牌),选错集成是能添加但功能残缺的主因。第三类:设备本身不支持,需要中转。典型两条路:WiFi 插座刷入 Tasmota 固件后走 MQTT 集成(仓库内置 homeassistant/components/tasmota、mqtt集成);或自购 ESP32 开发 ESPHome 固件接入。这条路门槛最高,但换来的是彻底脱离厂商云的本地控制,适合只接一两个顽固设备时再投入。摄像头类集成接入后,抓拍的实时画面会直接出现在面板卡片上:按一天的节奏配场景:清晨、白天、离家、夜间四个时段自动化不用想全再动手,建议按真实生活节奏一段一段加,每段只写一条最短规则。以下给出思路与最小片段,界面操作时按同样的字段填即可。清晨(07:00 左右):渐进唤醒。思路是触发时间 工作日条件 缓慢过渡,而不是简单开灯:- alias: 早晨唤醒 trigger: - time: 07:00:00 condition: - condition: time weekday: [mon, tue, wed, thu, fri] action: - service: light.turn_on target: { entity_id: light.bedroom } data: { brightness_pct: 100, transition: 600 }transition: 600表示 10 分钟内缓慢变亮,这是比闹钟温和的关键参数。白天(日落前 30 分钟):回家前补光。触发器选日落并给负偏移,比固定时间可靠得多,因为它随季节自动调整:- alias: 日落自动开灯 trigger: - sun: { event: sunset, offset: -00:30:00 } action: - service: light.turn_on target: { entity_id: light.living_room } data: { brightness_pct: 80 }离家:全员离场才执行,避免误关。触发条件是任意一个家庭成员变为not_home,但动作前加一道确认所有人都已离开的校验,这是新手最容易漏的防误触发逻辑:- alias: 离家模式 trigger: - state: { entity_id: person.family_member, to: not_home } condition: - condition: template value_template: - {{ states.person | selectattr(state, eq, home) | list | length 0 }} action: - service: light.turn_off target: { entity_id: all }夜间:安静优先。常用组合是门锁关闭 全部离家触发关灯、关电视,再加一条深夜门窗传感器报警 → 推送通知。夜间场景建议只保留必要设备,别把安防动作塞进同一条自动化里,出问题时难以定位。一个实用原则:每条自动化只解决一件事,触发、条件、动作各留一行余量,后续加场景是新增条目而不是改旧条目。稳定性与隐私:备份、记录范围、远程访问的取舍备份先于一切其他操作。内置设置 → 系统 → 备份可定期创建完整备份并下载到本地,恢复时上传文件即可。建议把改配置之前先手动备份一次变成习惯,因为 YAML 改错格式的代价是系统重启失败。记录范围要主动收窄。历史数据库默认保留 10 天,在树莓派这类小容量设备上,建议把保留期降到 7 天,并让 recorder 只记录关键实体(门窗、照明、温度),而不是全量设备。记录越少,存储压力和隐私面都越小。本地即隐私,但要补远程短板。数据留在本地是 Home Assistant 的核心价值;一旦需要外网访问,就不要再直接暴露 8123 端口,优先顺序是:官方远程服务(最省心,付费) VPN 回连(免费,需维护) 反向代理配 HTTPS(自由,配置成本最高)。无论哪种,远程访问都要配合多因素认证。升级节奏:跟随稳定渠道即可,大版本前先看发布说明中涉及你所用集成的变更;Docker 用户拉新镜像重启容器,镜像用户走系统内置升级。排障:设备连不上、系统变慢时的检查顺序新手问题 80% 集中在两处,按顺序查比重启大法高效:设备连不上,按此顺序排查:设备与 Home Assistant 是否同网段(访客网络、VLAN 是最常见断点);设备本身是否正常工作(用厂商 App 先确认一次);是否选对了集成(白牌设备尤其要看品牌归属,再对照集成说明);手动添加时核对 IP/端口/凭据,本地接入优先 IP 而非域名;以上都排除后,再考虑重启设备与 Home Assistant,并在日志里看对应集成的报错原文,而不是界面笼统提示。系统变慢,定位思路:先打开系统健康页面看资源占用,确认是 CPU、内存还是磁盘 IO 见顶;变慢往往与最近一次改动强相关:最近加了哪个集成、哪条自动化,优先怀疑它,可临时禁用观察;历史数据量是长期变慢的主因,按上一节收窄记录范围通常立竿见影。另有一个新手高频误区:把界面里没看到设备当成设备坏了。自动发现只覆盖支持广播协议的设备,大量设备(尤其串口、Zigbee 协调器、纯 TCP 设备)本来就需要手动添加,这不代表系统异常。下一步往哪走:扩展方向与入口当基础场景跑稳之后,自然的扩展顺序是:语音入口:接入语音助手集成,让灯光、开关响应语音指令;场景化分组:用 Group 与场景把散落的设备整理成客厅卧室这类语义单元,自动化的可读性会显著提升;能源视图:接入电表类设备后,仪表盘可展示家庭能耗分布,配合时间触发做错峰用电;社区扩展:通过 HACS 类渠道安装社区组件,补齐官方集成未覆盖的长尾设备;源码阅读:想理解某个集成的实现,直接读 homeassistant/components/ 下对应目录,每个集成自成一个包,结构统一,适合按图索骥。本文涉及的启动参数、集成清单、硬件支持均可在仓库内直接查证:入口在 Dockerfile 与 machine/ 目录,自动化与集成的完整实现以 homeassistant/components/ 为准。先让一条日落开灯跑起来,再按一天的节奏逐条补场景——这是把系统从装上了变成用起来了的最短路径。【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 从 5 步到整套智能家居自动化:Home Assistant 本地中控零代码配置完整指南
从 5 步到整套智能家居自动化:Home Assistant 本地中控零代码配置完整指南【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core晚上回家,你掏出手机:先开 A 应用关客厅灯,再切到 B 应用看门锁状态,最后用 C 应用把空调调高两度。三个 App 走下来,这件事本可以一句话解决。Home Assistant 就是为此而生的:一个开源、本地优先的智能家居自动化平台,它把家里所有智能设备收进同一个本地面板,控制逻辑跑在你自己的硬件上,断网时核心联动照常工作。本文覆盖:三种安装方式的取舍、最快启动与验证路径、设备接入的三类方式、按一天生活节奏组织的场景配置思路,以及稳定性与排障建议。Home Assistant 是什么:一个跑在自己设备上的本地中控先给判断,再给依据:适合谁:手里已有两个以上不同品牌智能设备、不想在多个 App 之间切换的人;对数据隐私敏感、希望记录留在本地的人。本地优先:自动化判断(如日落开灯)在本地执行,不依赖厂商云;断外网时,设备间联动依然可用。设备广度:核心仓库的 homeassistant/components/ 目录下内置了 1500 个集成,覆盖灯光、空调、门锁、传感器、摄像头、音箱等常见品类,主流生态基本都能直接接入,这是它区别于单一品牌中枢(只能管自家设备)的关键。交互方式:界面操作为主,自动化用可视化编辑器配置;只有少数高级用户需要手写 YAML,本文给出的片段均为最小可运行示例,可直接参照。它不是另一个品牌的中枢,而是一个跨品牌的中立层:设备数据先进入 Home Assistant,再由它统一驱动自动化。先选安装方式:镜像、Docker、源码三条路线怎么选项目为不同硬件和背景的用户提供了对应方案,选型依据只有一条:你的设备是什么、你想不想碰系统内部。方案适合人群优点代价官方树莓派/硬件镜像新手,有树莓派、Odroid 等单板写入 SD 卡即用,系统、升级、备份一体化需要一块专用硬件,受官方支持机型限制Docker 容器有 NAS 或闲置 Linux 电脑,有一点 IT 基础不占独立设备,隔离性好,便于备份需自行配置卷与网络,升级手动拉镜像源码安装开发者,要改代码或做集成开发完全可控,可打断点环境维护成本最高,不适合普通用户支持的硬件清单可以直接看 machine/ 目录,除各类 x86 平台外,包含树莓派 3/4/5、Odroid、Khadas VIM3 等。只有一台闲置 NAS 或迷你主机 → 选 Docker。愿意买一块树莓派、追求零维护 → 选官方镜像。想改源码 → 才考虑源码安装,克隆仓库:git clone https://gitcode.com/GitHub_Trending/co/core仓库根目录提供了 Dockerfile,生产与开发环境分别对应,可直接参考其构建逻辑。最快跑起来:最小启动路径,以及怎么算成功以 Docker 为例,最小部署只需要一条命令,把配置目录挂载出来、指定时区即可:docker run -d --name homeassistant --restartunless-stopped \ -e TZAsia/Shanghai \ -v /path/to/your/config:/config \ --networkhost ghcr.io/home-assistant/home-assistant:stable启动后,用浏览器访问http://主机IP:8123(默认端口定义在 homeassistant/const.py 的SERVER_PORT),完成三件事即算初始化成功:创建管理员账户——这是唯一必须立刻记下的凭据,丢了只能清库重来。填写家庭位置与时区——日出日落、地理围栏类自动化都依赖它,填错会导致日落开灯这类场景整体偏移。验证标准:进入设备与服务能看到至少一个被发现的设备(比如家里的路由器、打印机),说明网络发现链路是通的。此时你会看到一个按状态组织的主页:灯光开关、温湿度曲线、家庭成员位置各占一栏,而不是设备列表的堆砌。接入设备:自动发现、手动配置、需要中转,三类方式对号入座在配置 → 设备与服务 → 添加集成里搜索品牌名,是接入的统一入口。集成入口页会直接列出可自动发现的候选:按接入难度,设备大致分三类,对号入座能省大量排查时间:第一类:局域网自动发现,装完即用。飞利浦 Hue(按网桥按钮配对)、HomeKit 设备、部分 Sonos 音箱等。前提是设备与 Home Assistant 在同一网段;发现不到时,先确认不是被路由器划分到了访客网络或 VLAN。第二类:有账号或 IP,手动填写。小米米家、摄像头、天气数据源等多属此类。常见坑:厂商账号要求海外手机号或地区不匹配,需先确认账号体系可用;本地接入的设备,填 IP 比填域名更稳,能避开 DNS 解析波动;一个集成可能对应多种设备(如 Tuya 集成下挂了几十个白牌品牌),选错集成是能添加但功能残缺的主因。第三类:设备本身不支持,需要中转。典型两条路:WiFi 插座刷入 Tasmota 固件后走 MQTT 集成(仓库内置 homeassistant/components/tasmota、mqtt集成);或自购 ESP32 开发 ESPHome 固件接入。这条路门槛最高,但换来的是彻底脱离厂商云的本地控制,适合只接一两个顽固设备时再投入。摄像头类集成接入后,抓拍的实时画面会直接出现在面板卡片上:按一天的节奏配场景:清晨、白天、离家、夜间四个时段自动化不用想全再动手,建议按真实生活节奏一段一段加,每段只写一条最短规则。以下给出思路与最小片段,界面操作时按同样的字段填即可。清晨(07:00 左右):渐进唤醒。思路是触发时间 工作日条件 缓慢过渡,而不是简单开灯:- alias: 早晨唤醒 trigger: - time: 07:00:00 condition: - condition: time weekday: [mon, tue, wed, thu, fri] action: - service: light.turn_on target: { entity_id: light.bedroom } data: { brightness_pct: 100, transition: 600 }transition: 600表示 10 分钟内缓慢变亮,这是比闹钟温和的关键参数。白天(日落前 30 分钟):回家前补光。触发器选日落并给负偏移,比固定时间可靠得多,因为它随季节自动调整:- alias: 日落自动开灯 trigger: - sun: { event: sunset, offset: -00:30:00 } action: - service: light.turn_on target: { entity_id: light.living_room } data: { brightness_pct: 80 }离家:全员离场才执行,避免误关。触发条件是任意一个家庭成员变为not_home,但动作前加一道确认所有人都已离开的校验,这是新手最容易漏的防误触发逻辑:- alias: 离家模式 trigger: - state: { entity_id: person.family_member, to: not_home } condition: - condition: template value_template: - {{ states.person | selectattr(state, eq, home) | list | length 0 }} action: - service: light.turn_off target: { entity_id: all }夜间:安静优先。常用组合是门锁关闭 全部离家触发关灯、关电视,再加一条深夜门窗传感器报警 → 推送通知。夜间场景建议只保留必要设备,别把安防动作塞进同一条自动化里,出问题时难以定位。一个实用原则:每条自动化只解决一件事,触发、条件、动作各留一行余量,后续加场景是新增条目而不是改旧条目。稳定性与隐私:备份、记录范围、远程访问的取舍备份先于一切其他操作。内置设置 → 系统 → 备份可定期创建完整备份并下载到本地,恢复时上传文件即可。建议把改配置之前先手动备份一次变成习惯,因为 YAML 改错格式的代价是系统重启失败。记录范围要主动收窄。历史数据库默认保留 10 天,在树莓派这类小容量设备上,建议把保留期降到 7 天,并让 recorder 只记录关键实体(门窗、照明、温度),而不是全量设备。记录越少,存储压力和隐私面都越小。本地即隐私,但要补远程短板。数据留在本地是 Home Assistant 的核心价值;一旦需要外网访问,就不要再直接暴露 8123 端口,优先顺序是:官方远程服务(最省心,付费) VPN 回连(免费,需维护) 反向代理配 HTTPS(自由,配置成本最高)。无论哪种,远程访问都要配合多因素认证。升级节奏:跟随稳定渠道即可,大版本前先看发布说明中涉及你所用集成的变更;Docker 用户拉新镜像重启容器,镜像用户走系统内置升级。排障:设备连不上、系统变慢时的检查顺序新手问题 80% 集中在两处,按顺序查比重启大法高效:设备连不上,按此顺序排查:设备与 Home Assistant 是否同网段(访客网络、VLAN 是最常见断点);设备本身是否正常工作(用厂商 App 先确认一次);是否选对了集成(白牌设备尤其要看品牌归属,再对照集成说明);手动添加时核对 IP/端口/凭据,本地接入优先 IP 而非域名;以上都排除后,再考虑重启设备与 Home Assistant,并在日志里看对应集成的报错原文,而不是界面笼统提示。系统变慢,定位思路:先打开系统健康页面看资源占用,确认是 CPU、内存还是磁盘 IO 见顶;变慢往往与最近一次改动强相关:最近加了哪个集成、哪条自动化,优先怀疑它,可临时禁用观察;历史数据量是长期变慢的主因,按上一节收窄记录范围通常立竿见影。另有一个新手高频误区:把界面里没看到设备当成设备坏了。自动发现只覆盖支持广播协议的设备,大量设备(尤其串口、Zigbee 协调器、纯 TCP 设备)本来就需要手动添加,这不代表系统异常。下一步往哪走:扩展方向与入口当基础场景跑稳之后,自然的扩展顺序是:语音入口:接入语音助手集成,让灯光、开关响应语音指令;场景化分组:用 Group 与场景把散落的设备整理成客厅卧室这类语义单元,自动化的可读性会显著提升;能源视图:接入电表类设备后,仪表盘可展示家庭能耗分布,配合时间触发做错峰用电;社区扩展:通过 HACS 类渠道安装社区组件,补齐官方集成未覆盖的长尾设备;源码阅读:想理解某个集成的实现,直接读 homeassistant/components/ 下对应目录,每个集成自成一个包,结构统一,适合按图索骥。本文涉及的启动参数、集成清单、硬件支持均可在仓库内直接查证:入口在 Dockerfile 与 machine/ 目录,自动化与集成的完整实现以 homeassistant/components/ 为准。先让一条日落开灯跑起来,再按一天的节奏逐条补场景——这是把系统从装上了变成用起来了的最短路径。【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考