这一切的起源来自于9月份的某个晚上没有找到充电桩……
事实上在那之前已经有一个南哪充电的网页了: https://charge.zhuxh.net/

不过我个人用起来感觉还是差点意思,只能一眼看见哪里还有空闲,但由于充电桩过于不够,想充电的时候很可能是一片全红,或者仅有的绿色离自己很远。
于是我也准备自己写一个,能够显示预计剩余时间,方便我去提前蹲守 ,卷死你们
后端爬取数据
爬虫对我来说还是挺简单的,毕竟也写了好几个爬虫相关项目了,Reqable启动!
获取充电站ID
首先闪开来电在一堆请求中筛选出属于南大仙林的充电站点,拿到充电站点的 station_id ,这一步属于纯手抄,具体id如下:
获取每个充电站下插座ID
上一步只有33个充电站,手抄倒也能接受,不过302个插座ID也要手抄的话还是放过我吧。
写于2025年6月16日:为啥新增的充电桩好多都是一个充电站就俩插座,导致我今天手抄了好久的station_id。目前仙林校区累计112个充电站,724个插座。
从 f'https://wemp.issks.com/charge/v1/outlet/station/outlets/{station_id}' 中可以获取每个充电站点的信息,其中包含插座的id。
终于,来获取每个插座的状态吧
在上一步我们能拿到每个充电站(比如天文学院)下每一个充电插座的outletNo,这一步就可以根据outletNo,从 f'https://wemp.issks.com/charge/v1/charging/outlet/{outletNo}' 中获取每个插座的具体状态了!
返回示例:
其实里面很多信息都是不必要的,我这里把插座名称、预计剩余时间、已使用时间、状态代码(空闲、故障、分钟计费模式、固定金额模式)、是否有错误信息这几个拿下来就好了,同时再算出一个预计可用时间方便前端直接展示(毕竟我前端实在太弱了)。代码如下:
幸运的是,获取状态这一步并不需要token,而每个站点下面的插座完全固定不变。之后更新数据只要根据已有的outletNo重复执行这一步就OK了。
数据后处理
我自己部署时用多线程(302条数据基本2秒左右就搞定了,实测下来也不会触发风控)跑,定时每分钟在后端机器上更新一次数据。
为了方便前端调用,我还在后端将数据按照剩余时间排序,以及将充电站点从原来按xx号机归类改为xx栋:
第一版前端
毕竟是前端白痴,我的第一版前端设置是使用Python生成的。>︿<
发出来给大家笑话一下
而且界面也是相当简陋,不过好歹还是用GPT帮我生成了一段js代码用于筛选站点

第二版前端
所谓的第二版也只是写了几句css尽力去拯救这个界面罢了。

第三版前端
我开始捣鼓我的新版个人主页了,既然Mix Space支持写Markdown with JavaScript,我就把/charge.html挂在了个人主页下了,并且也改进了原来的筛选功能,进行筛选的同时会更改URL参数,这样刷新之后也能记住上次用户筛选的站点并直接展示出来了。

第四版前端
由于从第一版就用表格展示,从上面的图也能看出来,在更常用的应用场景——手机上的体验属实一言难尽。于是下定决心重构了半天的UI,并且在开头添加了一个统计表格,可用更方便地规划充电目的地了。

基本所有前后端代码都在下面的github仓库中,欢迎使用但请遵守MIT协议,使用时保留我的版权信息。
后续小更新
- 2024-12-01:新增鼓楼校区。
- 2025-01-07:今天突然发现充电必须充值后按分钟计费了,岂可休。更新了按已使用时间逆序,按照闪开充电提供的说明,这个时间最大为480分钟,至少还是能作为参考大概知道哪个充电桩快结束了。
- 2025-02-22:分钟计费模式用户可以自选预充值的金额了,因此可以根据这个估算预计可用时间了。但考虑到有些人直接选往高了选以便充满,同时接口返回数值的精度导致最后计算精度较低,因此仅供参考。电度计费模式理论上也可以估计,但考虑到接口中没有办法直接读取功率,因此暂不编写。
- 2025-06-16:新增鼓楼和仙林多处充电桩。(插座数变化:鼓楼148->308,仙林302->724)
- 2025-06-22:貌似系统设置的最长充电时间为480分钟,因此基于此对剩余时间的预计做了修改。
- 2025-09-09:删除历史充电记录功能。
- 2025-10-11:更新充电桩。