2024 年冬季的一场入室盗窃让许多居民开始重新审视家门口的安全防护。传统的敲门声已经无法满足现代家庭对即时信息的需求,因而很多人选择安装智能视频门铃。市场上入门级的 Blink 门铃因其价格亲民、功能基本受到青睐,然而在实际使用中却暴露出一个不容忽视的问题:门铃的声响只能在手机推送里出现,而家里尤其是客厅、卧室的成员往往无法及时听到。 Blink 门铃本身支持云端录像、云端存储以及通过 Amazon Alexa 进行语音控制。其核心工作原理是将按铃事件上传至 Blink 的云平台,随后触发对应的 Alexa Skills 或 IFTTT 小程序,进而发送推送通知到用户的手机。虽然这套流程在技术实现上非常成熟,但用户必须依赖手机或平板才能收到提醒,且每月订阅费用会对预算有限的用户形成额外负担。
更重要的是,若家中老人或孩子不常携带手机,门铃的'智能化'便形同虚设。 针对上述痛点,我制定了一套无需订阅、且不需要在路由器上开放端口的解决方案。核心目标是让门铃按下的瞬间,声音能够在已有的 Google Home Mini 上自动播放,从而让全家成员都能即时获知来访者。为此,我给自己设定了两个硬性约束:不支付任何月费,不把本地设备暴露在公网。这两条限制在很多现成的商业方案中几乎不可调和,但通过巧妙的云服务组合,却可以实现。 整套系统的核心是五条云服务的串联:Blink 门铃 → Alexa 自动化 → Samsung SmartThings 虚拟灯 → VPS 上的轻量 Web 服务 → Home Assistant 本地轮询。
每一步都充当一次信号的转发,最终把一个简单的二进制状态(灯开/关)映射为 Google Home Mini 的音频播放指令。虽然看起来像是一场'云端的鲁布·戈德堡机器',但它已经在实际环境中稳定运行超过一年半,为家庭带来了真正无缝的门铃提醒体验。 第一步是让 Blink 门铃与 Alexa 之间建立联动。Blink 官方提供了与 Alexa 的深度集成,只要在 Alexa App 中打开 Blink 技能并完成账号绑定,门铃的按铃事件即可被 Alexa 识别。随后,我在 Alexa 中编写了一条自动化 Routine,当检测到 Blink 门铃的'Ring'事件时,指令执行两项操作:其一,打开预先在 SmartThings 中创建的虚拟灯;其二,保持其他已有设备的原有状态不变。这样,门铃的每一次按动,都会在云端生成一次「灯开」信号。
第二步利用 Samsung SmartThings 作为状态桥接。SmartThings 支持创建虚拟设备(Virtual Switch),其本质是一个在云端保存的布尔值。通过上述 Alexa Routine,我将这个虚拟灯的状态切换为'开',随后 SmartThings 会把该状态变更通过配置的 Webhook 发送出去。Webhook 的目标地址指向了我自己租用的 VPS,只要灯的状态由'关'变为'开',SmartThings 就会立即 POST 一段包含设备 ID、时间戳等信息的 JSON 数据包到该地址。整个过程无需用户手动干预,也不需要在本地网络中打开任何端口。 第三步在 VPS 上搭建一个极其轻量的 HTTP 服务。
该服务使用 Node.js 或 Python 的 Flask 框架实现,仅监听来自 SmartThings 的 POST 请求。当收到灯开的 Webhook 时,服务会记录当前状态,并在响应中返回一个简短的确认。随后,为了防止灯的状态一直保持'开'导致后续触发重复,它会在 2 秒内自动发送一次'灯关'的指令回去给 SmartThings,完成一次完整的闭环。这样,VPS 扮演的角色相当于一个云端的中转站,既保存了状态,又负责快速复位。 第四步回到本地网络,使用 Home Assistant 作为本地的智能中枢。Home Assistant 通过自定义的 RESTful Sensor 定期轮询 VPS 提供的状态接口,查询当前灯的状态是'开'还是'关'。
当 Sensor 检测到状态从'关'转变为'开'时,触发一条自动化规则:该规则调用 media_player.play_media 服务,向客厅的 Google Home Mini 发送一段提前录制好的门铃提示音。播放完毕后,Home Assistant 再通过内部脚本将 VPS 上的状态手动改为'关',以防下次轮询误判。这样,即使云端的灯已经被 VPS 重置,Home Assistant 仍然能够在本地完成一次完整的音频播放。 从实际使用效果来看,这套五云协同的方案彻底解决了门铃声音被忽略的问题。无论是来访的快递员、邻居还是朋友,只要按下 Blink 门铃,Google Home Mini 都会在几秒钟内播放清晰的门铃提示音,声音覆盖整个客厅甚至卧室,完全不需要任何手机推送或手动操作。家人们第一次体验到'门铃响起,语音提醒随即而来'的便利,甚至觉得比传统的机械敲击声更为直观。
更重要的是,这套系统对网络延迟的容忍度很高,大多数情况下延迟不超过 2 秒,完全可以满足日常生活需求。 然而,依赖五条云服务也意味着系统整体的可用性会受到各方服务商的 SLA 影响。尤其是 Samsung 近期宣布将对个人用户收取 SmartThings API 的月费(约 4.99 美元),这对于仅使用一个布尔值存储的虚拟灯而言,显然是一种资源浪费。若继续使用,需要在预算中额外计入这笔费用;若寻找替代方案,则要考虑迁移到完全免费的平台或转向本地化实现。此外,VPS 的租金虽然一年只有十几美元,但若对可靠性要求更高,可能需要选择付费更高的托管服务,以保证 Webhook 的及时投递。 面对这些成本和依赖问题,社区中有不少 DIY 爱好者提供了更为轻量化的替代思路。
一种常见的做法是使用 MQTT 消息代理(如 Mosquitto)取代 SmartThings 的虚拟灯,所有设备(包括 Blink、Alexa、Home Assistant)在同一 MQTT 主题下订阅状态变更,从而省去对云端商业平台的依赖。另一种方案是直接通过 Home Assistant 的 Blink 集成或 Blink 的本地 API(如果可获取)读取按铃事件,绕过 Alexa 与 SmartThings,进一步减少云链路。还有人建议使用 Zigbee2MQTT,将门铃信号通过 Zigbee 协议直接传输到本地 Hub,实现真正的全本地化控制。除此之外,若对语音提醒的需求不高,亦可考虑使用低成本的蜂鸣器或 LED 灯条配合 Arduino,实现即插即用的本地提示。 综上所述,这套从 Blink 门铃到 Google Home Mini 的五云协同方案虽然看似繁琐,却在不使用任何订阅服务且不暴露本地端口的前提下,成功实现了门铃声音的家庭全覆盖。它展示了云服务之间灵活组合的潜力,也为喜欢 DIY、关注隐私和成本的用户提供了一个可参考的案例。
未来,随着更多开放 API 的出现和本地化技术的成熟,门铃系统的云链路有望进一步简化,理想的智能家居将不再依赖'五朵云',而是只靠一朵安全可靠的本地云即可完成所有感知与响应。 。
