做密室逃脱的人大概都幻想过这么一件事：如果把整个房间变成一套能随时读状态、随时触发、随时重置的逻辑系统，现场把控就会轻松很多。标题里那句“Turn every escape room puzzle into a Home Assistant device”，我最早看到时愣了一下，后来越想越觉得准确——Home Assistant（以下简称HA）不该只被理解成“智能家居平台”，它更像一个通用的状态机容器。而密室谜题本质上就是“输入、判断、输出”的状态流转。把每一个谜题变成HA里的实体，等于把整个房间的机关逻辑搬到一个可以查询、可以调试、可以重复上演的系统里。
这篇东西想聊的不是怎么装HA，也不是怎么接一个传感器，而是怎么把“谜题”抽象成设备模型：从命名规划到自动化规则，从顺序类谜题到多谜题依赖，再到调试和防误触。如果你正在做密室场景搭建、解谜装置改造，或者单纯想把家里的门锁、盒子、机关改成一套可以编程的“实体物”，这篇可以当一份项目思路参考。
1. 先把“解谜”翻译成设备：建立一套通用的实体模型
1.1 谜题的本质是状态流转，HA天生就是状态机
密室里的谜题五花八门，但拆到最底层，无非是三个部分：玩家做了什么操作，系统如何判断这个操作，操作成功后给了什么反馈。按密码锁是“输入正确数字串→放行”，踩压力板是“检测到踩压→触发机关”，拼图形状是“比对吻合度→开门”。这些逻辑放到HA里，操作就是实体状态的变化，判断就是模板或者自动化条件，反馈就是调用服务。
HA真正的优势不在“能接多少智能设备”，而在它把一切都收敛成了统一的状态模型。传感器是状态，开关是状态，连你自定义的一个逻辑变量也是状态。对于做谜题的人来说，这意味着你不需要写一套独立的解谜程序，也不需要用单片机固件去硬编码每一关的逻辑。你只需要定义几个实体，写几条自动化，再加一个前端页面，谜题就活了。
我在实际搭建里很喜欢用一句话概括：密室谜题 = 实体 + 状态条件 + 动作服务。睡觉前想一遍这个公式，第二天基本不会卡壳。
1.2 把谜题抽象成五类HA实体，游戏场景就能硬接进来
不同类型的谜题元素，落到HA里对应不同类型的实体。别一开始就想着写复杂Python脚本，先把元素分类：
| 谜题元素 | 对应实体 | 典型用途 |
|---|---|---|
| 按钮、开关、压力板 | binary_sensor / input_boolean | 检测玩家“按下”“踩住”“拨到”某个状态 |
| 密码输入、字母盘 | input_text / input_select | 收集玩家输入的字符或选项 |
| 进度阶段、已解锁关卡 | input_boolean / input_number | 表示当前解谜推进到哪一步 |
| 倒计时、限时环节 | timer / time-based automation | 超时重置、紧急强制解锁 |
| 最终输出（锁、门、灯） | switch / lock / button | 控制电磁锁、继电器、声光反馈 |
实体模型一旦定下来，物理设备只是这些实体的“执行外壳”。比如压力板可以是一块真实的压感地垫，也可以是一个你放在桌上测试用的门磁传感器，甚至可以是网页上点的虚拟按钮。谜题逻辑完全不依赖物理外壳，这就是把谜题“设备化”之后最大的自由。
命名也要认真一点。我见过有人把实体一律叫binary_sensor.aaa1、binary_sensor.aaa2，一旦谜题超过五个，维护的人直接崩溃。建议用“房间号_谜题序号_物理元素”的结构，比如：
binary_sensor.room01_puzzle01_pressure_a binary_sensor.room01_puzzle01_pressure_b input_boolean.room01_puzzle01_stage_a switch.room01_puzzle01_exit_lock后面所有自动化、仪表盘、日志检索都从这套命名里受益。
2. 直接用HA实现一个“按顺序踩踏板”谜题
2.1 题目设定：三块踏板必须按A→B→C顺序触发
先拿一个最常见的顺序类谜题开刀。场景是这样的：玩家面前有三块压力板，线索提示里给出了正确顺序A、B、C。玩家必须按顺序踩，中途踩错就全部重置，三块全部按正确顺序触发后，旁边的门解锁。
物理端我会准备三块二值传感器压力板，分别接入HA，每个压力板变成binary_sensor.pad_a、binary_sensor.pad_b、binary_sensor.pad_c。门的解锁用继电器控制电磁锁，对应实体switch.exit_lock。逻辑端需要三个辅助实体：
input_boolean.stage_a input_boolean.stage_b input_boolean.stage_cstage_a表示“玩家已经正确完成了第一步”，stage_b表示“已经正确完成了前两步”，stage_c表示“三步全部完成”。
2.2 用自动化实现顺序判断，而不是写死一段代码
新建四个自动化就够了。第一个：检测A被踩，并且当前还没有进入任何阶段，就把stage_a置为开。第二个和第三个处理“错误触发”：比如玩家还没踩A就踩了B，或者还没踩A、B就踩了C，这时调用重置脚本，把所有input_boolean恢复为关。第四个：检测C被踩，同时stage_a和stage_b都已经为开，认为顺序正确，就让电磁锁通电。
核心代码逻辑可以写成这样：
automation: - id: "puzzle01_press_a_first" alias: "P01 正确踩下A，激活第一阶段" trigger: - platform: state entity_id: binary_sensor.pad_a to: "on" condition: - condition: state entity_id: input_boolean.stage_a state: "off" action: - service: input_boolean.turn_on entity_id: input_boolean.stage_a - id: "puzzle01_error_b_before_a" alias: "P01 错误：A之前踩B，全部重置" trigger: - platform: state entity_id: binary_sensor.pad_b to: "on" condition: - condition: state entity_id: input_boolean.stage_a state: "off" action: - service: script.puzzle01_reset_all - id: "puzzle01_error_c_before_ab" alias: "P01 错误：A/B之前踩C，全部重置" trigger: - platform: state entity_id: binary_sensor.pad_c to: "on" condition: - condition: state entity_id: input_boolean.stage_b state: "off" action: - service: script.puzzle01_reset_all - id: "puzzle01_unlock_exit" alias: "P01 正确完成ABC，解锁出口" trigger: - platform: state entity_id: binary_sensor.pad_c to: "on" condition: - condition: state entity_id: input_boolean.stage_a state: "on" - condition: state entity_id: input_boolean.stage_b state: "on" action: - service: switch.turn_on entity_id: switch.exit_lock细看会发现一个很微妙的地方：第二个自动化处理“还没踩A就踩B”的错误，第三个处理“A/B还没完成就踩C”的错误。但C的错误判断条件是stage_b 为 off，也就是说只要没完成前两步，踩C都算错。这个条件把“踩了A没踩B时直接踩C”和“一上来就踩C”两种情况都覆盖了，不需要额外再写分支。这是自动化条件合并很好用的一个小技巧。
重置脚本script.puzzle01_reset_all的内容看起来是这样：
script: puzzle01_reset_all: alias: "P01 全部重置" sequence: - service: input_boolean.turn_off entity_id: - input_boolean.stage_a - input_boolean.stage_b - input_boolean.stage_c - service: switch.turn_off entity_id: switch.exit_lock2.3 为什么不用更复杂的编程方式去实现
有人会问：用 Esphome 写个单片机逻辑不也行吗？甚至用一个很短的 Python 脚本在校验服务器上也能做出来。但区别在维护层。HA里每个实体都是可视化状态，哪天运营人员问我“现在玩家解到哪一步了”，我直接打开仪表盘就能看到stage_a是开还是关。如果是写死在固件里，运营人员只能干瞪眼。
自动化还支持mode: restart、mode: single这类执行模式配置。压力板这类物理输入，玩家可能快速连续踩、抖脚、误触，如果是脚本轮询模式，容易出现自动化触发被排队执行的情况。我在触发器的自动化上一般加：
mode: single保证同一时间只处理一次触发，后续重复触发会直接忽略。这一步在公测阶段被验证为非常关键：不加mode: single，玩家踩错时重置脚本可能会执行两三轮，导致状态看起来像“自动跳关”。
3. 多谜题串联：把整间牢房包装成一棵依赖树
3.1 谜题之间的“门槛”不该写在人脑里，要写成实体关系
密室很少只有一个谜题。通常玩家要先解A谜题拿到一个关键线索，再靠线索打开B谜题，B解完才解锁C谜题的输入。如果所有逻辑都靠现场操作员盯监控手动开门，那压根不需要做电子化。
多谜题串联的实现思路，和前面那个单谜题完全相同：每个谜题的“完成状态”是一个实体，下一个谜题的可操作状态也是一个实体。前一个没完成，后一个的自动化条件永远不满足，自然不会被触发。
比如谜题二是“输入四位密码”，玩家只有在谜题一完成后才能看到密码提示。这时可以把谜题一的完成状态写成一个模板二进制传感器:
binary_sensor: - platform: template sensors: room01_puzzle01_done: value_template: "{{ is_state('input_boolean.stage_c', 'on') }}"然后在谜题二的密码校验自动化里加条件：“只有room01_puzzle01_done为开时才继续校验密码”。否则即使玩家误打误撞把正确密码提前输进去，门也不会开。这就是“依赖树”在HA里的落法。
3.2 限时、超时自动重置与“防暴力破解”设计
玩家卡关在密室运营里很常见，但更常见的是玩家乱试：暴力试密码、乱踩压力板、所有按钮全部点一遍。这些行为对真人NPC来说是灾难，对HA来说只是几条条件而已。
我的做法是给每个核心谜题配一个重置计时器。比如玩家在错误状态停留超过30秒，系统自动重置该谜题。实现起来非常直接：重置脚本里启动一个timer，时间到后再跑一遍重置。同时为了避免玩家通过反复触发传感器让自动化队列拥堵，所有重置自动化都启用mode: restart，计时器一重置就把之前的恢复动作作废。
防暴力破解的思路则不同：不是不让人试错，而是让试错成本变高。密码输入谜题我喜欢用滑动次数限制，比如input_number记录尝试次数，超过上限就锁定密码面板五分钟。这个锁定期通过一个自动化实现：
- id: "puzzle02_brute_force_lock" alias: "P02 密码输错超过3次，锁定5分钟" trigger: - platform: state entity_id: input_number.puzzle02_attempts to: "3" condition: - condition: state entity_id: binary_sensor.puzzle02_locked state: "off" action: - service: binary_sensor.turn_on entity_id: binary_sensor.puzzle02_locked - service: timer.start entity_id: timer.puzzle02_lockout data: duration: "00:05:00"锁定期的判断逻辑放在密码校验自动化的最前面，一旦puzzle02_locked为开，校验动作直接终止。
3.3 整场清场后的一键重置：把“关店”也做成一个设备
运营人员每天要重复做的一件事是：确认房间没人，把所有机关恢复到初始状态。这个动作也应该是一个HA实体。我会创建一个button.system_reset_all，点一下就把全房间所有input_boolean清零、所有电磁锁断电、所有计时器停掉。按钮不靠记忆，靠脚本。
更进一步，如果场地有固定的营业时段，还可以用time触发器在每天固定时间自动重置。我建议不要完全依赖自动重置，保留一个手动按钮，因为密室经常有包场、延误、临时进房间调试的情况，自动重置会把现场调试人员正在看的中间状态给清掉。
4. 把仪表盘变成“密室监控终端”：不止是好看
4.1 玩家视角跟运营视角必须分两个页面
把谜题变成HA设备之后，最容易犯的错误就是把所有实体一股脑塞进同一个仪表盘。玩家那边如果能看到input_boolean.room01_puzzle02_locked这种状态，谜题等于直接泄底了。
我的习惯是拆成两个试图视图：
第一套是“玩家反馈屏”，放在房间里的平板或者电视上。只显示当前谜题的进度提示、剩余时间、已解锁的线索，不显示任何具体状态实体。比如谜题一时，平板只显示“三重机关已激活”这类经过文案包装后的文字，数据源用的是模板传感器翻译过的状态，而不是裸实体。
第二套是“运营监控屏”，放在控制室。这个页面要能看到全部谜题的完成状态、当前卡在哪一步、哪个传感器最后被触发、电磁锁通断情况。调试时还能打开日志面板，直接回放玩家前五分钟的操作轨迹。
前端卡片我自己常用entities卡片加icon和tap_action。比如运营监控页里每个谜题标题做成导航按钮，点一下跳到对应谜题的分组视图。用auto_fill插件按实体命名空间自动分组，几十个实体也能管得过来。
4.2 历史回放能力比实时状态更值钱
真实运营场景里，最常发生的问题是：玩家说“我明明按了那个按钮，门没反应”，运营人员需要在现场扯皮很久。HA自带history和logbook功能，状态变化和自动化触发记录都留了痕迹。
所以每次谜题自动化触发时，我建议都带上有意义的alias。不要叫自动化001，而是叫P03 正确输入顺序后激活电磁锁。这样在日志里一眼就能看出当时的判断逻辑走没走通。实测里这个习惯帮过大忙：有一次门锁没弹开，查日志发现自动化被正确触发，但switch.exit_lock状态已经为开了，问题出在继电器触点老化，和逻辑无关。没有日志的话，我大概率会先去改自动化，白折腾一小时。
4.3 让状态可见：把关键谜题结果映射成大字号卡片
玩家的反馈屏上为了制造沉浸感，不建议显示“A完成、B完成、C完成”这样干巴巴的条目。我会用一个markdown卡片，嵌入模板变量做文案渲染。比如谜题一完成后显示“石台深处传来齿轮转动的声响”，两个谜题都完成后显示“锁扣弹开的声音从门后传来”。
这种展示方式完全依赖HA的模板系统，不写死文字，而是根据实体状态实时切换。从运营角度说，任何一场游戏里，玩家当前看到的反馈都跟实际机关状态严格同步，不会出现“文案说打开，门却没开”的脱节。
5. 调试与常见坑：这些坑我基本都踩过一遍
5.1 传感器抖动：实体状态像“闪动”一样反复翻转
密室压力板、按钮这类机械触点，在按下和松开的瞬间会产生抖动，如果HA用ESPHome或直连GPIO读取，状态可能在几十毫秒内连续变化好几次。自动化一旦被触发两次，电磁锁就可能出现“啪地一下吸合又释放”的诡异现象。
解决办法有两个方向。一个是硬件层面加RC滤波或者用带消抖的输入模块，另一个是在HA层面对自动化加mode: single和触发器延迟：
trigger: - platform: state entity_id: binary_sensor.pad_a to: "on" for: milliseconds: 200for: 200ms的意思是：状态变成开并持续200毫秒后才触发后续动作，短暂抖动会被直接过滤掉。这个值我测试下来很稳，既能过滤物理抖动，又不会让玩家的快速操作变得迟钝。
5.2 自动化触发顺序的“幽灵执行”：为什么门自己开了
比较隐蔽的一个坑是：两个自动化同时对一个实体进行操作，导致状态竞争。比如重置脚本在关闭stage_a的同时，另一个自动化检测到stage_a从开变为关，以为“谜题结束”，又跑去触发了一次解锁。
解决这类问题的核心思路是条件前置。任何解锁自动化都要明确加上“是否已完成前置阶段”的条件，而不是只依赖单次状态变化。宁可多写两个条件，也不要让逻辑猜你的意图。我自己的规则就是：所有执行“最终结果”的自动化，必须同时满足两个以上前置状态。
5.3 设备掉线跟逻辑掉线是两回事
HA把实体和设备做了抽象，但物理链路始终存在不可靠因素。电磁锁这类系统建议走本地直连的控制方式，避免经过云平台中转。WiFi传感器掉线可以容忍，最终那一下开门动作不能容忍。我一般用ESPHome的本地自动化兜底：电磁锁由HA正常控制，但如果感知到HA失联超过一定时间，ESPHome本地会强制把锁复位成关闭状态，避免玩家卡死在房间里。
电源分配也要注意，同一个继电器模组带多个锁时，启动瞬间电流可能很大，影响传感器供电。我在现场吃过一次亏：门锁吸合瞬间，压力板读数异常跳变，自动化误判踩板。后来把传感器供电和继电器供电分开走，问题立刻消失。
5.4 用HA开发者工具做“干跑测试”，不碰物理装置
每次改完自动化，不要直接跑去房间踩板测试。先在开发者工具里手动改变实体状态，看自动化是否按预期触发。比如把binary_sensor.pad_a手动切换为开，观察stage_a是否被点亮，再把pad_b手动切换为开，观察是否触发重置。
这种做法可以在一分钟之内验证完整逻辑链，而不用一路小跑去踩三次板。我在项目后期几乎把开发者工具当成主力调试器用，效率高很多。也建议每写一条自动化都建好对应测试步骤清单，改版后照着清单走一遍，能挡住大部分回归问题。
5.5 防误操作：线上状态和重置脚本要能分开
最后提醒一个管理细节：控制室的运营屏，不要直接摆重置按钮和强制解锁按钮。我见过运营人员倒茶时手肘碰到屏幕上的强制开门，整场流程直接崩掉。给危险操作增加确认确认弹窗，或者用conditional卡片把它隐藏到“管理页”并配一个访问密码页保护。这不是技术问题，是现场管理问题，但顺手就能在HA里实现。
写在最后
把每个密室谜题变成HA里的一个设备，做着做着会发现，真正顺手的不是那几条自动化，而是“用状态管理规则”这种思维方式的转变。以前想改一个谜题顺序，要去现场拆线、改固件、重新烧录。现在只需要改一个实体状态或者一条自动化条件，整个逻辑链就跟着变了。
我最喜欢的一个配角功能是全局的状态面板：运营开场前扫一眼所有input_boolean是否都是默认状态，比逐个人工检查机关快得多。这套东西扩展性也强，后续不管是加计时谜题、加语音提示、加多点触控联动，都是在现有实体模型上加节点，不大需要推倒重来。
如果你手里正好有套闲着的HA环境，建议先把类似“三踏板顺序谜题”的最小模型搭出来跑一遍。不需要高级硬件，随便用三个开关模模拟压力板就能验证全部思路。验证通了，再往实体设备上迁移，一定会顺手很多。
