EVCC项目中Tibber-Pulse连接问题的分析与解决

问题背景

在EVCC开源项目中，用户报告了一个与Tibber-Pulse集成相关的问题：系统频繁重新连接Tibber Websocket API，导致超过了Tibber后端设定的每小时20次的连接限制。这一问题表现为EVCC大约每60秒就会重新建立与Tibber API的连接，并在日志中显示"Rate limit exceeded"错误。

技术分析

通过深入分析日志和代码，我们发现问题的根源在于EVCC与Tibber API之间的Websocket连接超时设置不当。具体表现为：

1. 连接稳定性问题：EVCC默认设置了10秒的Websocket读取超时时间，这在Tibber API的实际工作模式下显得过于严格。

2. 数据更新频率差异：测试发现，使用Tibber提供的DEMO令牌时，数据更新频率约为每秒1次；而使用真实数据时，更新间隔可能达到3秒甚至出现15秒的间隔。这种差异导致10秒的超时设置在实际环境中频繁触发。

3. 底层实现机制：当超时发生时，go-graphql-client库会尝试重新建立连接。这一行为虽然是设计上的容错机制，但在当前场景下导致了不必要的频繁重连。

解决方案

经过技术团队的深入研究和测试，确定了以下解决方案：

1. 调整超时参数：将Websocket读取超时时间从10秒增加到90秒，这与Home Assistant等项目中使用的设置保持一致，能够适应各种Tibber电表硬件的实际工作特性。

2. 版本兼容性考虑：在实现解决方案时，团队还注意到了版本信息传递的问题，确保在用户代理字符串中正确包含版本信息以便于问题追踪。

实施效果

该解决方案已通过以下方式验证其有效性：

• 在测试环境中，修改后的版本成功消除了频繁重连的问题
• 实际用户反馈确认修改后的版本运行稳定，不再出现连接限制错误
• 系统能够适应不同Tibber电表硬件的数据更新频率差异

技术启示

这一案例为我们提供了几个重要的技术启示：

1. API集成需要考虑实际工作模式：不能仅基于测试环境或DEMO数据来设计系统参数。

2. 超时设置需要平衡：既要防止无限等待导致的系统僵死，又要避免过于敏感导致不必要的重连。

3. 日志监控的重要性：完善的日志系统能够帮助快速定位和解决这类连接稳定性问题。

通过这次问题的分析和解决，EVCC项目在Tibber-Pulse集成方面获得了宝贵的经验，也为其他类似项目提供了参考。