整理手机照片，发现几张木工1.0的照片，留存一下，主打一个简陋。

www.zuojiaju.com现状

我最近打算做一台cnc，准备系统的学一下cnc知识。想到早年在www.zuojiaju.com收藏了几个cnc相关的帖子。

当我准备打开网站的时候发现简直是个噩梦，

• 域名（www.zuojiaju.com）不能访问了；
• 搜索一下，原来换成www.diy.cc这个域名，打开一看网站换成了收费的问答系统，再点进去一看，全是Discuz的mysql报错信息；
• 又找了一圈，论坛到了mgm1.diy.cc这个子域名下，终于看到点影子了，可是所有内容都不能查看，我可是交了钱的会员啊；
• 换手机APP吧，APP说是到期了不能使用了，8月的时候说开始恢复，至今是12月，还是无法使用

app功能正在修复 老李 2023-8-11，app现在也在搞备案制，这下就更难了。

目前我找到唯一能访问的方法是移动端的web，勉强能用，但页面打开速度奇慢，基本上在45秒左右。我以为是我网络问题，17ce看了一下，全国都是4-10秒。

看来是彻底躺平了

老李不易

目前这个网络环境，做论坛的确很难。据说之前被注销过域名备案，搞收费制又被人举报个人网站涉嫌经营。李先生能坚持这么多年，确实是不容易。

但是：
难归难啊，既然还在做，就说明能做啊；既然能做，就应该把他做好啊；
如果不能再做了，可以把他交给有能力的人继续做下去啊。网站虽然是个人做的，但是数据可是大家的啊。何必这样搞的半死不活的呢。

论坛的新帖，新回复的数量都很少，帖子的click很少。
等数据抓完了，可以做一个按周期分析的统计数据图表。看看到底是从什么时候开始出了问题的。

收费的错？

据说这一切的错都是从收费开始的。
又说，收费是为了防止内容被监管读取而被处罚，用app就不会被监管识别。看来他们是不了解云厂商的内容防火墙机制啊。

我觉得网站收费没有问题，用收费负担成本，提供更好的体验，这是良性循环。我是第一时间就交钱成了收费会员。

但如果出发点是想通过论坛收费来赚钱，我觉得就大错特错了。论坛收费制，除了成论人坛，其他寥寥无几。想赚钱，别的变现方式有很多啊。为什么要走这个死胡同呢。

成本多少

我简单看了一下帖子数量大概不到100万，自增id数目前是99.9万，回复数量估计不到1千万，用户数20多万，PV很少。这个体量Discuz用一台2c4g足够了。

附件(主要是图片)的存储量相对会大一些的，出口走的是两个CDN，一个是金山，另一个是不知名厂商，有点乱。
这个体量服务器成本+CDN流量，一个月几百元是足够的。这哪里需要搞什么收费啊。

管理员天天说搞APP要很多钱。Discuz的APP是可以不花钱的，有很多公版的app方案。
比如Discuz hub，一键打包的discuzAPP有很多，开源的Discuz app也很多。

为什么要费事费力抓取木工网

我感觉木工网基本上是个躺平状态，撑一天算一天的事了。他的消失也就是个时间问题了。像是个确诊了癌症的病人。
这些数据还是挺有价值的，所以我想我能做的就是把这些文字抓紧镜像下来。

• 一来我自己方便查阅，
• 二来方便别人查阅，
• 三来纯粹的就是觉得数据丢了可惜，

我们的木工手艺都快失传了，难道我们还不能保留我们的文字嘛！！！ 天涯不是就消失了嘛！

页面打开时间3-8秒，非CDN下的静态内容速度很快，同服务器的www.cncdiy.cn也很快，这就是典型的mysql在拖。经验告诉我们，这样的论坛说崩就崩。所以缓存数据刻不容缓。

关于版权

网站的协议页（https://mgm1.diy.cc/misc.php?mod=faq&action=faq&id=1&messageid=43）
适用版权第3条第A款，A、在用于非商业、非盈利、非广告性目的时需注明作者及文章出处“中国木工爱好者”。

第五章 版权
1、本论坛文章仅代表作者本人观点，与本论坛立场无关。作者文责自负。
2、在本论坛原创发表的文章，其著作权归作者所有，其版权归作者及本论坛共同拥有，未经作者许可，任何人不得擅自用于商业目的。中国木工爱好者有权将在论坛发表的文章用于论坛其他用途。
3、作者无专门声明或者转载时无附带声明的文章其版权申明以下列原则为准：
A、在用于非商业、非盈利、非广告性目的时需注明作者及文章出处“中国木工爱好者”。
B、在用于商业、盈利、广告性目的时需征得文章原作者同意，注明作者姓名、授权范围及文章出处“中国木工爱好者”，并按国家有关法律规定向作者和论坛支付稿费和版权费。

如果原作者不想文章显示在这里，之后我会做一个ban功能，原作者简单提交验证后就可以ban掉自己发布的所有内容。

关于蜘蛛

我的蜘蛛的名字叫MugongSpider(木工蜘蛛)。作为一个蜘蛛程序，首先就是要尊重网站的robots（https://mgm1.diy.cc/robots.txt）
我抓取的都是可以直接浏览到的内容（移动端页面），这些帖子，评论等内容，并不在网站Disallow范围内。

#
# robots.txt for Discuz! X3
#

User-agent: *
Disallow: /api/
Disallow: /data/
Disallow: /source/
Disallow: /install/
Disallow: /template/
Disallow: /config/
Disallow: /uc_client/
Disallow: /uc_server/
Disallow: /static/
Disallow: /admin.php
Disallow: /search.php
Disallow: /member.php
Disallow: /api.php
Disallow: /misc.php
Disallow: /connect.php
Disallow: /forum.php?mod=redirect*
Disallow: /forum.php?mod=post*
Disallow: /home.php?mod=spacecp*
Disallow: /userapp.php?mod=app&*
Disallow: /*?mod=misc*
Disallow: /*?mod=attachment*
Disallow: /*mobile=yes*

方案

通过蜘蛛抓取移动端页面上的所有帖子&评论内容，生成archive页面。
帖子和评论这个很容易搞定，不容易搞的是图片，图片可以先跨站调用。但是如果论坛倒闭了，就无法浏览了。
最稳妥的办法是将图片也全部缓存下来，这个工作量就比较大了。先搞定文字内容，图片回头再搞说吧。

抓取中

单线程抓取，比想象的快一些，一分钟抓20条，平均一条3秒，大概35天可以抓完。

帖子数据

大概抓了7天，帖子数据全部抓取完毕，
自增id最后数为999668，共抓取到有效帖子709847，无效帖子289821，发帖用户数153720。
人均发帖：4.6个。

评论数据

大概抓了4天，评论数据全部抓取完毕，
自增id最后数为11079746，共抓取到有效回复11079746，只回复未发帖用户83717。
人均回复：46.5个。

用户数据

总用户数237437（发过帖子+发过回复）

数据统计

thread
有效帖子数量 709847

发布过主题用户数量 153720
人均发帖 4.6个

comment
有效评论数量 11079746

只发布过主题用户数量 83717
人均回复 46.5个

user
用户数量 237437 （发过帖子+发过回复）

清理
清理掉签到板帖子8.5万，回复220万

简单的按月统计发帖量柱状图（出掉签到板块的统计数据）：

从统计数据来看，
2006~2013 高速发展期
2013~2018 巅峰期
2018~2020 衰退期
2020~2023 躺平...

2023年下半年每个月只有200多贴，12月到了100多贴，按照这个趋势，2024年月发帖量会跌破100。
2025年关闭？😒😒😒

统计cvs数据:

2006, 1, 4 
2006, 2, 53 
2006, 3, 74 
2006, 4, 182 
2006, 5, 145 
2006, 6, 102 
2006, 7, 68 
2006, 8, 109 
2006, 9, 199 
2006, 10, 268 
2006, 11, 242 
2006, 12, 379 
2007, 1, 348 
2007, 2, 263 
2007, 3, 422 
2007, 4, 412 
2007, 5, 576 
2007, 6, 430 
2007, 7, 369 
2007, 8, 510 
2007, 9, 554 
2007, 10, 437 
2007, 11, 503 
2007, 12, 525 
2008, 1, 794 
2008, 2, 579 
2008, 3, 851 
2008, 4, 912 
2008, 5, 766 
2008, 6, 768 
2008, 7, 778 
2008, 8, 699 
2008, 9, 846 
2008, 10, 997 
2008, 11, 1138 
2008, 12, 1413 
2009, 1, 1275 
2009, 2, 1420 
2009, 3, 1495 
2009, 4, 1351 
2009, 5, 1262 
2009, 6, 1170 
2009, 7, 1000 
2009, 8, 1043 
2009, 9, 1052 
2009, 10, 1016 
2009, 11, 1228 
2009, 12, 1279 
2010, 1, 1150 
2010, 2, 787 
2010, 3, 1431 
2010, 4, 1509 
2010, 5, 1414 
2010, 6, 1267 
2010, 7, 1056 
2010, 8, 1158 
2010, 9, 1223 
2010, 10, 1209 
2010, 11, 1907 
2010, 12, 2256 
2011, 1, 1652 
2011, 2, 1537 
2011, 3, 2102 
2011, 4, 2282 
2011, 5, 2667 
2011, 6, 1932 
2011, 7, 1900 
2011, 8, 2162 
2011, 9, 2510 
2011, 10, 2764 
2011, 11, 2911 
2011, 12, 3257 
2012, 1, 2422 
2012, 2, 3325 
2012, 3, 3913 
2012, 4, 3760 
2012, 5, 3788 
2012, 6, 3201 
2012, 7, 3162 
2012, 8, 3203 
2012, 9, 3056 
2012, 10, 3420 
2012, 11, 3716 
2012, 12, 5458 
2013, 1, 3498 
2013, 2, 2440 
2013, 3, 3748 
2013, 4, 4088 
2013, 5, 4046 
2013, 6, 3843 
2013, 7, 2691 
2013, 8, 3351 
2013, 9, 3666 
2013, 10, 4499 
2013, 11, 5750 
2013, 12, 6548 
2014, 1, 5523 
2014, 2, 4415 
2014, 3, 6662 
2014, 4, 7386 
2014, 5, 7442 
2014, 6, 7104 
2014, 7, 7439 
2014, 8, 7447 
2014, 9, 7726 
2014, 10, 8384 
2014, 11, 8477 
2014, 12, 8336 
2015, 1, 7256 
2015, 2, 3376 
2015, 3, 5731 
2015, 4, 5953 
2015, 5, 5839 
2015, 6, 5640 
2015, 7, 5195 
2015, 8, 4736 
2015, 9, 4443 
2015, 10, 4733 
2015, 11, 5458 
2015, 12, 6209 
2016, 1, 5555 
2016, 2, 3407 
2016, 3, 6384 
2016, 4, 6299 
2016, 5, 6135 
2016, 6, 5354 
2016, 7, 4821 
2016, 8, 4582 
2016, 9, 4705 
2016, 10, 5274 
2016, 11, 5311 
2016, 12, 6626 
2017, 1, 5857 
2017, 2, 6559 
2017, 3, 10155 
2017, 4, 7803 
2017, 5, 7384 
2017, 6, 7430 
2017, 7, 6834 
2017, 8, 6598 
2017, 9, 6802 
2017, 10, 6682 
2017, 11, 6285 
2017, 12, 5975 
2018, 1, 4809 
2018, 2, 3202 
2018, 3, 4814 
2018, 4, 4557 
2018, 5, 4391 
2018, 6, 4007 
2018, 7, 3701 
2018, 8, 3604 
2018, 9, 3381 
2018, 10, 3364 
2018, 11, 3466 
2018, 12, 3736 
2019, 1, 3723 
2019, 2, 2916 
2019, 3, 4792 
2019, 4, 4882 
2019, 5, 4329 
2019, 6, 3994 
2019, 7, 3711 
2019, 8, 3377 
2019, 9, 3298 
2019, 10, 3468 
2019, 11, 3279 
2019, 12, 3140 
2020, 1, 2207 
2020, 2, 2715 
2020, 3, 3338 
2020, 4, 3363 
2020, 5, 3191 
2020, 6, 2589 
2020, 7, 2387 
2020, 8, 2069 
2020, 9, 1776 
2020, 10, 2113 
2020, 11, 4049 
2020, 12, 5019 
2021, 1, 2201 
2021, 2, 1841 
2021, 3, 2450 
2021, 4, 2161 
2021, 5, 1891 
2021, 6, 1687 
2021, 7, 1483 
2021, 8, 1303 
2021, 9, 1097 
2021, 10, 1002 
2021, 11, 1080 
2021, 12, 997 
2022, 1, 1173 
2022, 2, 844 
2022, 3, 760 
2022, 4, 767 
2022, 5, 817 
2022, 6, 719 
2022, 7, 530 
2022, 8, 462 
2022, 9, 513 
2022, 10, 505 
2022, 11, 595 
2022, 12, 462 
2023, 1, 399 
2023, 2, 424 
2023, 3, 419 
2023, 4, 393 
2023, 5, 345 
2023, 6, 241 
2023, 7, 226 
2023, 8, 277 
2023, 9, 267 
2023, 10, 211 
2023, 11, 184 
2023, 12, 150 

米家的智障设备

米家的智能设备只能定时、条件触发这两个最简单的操作，说白了就是一个定时自动开关，复杂一些的场景就无能为力了。
单靠米家这点功能，想要智能门都没有，只有自己控制设备，实现智能化。

按照这个思路开始折腾

方案1，ZigBee

我有一个最老款的米家ZigBee一代网关，以前写过ZigBee控制协议，Server端可以接收到网关下所有子设备的通讯数据（组播收），Client端可以模拟子设备发送数据，模拟心跳、 模拟传感器、模拟无线开关都没有问题，做联动触发也都正常（单播发），

ZigBee虽然能控制的设备有限，只要能控制网关下子设备的触发，再结合米家的场景，组合起来应该也将就够用了，跑了一下程序，发现Server可以运行，Client端无法运行了，只可以接收数据，不能发送数据了，搜索一下发现是一代网关插件升级之后不允许局域网通讯了，插件还无法降版，这条路断了，

PS：即使这条路没断这也不是一个好的方案，
1，一代网关太老了，缺乏新的支持，产品已经停产，新的网关更不支持局域网接入，
2，小米自家也在慢慢的淘汰ZigBee换用蓝牙

方案2，Home Assistant

自己写程序控制设备，Home Assistant应该是天选的，HA有原生的REST API，很灵活很方便，简单易用、坚固稳定。
其实HA应该是第一选择，但HA装系统、配置、导入设备，都比较麻烦，实在有点太折腾了。

ZigBee的路不通，没办法只能走HA这条路了，虚拟机装好HA，MIIot装好，设备绑定好，API调试好，问题又来了，HA对米家的设备支持不全，触发设备全都不能控制，支持的设备还有很多功能缺失，比如，浴霸只能开关灯，通风，排风，暖风这些功能全都缺失了，触发设备不支持，控制触发设备结合米家场景的方法也都行不通了，

两条大腿都断了，准备放弃这个事了。不死心，又盘了盘，Github看了看，发现有抓包模拟协议控制设备的，协议控制一般是我的首选，很久之前我就尝试过抓包，发现双向都是加密的，看了看也就放弃了，当时也没有硬需求，之后也就没多做研究，现在已经没有其他办法了，不死心，硬着头皮上，再抓包试试...

方案3，协议控制

协议控制的好处是可以一次性解决所有的问题，指令直接发送到小米云端和设备无关和系统无关，丢数据到api.io.mi.com，由小米云端下发设备控制，高效稳定，梳理协议是最复杂难度最高的，无法解密的概率是很高的，当然解密了收益是最大的，有两个关键问题，

1，RC4密匙的算法
sha256(ssecurity + _nonce)

2，请求签名加密方法
反正也不知道sign的具体格式到底是啥 各种调 各种尝试 结果如下：
uri . key _nonce . data

提交数据有两种方式
1，加密方式，RC4加密，以后可能都要RC4加密
2，明文，目前可用，可能是在兼容老设备？

构建请求JSON
构建请求JSON必须解密RC4，按照原数据结构再构建请求数据，数据结果详细说明可以通过https://home.miot-spec.com/查询，读两遍别人的代码，把代码删减一下，Python跑通，用更简单的PHP重新写一遍，方便网页控制10几行代码DEMO测试通过... 前前后后折腾了一个礼拜，备忘，

参考：
https://www.xiaoweigod.com/network/2235.html
https://kero.ink/posts/mihome-app-api.html
https://github.com/PiotrMachowski/Xiaomi-cloud-tokens-extractor/blob/master/token_extractor.py

发现问题：
稳定运行1个多月之后发现抓包获取到的授权过期了，原来这个授权是会过期的，生命周期并不很长！总不至于每个月抓一次吧授权吧。

解决方法：
跑脚本，模拟一遍登录流程，抓取登录后的cookie，保存到本地，定期获取一下，周期暂时先放到1个月试试。

更新

今天我更新了一下Xiaomi Miot Auto发现多了一个可选项，

禁用米家APP通知消息实体 这个虚拟传感器以前就有 但我没有使用过
禁用米家场景历史实体 这个是新增加的 正好两个一起研究一下

v0.7.14 的更新，add scene history sensor (#1361)
https://github.com/al-one/hass-xiaomi-miot/releases/tag/v0.7.14

打印一下传感器信息：

sensor.mi_345123456_message

Array (
    [entity_id] => sensor.mi_345123456_message
    [state] => 摄像机: 用户345123456于23:42在带屏音箱上观看摄像机 储藏室直播视频.
    [attributes] => Array
        (
            [entity_class] => MihomeMessageSensor
            [filter_homes] => Array
                (
                )

            [exclude_types] => Array
                (
                    [0] => 13
                )

            [msg_id] => 17344867324567850112
            [is_new] => 1
            [type] => 6
            [title] => 用户345123456于23:42在带屏音箱上观看摄像机直播视频.
            [content] => 摄像机
            [user_id] => 345123456
            [ctime] => 1703173364
            [timestamp] => 2023-12-21T15:42:44+00:00
            [model] => isa.camera.hlc6
            [device_id] => 345123456
            [home_name] => 大楼
            [room_name] => 一楼
            [event] => stream
            [event_data] => 
            [prev_message] => 小米智能摄像机: 用户345123456于23:09在带屏音箱上观看小米智能摄像机直播视频.
            [icon] => mdi:message
            [friendly_name] => Xiaomi 345123456 message
        )

    [last_changed] => 2023-12-21 23:42:56
    [last_updated] => 2023-12-21 23:42:56
    [context] => Array
        (
            [id] => 01HJ6ASDFARTEGWT083FPEH
            [parent_id] => 
            [user_id] => 
        )
)

sensor.mi_666666666_66660166660575_scene_history

Array (
    [entity_id] => sensor.mi_345123456_884885886887_scene_history
    [state] => 旅行
    [attributes] => Array
        (
            [entity_class] => MihomeSceneHistorySensor
            [from] => user
            [name] => 旅行
            [ts] => 1703173662
            [timestamp] => 2023-12-21T15:47:42+00:00
            [scene_id] => 1731231401335251234
            [targets] => Array
                (
                    [0] => Array
                        (
                            [at] => phone
                            [error] => 0
                            [note] => 
                            [origCode] => 0
                            [origErr] => 
                            [t] => 1
                        )

                )

            [prev_value] => 有人移动-米家智能充电台灯开灯并设置灯光
            [prev_scene_id] => 1721231066712417412
            [icon] => mdi:message
            [friendly_name] => Xiaomi 345123456_884885886887 Scene History
        )

    [last_changed] => 2023-12-21 23:47:57
    [last_updated] => 2023-12-21 23:47:57
    [context] => Array
        (
            [id] => 01HJ6XXXXXXXXXXJQKQM2DFM5Q
            [parent_id] => 
            [user_id] => 
        )
)

作用

一个是记录米家的通知消息，一个是记录米家的场景消息，通过这两个虚拟传感器，就可以捕捉到米家智能化都做了些什么。但home assistant是通过轮询来工作的，所以消息不是实时的。

但是不管怎么说，这都为米家 & home assistant 通讯提供了另一条途径。

问题

• 这两个传感器都只保留最后两条消息，（当然可以通过读取日志获取更多的历史消息)
• 读取的消息不是实时的，轮训的周期应该是30秒，当然可以自定义
• 每次读取最后一条消息，如果瞬间触发了5个场景事件，生成5条消息，那么除了最后一条，其余4条就都被MISS了，

使用

未完....

Home Assistant

Home Assistant是一个IoT设备的集中管理平台，他可以解决各家产品相互不兼容的问题。

我用的最多的设备是米家，其次是易微联，还有少量的其他品牌的产品，另外还有一些自己DIY的设备，比如WLED，ESP8266的继电器等等。

这些品牌都互不兼容，或者蹩脚兼容。好在这些品牌几乎都能被Home Assistant所支持，或者说大家都符合相关IoT标准。

丢弃米家接口

我一直都是通过对https://api.io.mi.com/app接口进行抓包，而后将数据rc4加解密，直接对米家APP的接口进行读写操作。这套流程很麻烦，涉及到抓包，签名，授权，数据加解密等各个环节。

[抓包米家app文章] 米家"智能"设备折腾 模拟米家协议

麻烦是麻烦些，因为是直接操作的米家APP接口，好处是相当稳定。随着手机抓包的越来越难，加之有个别新的设备抓包数据莫名其妙的无法解密，比如最新的人体传感器2S，所以我决定弃用解密米家APP的方案。

即使数据可以解密，这个方法也不是长久之计，说不定哪天一更新就不能用了，所以我决定扔掉用了几年的米家接口。

请勿索要米家APP接口协议，因为这涉及加解密，其实GITHUB上有，我就是参考的别人的代码，也可已参考上文完整的思路已经给出了

Home Assistant REST API

REST API是Home Assistant另外一个非常大的特点，别的品牌也有开放接口给开发者的，但是这些接口更多的是给产品、给厂商，并不是给普通用户的。

Home Assistant的API是面向用户的，你只需要会一点点基础编程就可以使用，最少也就3-4行代码就可以解决问题了。

比如，要把灯打开：

// php
$token = "xxxxxxxxxx"; // token
$id = "xxxxxxxxxx"; // 设备id
$url = "http://192.168.1.15:8123/api/services/light/turn_on"; // hass 服务器地址
$opts = ["http" => ["method" => "POST", "content" => json_encode(['entity_id' => $id], 320), "header" => "Authorization: Bearer {$token}"]];
file_get_contents($url, false, stream_context_create($opts));

加上一个cron就可以做一些自定义的控制了。

Home Assistant REST API 官方文档：

HA的API几乎可以做所有的操作，官方文档有详细实例。
https://developers.home-assistant.io/docs/api/rest/

开启Home Assistant接口功能

API功能是Home Assistant系统默认就带的，只需在菜单administrator中开启高级模式，再在长期访问令牌中添加一个TOKEN就可以了。

注意生成了TOKEN要及时复制保存，关闭了alert就再也看不到了。

除了灯和开关 为什么找不到其他的控制方法？

灯和开关都可以找到demo，一搜一大堆。除了这两个方法之外就几乎再也找不别的方法实例了，github和官方文档都没有，难道所有人只操作灯和开关？

官方文档services方法这样写：

Returns an array of service objects. Each object contains the domain and which services it contains.

看了几遍我都没有明白，直到我把自己的services全部打印出来，里面把所有的域名，方法，属性全部列了出来。
只要按照里面的数据，构建自己的请求就可以了。

我做了4个方法：

• light 控制灯
• switch 控制开关
• cover 控制电机(窗帘等)
• text 控制小爱语音

如果有小爱，是有一个偷懒的办法的，只要一个text就够了，所有的操作都让小爱去干就可以了，比如关闭4个灯：
light(灯0, off)，light(灯1, off)，light(灯2, off)，light(灯3, off)

text(小爱同学，关闭所有的灯。)

Xiaomi Miot Auto

Xiaomi Miot Auto是一个非常不错的集成，支持米家几乎所有的非触发型设备，

安装 Xiaomi Miot Auto For HomeAssistant

文档 github

https://github.com/al-one/hass-xiaomi-miot/blob/master/README_zh.md

• 进入容器

  docker exec -it HASS bash

• 安装

  wget -O - https://get.hacs.vip | DOMAIN=xiaomi_miot bash -

• 配置

  配置 > 设备与服务 > 添加集成
  添加 Xiaomi-Miot-Auto
  Add devices using Mi Account (账号集成) > 云端模式

本地模式还是云端模式

开始我是使用的是作者推荐的自动模式，自动模式的意思支持本地模式的设备本地化，不支持本地模式的设备走云端模式，也就是说大部分设备是本地化运行的。

但我发现本地模式有个致命的问题，当网络重启(DHCP)，设备新获取到的IP地址与设备添加时的IP地址不一致时，设备就掉线了。尝试重载设备等方法均无效。到现在我也不知道如何解决这个问题。

而后我只能尝试云端模式。经过长时间的运行，发现云端模式非常稳定。所以只要家庭网络稳定，云端模式是非常不错的选择。

可以部署到公网？

我猜想：如果只走云端控制设备，把HASS部署在公网服务器上也是一样的，还更稳定。外网操作HASS的问题也就存在了。硬件设备也不需要了，功耗问题也不存在了。
回头试试，验证一下。