其实这篇文章前半部分在 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 上，还没有与树莓派连接起来。具体架构和源码会在下一部分介绍。