资讯专栏INFORMATION COLUMN

记一次难忘的微信蓝牙硬件入坑过程

wing324 / 3348人阅读

摘要:前几个月的时候,开发了一个微信硬件相关的项目,其业务相对比较简单,就是一个微信的蓝牙硬件设备,通过微信硬件传输一些数据到我们这边的服务器。

前几个月的时候,开发了一个微信硬件相关的项目,其业务相对比较简单,就是一个微信的蓝牙硬件设备,通过微信硬件 JSAPI 传输一些数据到我们这边的服务器。

有开发微信硬件的朋友,应该都会有了解,这个流程大致如下:

但是最近客户向我反馈,收不到硬件发送的信息了。

这怎么可能,代码、服务器都没有变过,怎么可能会出问题呢?但毕竟客户就是上帝,这个问题得检查一下啊,我怀着一颗忐忑的心,看了一下服务器的 Log 日志。

看到了这段日志,更觉得奇怪,easywechat 的扩展包从来没有升级过,此版本 3.1。怎么可能会出这个问题呢?我打开了Guard.php这个文件的代码:

    /** 
     * Handle message.
     *
     * @param array $message
     *
     * @return mixed
     */
    protected function handleMessage(array $message)
    {
        $handler = $this->messageHandler;

        if (!is_callable($handler)) {
            Log::debug("No handler enabled.");

            return null;
        }

        Log::debug("Message detail:", $message);

        $message = new Collection($message);

        $type = $this->messageTypeMapping[$message->get("MsgType")];

        $response = null;

        if ($this->messageFilter & $type) {
            $response = call_user_func_array($handler, [$message]);
        }

        return $response;
    }

第 393 行的代码是这一行:

$type = $this->messageTypeMapping[$message->get("MsgType")];

从日志来看,错误很明显,我打印了一下$message->get("MsgType") ,结果为 null。

各种 Google 无果,最终找来了超哥,easywechat 的作者,在超哥的帮助下,定位到了错误。

从 wechat 的 log 日志中看,有收到硬件发送来的数据,但是收到的数据是这样的:

{
    "device_id": "gh_e6a24fdc82b6_69b49a3ee626ee55",
    "device_type": "gh_e6a24fdc82b6",
    "msg_id": "524313758",
    "msg_type": "device_text",
    "create_time": "1516171166",
    "open_id": "o7iyW0sUwv4wH6PWhextVbtPkNVE",
    "session_id": "380219",
    "content": "AQAPAgATAwAWBAAA"
}

而正常的文本消息数据包是这样的:

{
    "ToUserName": "gh_e6a24fdc82b6",
    "FromUserName": "o7iyW0sUwv4wH6PWhextVbtPkNVE",
    "CreateTime": "1516171641",
    "MsgType": "text",
    "Content": "123",
    "MsgId": "6511907613782547557"
}

MsgType ??

msg_type ??

WTF?微信开发的程序员们?你们是在逗我吗?

这个数据结构……

这个命名规范……

无力吐槽……

问题已经确认,微信的协议发生了变更,我调整了一下 easywechat 的变量命名和一些细节程序,感兴趣的小伙伴点击这里:https://github.com/todayqq/we...

修改的部分已经提交 PR 到原先的 wechat 扩展包中,希望有开发微信硬件的小伙伴,不要重复入坑。

最后,感谢超哥的帮助!

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/28130.html

相关文章

  • 一次使用Fiddler抓包工具抓取Https协议数据的踩坑过程

    摘要:直到今天,突然看到一个有意思的微信小游戏。后来试了几次之后才发现,这个小游戏比较刁,不仅做了微信的登录授权,而且做了手机端访问的判断,更甚至竟然用的还是协议的网页。调用的目标发生了异常。 记一次使用Fiddler抓包工具抓取Https协议数据的踩坑过程 前言 记得从刚入门前端第一天开始,当时的师傅就跟我介绍了一个可以抓取一些必须要在微信浏览器打开的链接的工具Fiddler,主要用来抓取...

    JackJiang 评论0 收藏0
  • 世间最美好的相遇是久别重逢、犹如你在什么时候选择软件测试、不思量 自难忘...

    摘要:软件测试,远远不是简简单单的事。下面是我整理出来的一份软件测试工程师学习与发展知识架构体系图。 软件测试,远远不是简简单单的事。然后就Java,Python,说只...

    JouyPub 评论0 收藏0
  • 一次使iview库的Radio可取消的过程

    摘要:概述库用的是是我们非常常用的组件。有一个特征是选中之后无法取消。现实中取消的需求是常见且可以理解的。所以看到这个需求之后第一尝试在组件之上搞一搞,这一搞就入坑了,现在就来理一理我的入坑之路吧。 概述 ui库用的是iview . radio、radioGroup是我们非常常用的组件。radio有一个特征是选中之后无法取消。现实中取消radio的需求是常见且可以理解的。所以看到这个需求之后...

    荆兆峰 评论0 收藏0
  • 一次修复微信支付吊起非常慢的问题

    摘要:记一次修复微信支付吊起非常慢的问题微信接支付调用有些安卓手机吊起非常慢,因为调支付写法就是这样子,实在定位不到问题所在,正在打算放弃的时候。定位会导致支付吊起不了吗原来之前把浏览器定位换成了微信定位,解决安卓下面会频繁弹授权的问题。 记一次修复微信支付吊起非常慢的问题 微信h5接支付调用 window.wx.invoke(getBrandWCPayRequest) 有些安卓手机吊起非常...

    Mertens 评论0 收藏0
  • 一次修复微信支付吊起非常慢的问题

    摘要:记一次修复微信支付吊起非常慢的问题微信接支付调用有些安卓手机吊起非常慢,因为调支付写法就是这样子,实在定位不到问题所在,正在打算放弃的时候。定位会导致支付吊起不了吗原来之前把浏览器定位换成了微信定位,解决安卓下面会频繁弹授权的问题。 记一次修复微信支付吊起非常慢的问题 微信h5接支付调用 window.wx.invoke(getBrandWCPayRequest) 有些安卓手机吊起非常...

    hatlonely 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<