📌 项目地址：mbillow/localthings | ⭐ 1,063 颗星 | 🔧 Python
用 Home Assistant 的人如果家里有三星洗衣机、冰箱或空调，大概率都装了官方的 SmartThings 集成。这个集成必须登三星账号，所有指令和状态都要绕一圈云端。后果大家都体验过：状态刷新慢半拍，断网就抓瞎，家里几台家电的数据全在三星服务器上转了一圈。
LocalThings 把这条弯路拉直了：它直接在你家的局域网里和三星家电通信，不需要三星账号，配置完成后也不再联系三星服务器。
它快在哪、稳在哪
README 里写得很实在，几个关键点：
- 支持推送的家电会实时上报状态变化，其余的每 30 秒轮询一次
- 配置完成后完全离线可用，不再连三星服务器
- 不向三星发送任何数据。要注意一点：家电自己和三星云的连接还在，LocalThings 不去动它。想彻底断掉家电联网，得自己在路由器上处理
和云端集成比，这三条基本覆盖了所有痛点。断网时洗衣机的剩余时间照样能查，自动化照常触发，这一点对依赖家电状态的自动化场景来说是质变。
不是逆向，是人家本来就有的标准协议
这个项目技术上最有意思的地方：它没有 hack 三星家电，而是用了三星家电本身就实现的开放标准。
三星的联网家电是 OCF（Open Connectivity Foundation）设备。LocalThings 通过 /oic/res 发现家电暴露的资源列表，从 /oic/d 读出设备类型（比如洗衣机是 oic.d.washer）。当某个状态家电既提供标准 OCF 资源又提供三星私有扩展时，LocalThings 优先用标准那份。这比纯逆向方案靠谱得多，协议是公开规范，接口不会因为固件小更新就突然变样。
通信走 CoAP（RFC 7252），跑在加密的 DTLS 会话里，用 X.509 客户端证书做认证。状态推送靠 CoAP Observe 实现，这也是它能做到“实时上报”的原因。
支持的设备比你想象的多
覆盖范围相当广，列几个大头：空调（含多联机）、洗衣机、烘干机、洗烘一体机、冰箱（连泡菜冰箱和酒柜都有）、烤箱、灶具和油烟机、洗碗机、微波炉、扫地机器人（早期支持）、空气净化器、除湿机、净水器、EHS 热泵，甚至回音壁的设置和状态也能读。
能控制什么取决于家电自己上报的能力，典型功能包括：开关机、程序和模式选择、启动/暂停/停止、温度设定、剩余时间和预计结束时间、门锁和童锁状态、能耗、滤网状态和报警。
兼容性方面，2022 年之后的大部分三星家电都能用。一些更早的洗衣机、空调和嵌入式烤箱走的是旧的本机接口（TCP 8888），README 有单独一节讲怎么接。配置时会自动检测家电用的是哪种接口，检测不到会直接告诉你。
怎么配置
流程很简单：你需要提供家电的 IP 地址，LocalThings 会自动识别设备类型和型号，然后生成对应的控件和传感器。
所以第一个实际建议是给家电固定 IP，在路由器上做 DHCP 静态分配就行，不然家电换个地址集成就断了。
第二个建议：遇到识别不了的情况别急着放弃。如果某台家电配置成功但没被认出来，或者缺某个控制项，Home Assistant 会弹提示请你下载诊断数据。维护者通常凭这一份诊断文件就能补上支持，README 的 “Reporting a capability gap” 一节写了怎么提交。
和官方集成放一起看
| 维度 | SmartThings 云集成 | LocalThings |
|---|---|---|
| 三星账号 | 需要 | 不需要 |
| 状态更新 | 依赖云端 | 本地推送 / 30 秒轮询 |
| 断网后 | 不可用 | 可用 |
| 协议 | 云 API | OCF / CoAP over DTLS |
唯一的要求是家电得在你的局域网里、有个固定 IP，外加大致是 2022 年后的机型。用 Python 写的 Home Assistant 自定义集成，许可证和安装细节以仓库页面为准。
如果你的三星家电符合条件，这个项目值得一试。它可能是把 SmartThings 云集成从你系统里移除的最后一块拼图。