常见问题
关于充电桩使用、平台运维、协议集成与业务合作的常见问题解答。如未找到答案，欢迎联系我们。
一、用户端（APP 使用者）常见问题
APP 上显示充电桩"空闲"，到了现场却充不了电，怎么回事？ ▾
这通常涉及状态同步延迟或"软故障"。OCPP 1.6 依赖 StatusNotification 上报连接器状态，若网络抖动或心跳中断，平台可能仍显示旧状态；OCPP 2.0.1 虽然通过 TransactionEvent 和更细粒度的监控改善了这一点，但若桩端检测到故障（如急停按下、枪锁故障）且未及时上报 NotifyEvent，APP 端仍可能误判为可用。建议在 APP 详情页增加"最后一次状态更新时间"提示。
为什么扫码后启动很慢，有时候要等十几秒？ ▾
启动延迟通常发生在 Authorize 鉴权与 StartTransaction（1.6）或 TransactionEvent(Started)（2.0.1）的往返过程中。若平台与桩之间的 WebSocket 心跳不稳定，或桩端信号弱，指令下发会重试。OCPP 1.6 的 StartTransaction 需要等待平台返回事务 ID 才能闭合，而 2.0.1 的事件驱动模型理论上更快，但若桩端固件对 TransactionEvent 处理不当，也可能造成卡顿。
充电中途停止，APP 显示"充电中"，桩却已经停了？ ▾
这是典型的状态不同步。OCPP 1.6 下，若桩因过温、漏电保护或枪被拔（但未正常发送 StopTransaction）而停止，平台可能因未收到 StatusNotification(Faulted/Available) 而维持充电中状态。OCPP 2.0.1 的 TransactionEvent(Ended) 设计更严谨，但需要桩端正确实现。平台侧可设置"心跳超时自动结束本地订单"的兜底逻辑。
同一个充电桩，为什么有时候 APP 显示支持即插即充，有时候不行？ ▾
即插即充（PnC/ISO 15118）是 OCPP 2.0.1 的原生能力，而 OCPP 1.6 不支持标准 PnC。如果平台接入了两种协议的桩，APP 应根据桩的实际协议版本和配置动态展示功能标签。若 2.0.1 桩的证书链未正确配置，PnC 也会失效，此时 APP 应回退提示"请扫码启动"。
二、运营/运维端常见问题
平台上有些桩显示离线，但现场看桩屏幕是亮的，怎么排查？ ▾
按网络层→WebSocket 层→OCPP 层顺序排查：①检查桩是否能访问平台 wss:// 地址（DNS、防火墙、443 端口）；②检查 Charge Point Identity 与 URL 路径是否完全匹配（例如 /ocpp/CP001 中的 ID 大小写或后缀错误）；③OCPP 1.6 查看 Heartbeat 是否正常，OCPP 2.0.1 查看 BootNotification 后的 Heartbeat 与安全事件日志。若桩本地屏幕正常但 OCPP 离线，通常是桩端 OCPP 模块死机或 SIM 卡流量耗尽。
OCPP 1.6 和 2.0.1 的桩混用，平台需要做两套对接逻辑吗？ ▾
需要，但可抽象。两者消息不兼容：1.6 用 StartTransaction/StopTransaction，2.0.1 用 TransactionEvent；1.6 配置靠 ChangeConfiguration 键值对，2.0.1 用结构化的 SetVariables/GetVariables 设备模型。建议平台在协议层之上建立统一"充电会话"模型，将两种协议的消息映射到同一业务对象，避免上层业务重复开发。
远程重启/远程停充指令经常失败，可能是什么原因？ ▾
OCPP 1.6 的 RemoteStartTransaction 要求桩端在收到后先做本地鉴权（如 Authorize），若桩的本地白名单缓存过期或 AuthorizeRemoteTxRequests 配置不当，会拒绝执行。OCPP 2.0.1 的 RequestStartTransaction 逻辑更严格，需要平台先确保 EVSE 和 Connector 的 AvailabilityState 为 Operative。此外，若 WebSocket 连接假死（TCP 通但应用层无响应），指令会超时，需依赖 TriggerMessage 或心跳超时检测来重置连接。
固件升级用 OCPP 1.6 还是 2.0.1 更可靠？ ▾
OCPP 2.0.1 的固件管理更安全、可追溯。1.6 的 UpdateFirmware 通常是"下发 URL → 桩下载 → 桩重启"，平台难以获知下载进度和校验结果；2.0.1 的 PublishFirmware 配合 UpdateFirmware 支持分块下载、安全校验和状态上报，更适合大规模运维。若平台仍以 1.6 为主，建议升级流程中增加"升级后 BootNotification 校验版本号"的步骤。
三、协议与技术集成常见问题
桩支持 OCPP 1.6，平台也支持，为什么接上来还是失败？ ▾
"支持 OCPP 1.6"不等于"即插即用"。常见断点包括：WebSocket 地址格式（末尾斜杠、路径大小写、是否用 wss）、Charge Point Identity 不匹配、消息子协议未协商（ocpp1.6）、TLS 证书不被桩信任（老旧固件不认新 CA）。OCPP 2.0.1 还额外要求安全配置文件（Security Profile）匹配，若平台强制 TLS 而桩仅支持基础认证，握手会直接失败。
我的平台同时支持 1.6 和 2.0.1，一个桩能自动切换吗？ ▾
不能自动切换。OCPP 版本在 WebSocket 握手阶段通过子协议（如 ocpp1.6、ocpp2.0.1）确定，桩端固件通常只实现其中一个版本。平台需要根据桩的 BootNotification 或连接 URL 中的标识来路由到对应的协议处理器。同一个物理桩无法在运行中从 1.6 "升级"到 2.0.1，除非更换固件并重新配置。
OCPP 2.0.1 的"设备模型"对平台开发有什么实际影响？ ▾
1.6 下，平台想知道桩支持什么功能，往往靠 GetConfiguration 拉取一堆厂商自定义键；2.0.1 的设备模型用树状结构标准化了 EVSE → Connector → Component → Variable，平台可以精确读写某个枪的温度阈值、某个继电器的状态。这对精细化运维和远程诊断是质的提升，但要求平台后端重构配置管理模块，不能沿用 1.6 的扁平键值存储。
智能充电（负载均衡）在两种协议下有什么差异？ ▾
1.6 支持基础的 SetChargingProfile（静态或基于时间的简单曲线），但缺乏电网协同和动态调整能力。2.0.1 的智能充电更完整，支持 ChargingStationExternalConstraints、动态功率上限下发和多桩集群调度，且与 ISO 15118 的 ChargeParameterDiscovery 可联动。若场站要做"有序充电"或"需量控制"，2.0.1 桩是更好的选择，但平台侧的充电计划引擎需要相应升级。
四、业务合作
如何与 LinkChargeHub 开展业务合作？ ▾
我们提供加盟合作、设备采购、场地运营与企业定制四种合作模式，覆盖代理商、物业与地产商、车队运营方等不同角色。提交合作意向告诉我们您的场地情况与合作意向，商务团队将在 24 小时内与您联系，并提供方案测算与现场勘测支持；您也可以通过「联系我们」页面直接发送邮件咨询。