其实这篇文章前半部分在 7 月 5 号就写了,但是写着写着就没了灵感(讲真,就像突然被人灌了硫酸铜变哑巴了),于是一直拖到现在(7 月 13 号)。 更正:因为住处装修的关系,这篇文章一直拖到 7 月 24 号才发布。

嗯,久违地看一下博客后台,果然上一次写文章又是近一个月前,我这博客都快写成月报了 (´・_・`)。 上次文章里说到我入手了一块 KBT Race 2 青轴键盘,我打算另起一篇文章详细地讲讲这件事,关于这个无良卖家,我要好好地批判一番。

好了,进入正题。我的一些朋友和同事可能知道我去年年底入手了一个树莓派(B+),然后年初做了一个温度和气压监控的小玩意。最初数据和 Web 查看器是放在一起的,都托管在 SAE 上;但是后来 SAE 稳定性越来越差,最厉害的一次 KVDB 服务挂掉长达 7、8 个小时,官方微博完全没反应,错误原因甚至修复进展通告都没有一条,简直无法忍受;于是后来数据存储搬到了 LeanCloud 上,查看器托管在自己 VPS 上了。架构的变化如图。

structure.png

其实这个玩意除了可以在办公室知道家里的环境情况,基本没什么其他用处。现在天气比较热,我有时候用来观察家里的空调定时功能有没有问题;上次就发现数据在雷暴中间断掉了,我当时判断家里电源跳闸了,下班回家一看果然如此。

但是这样还不够,这个项目(姑且称为项目)里的数据不是实时的,而是每 5 分钟由我的树莓派上报到 LeanCloud 存储。这样做的原因有两个:一是 5 分钟这个间隔对于气温来说已经足够小,再细分到 1 分钟甚至 30 秒并不会有什么很大差距了;二是纯粹避免太多次请求,因为之前我还尝试过上报网络情况,每分钟 ping 一次百度将响应事件上传到服务器,结果几天之后 ping 哪家哪家就无法访问。

那么什么情况下需要实时或者接近实时的响应呢?如果树莓派上接了家用电器的话,例如空调或是热水器、音响之类的,我就希望可以实时进行控制。之前我的想法是,树莓派在每 5 分钟去上报数据的时候,同时也去服务器上取数据。这样的话,我下一个命令,最多 5 分钟之后家里的电器就可以开始执行我的指令。

但是后来想想还是不够,不到 5 分钟已经可以烧开一壶水了,这个间隔明显太大。那么有什么办法可以与树莓派进行双向(或者近似双向)的交互呢?随后我在搜索树莓派摄像头的资料时,无意间发现了淘宝架构师 Hugo Zhu 的这篇文章《用Telegram和树莓派交互》

其中主要是使用到了 telegram-cli 这个东西,是一个命令行的 Telegram 客户端,并且支持 Python 和 Lua 脚本回调。具体说起来,就是启动时可以加载一个脚本,在这个脚本中可以设定一些回调,比如收到新消息时进行什么操作;然后新消息到来时就可以触发这个回调,进行一些操作了。最简单的就是收到消息之后回应一条消息。

具体使用方法看 Hugo 的文章就可以了解个大概,更详细的可以去看 telegram-cli 的 Pythong binding 文档或 Lua binding 文档。

然后说一下一些缺陷。

首先是帐号的问题,由于 Telegram 只能使用手机号进行注册,而很多人其实只有一个手机号码,那么意味着你不得不在 telegram-cli 上登录你自己的帐号。说白了,就是你和机器人使用同一个帐号。这种情况下机器人发出的消息,实际上就是你发出的消息。

第二个就是由同帐号问题带来的通知提醒问题,Telegram 同帐号跨设备的消息是不会有通知提醒的,这可能会给交互带来一些问题。比如机器人主动推送的消息你可能注意不到。

第三个是可能的安全问题。telegram-cli 会保存你的登录授权(实际上基本上所有 Telegram 客户端都是一经登录几乎永不失效),一旦这个客户端暴露给了别人就可能对你帐号的安全带来隐患。

最后也不得不吐槽一下 telegram-cli 的稳定性。不知道是作者根本就没做错误处理还是怎么地,平均两天崩溃一次,高峰时期一天崩溃三次。

虽然有这么多缺陷,但是用 telegram-cli 做的机器人还是挺多的。似乎大名鼎鼎的 LiberBot 就是用这个客户端做的。

Telegram 官方也适时推出了 Bot API——专门给机器人使用的接口。并且官方的机器人账号是不需要手机号注册的,也可以主动推送消息(但不能主动发起会话)。于是我正在将机器人从 telegram-cli 转移到官方 API 这边。目前机器人独立运行在 VPS 上,还没有与树莓派连接起来。具体架构和源码会在下一部分介绍。