Вопросы и ответы

Обычно причина в задержке синхронизации статуса или в «мягкой» неисправности. В OCPP 1.6 статус коннектора передаётся через StatusNotification; при нестабильной сети или пропущенных heartbeat платформа может показывать устаревший статус. В OCPP 2.0.1 это решается лучше благодаря TransactionEvent и более детальному мониторингу, но если станция обнаружила неисправность (нажата аварийная кнопка, сбой блокировки пистолета) и вовремя не отправила NotifyEvent, приложение всё равно может считать её доступной. Рекомендуем показывать в карточке станции время последнего обновления статуса.

Задержка обычно возникает на этапе Authorize и StartTransaction (1.6) или TransactionEvent(Started) (2.0.1). Если WebSocket-heartbeat между платформой и станцией нестабилен или сигнал слабый, команда отправляется повторно. В OCPP 1.6 нужно дождаться от платформы transaction ID до подачи питания; событийная модель 2.0.1 теоретически быстрее, но при слабой обработке TransactionEvent в прошивке задержки тоже возможны.

Это классическая рассинхронизация состояний. В OCPP 1.6, если станция остановилась из-за перегрева, защиты от утечки или извлечения пистолета и не отправила корректный StopTransaction, платформа может сохранять статус зарядки, не получив StatusNotification(Faulted/Available). В OCPP 2.0.1 TransactionEvent(Ended) строже, но требует корректной реализации на стороне станции. Со стороны платформы полезно правило «автоматически закрывать локальный заказ по таймауту heartbeat».

Plug & Charge (PnC / ISO 15118) — штатная возможность OCPP 2.0.1; OCPP 1.6 стандартный PnC не поддерживает. Если платформа обслуживает станции на обоих протоколах, приложение должно показывать признаки функций исходя из фактической версии протокола и настроек каждой станции. Если в 2.0.1 неправильно настроена цепочка сертификатов, PnC не работает, и приложение должно предлагать «отсканируйте QR-код для старта».

Проверяйте по порядку: сеть → WebSocket → OCPP. ① Доступен ли станции адрес wss:// платформы (DNS, firewall, порт 443). ② Совпадает ли Charge Point Identity с путём в URL в точности (например, регистр или суффикс в /ocpp/CP001). ③ В OCPP 1.6 проверьте Heartbeat; в 2.0.1 — Heartbeat после BootNotification и журнал событий безопасности. Если локальный экран работает, а OCPP офлайн, обычно завис модуль OCPP или закончился трафик SIM-карты.

Нужны, но их можно абстрагировать. Сообщения протоколов несовместимы: в 1.6 — StartTransaction/StopTransaction, в 2.0.1 — TransactionEvent; конфигурация в 1.6 идёт через пары ключ-значение ChangeConfiguration, в 2.0.1 — через структурированную модель SetVariables/GetVariables. Рекомендуем построить над протокольным слоем единую модель «сессии зарядки» и отображать сообщения обоих протоколов в один бизнес-объект — это избавляет от дублирования разработки.

RemoteStartTransaction в OCPP 1.6 требует, чтобы станция сначала выполнила локальную авторизацию (Authorize). Просроченный локальный кэш белого списка или неверная настройка AuthorizeRemoteTxRequests приводят к отказу. RequestStartTransaction в OCPP 2.0.1 строже: платформа должна убедиться, что AvailabilityState у EVSE и коннектора — Operative. Кроме того, при «полуживом» WebSocket (TCP открыт, но прикладной уровень не отвечает) команды уходят в таймаут — используйте TriggerMessage или детект таймаута heartbeat для пересоздания соединения.

Управление прошивкой в OCPP 2.0.1 безопаснее и лучше отслеживается. В 1.6 UpdateFirmware обычно означает «передать URL → станция скачивает → перезагрузка», и платформа не видит ни прогресс, ни результат проверки. В 2.0.1 PublishFirmware вместе с UpdateFirmware поддерживает частями загрузку, проверку безопасности и отчёты о статусе — это удобнее при большой сети. Если у вас в основном 1.6, добавьте в процесс шаг «подтверждение версии через BootNotification после обновления».

«Поддержка OCPP 1.6» не означает «работает сразу». Частые причины: формат адреса WebSocket (завершающий слэш, регистр в пути, wss или ws), несовпадение Charge Point Identity, не согласован подпротокол (ocpp1.6), станция не доверяет TLS-сертификату (старая прошивка не знает новый CA). В OCPP 2.0.1 дополнительно требуется совпадение security profile: если платформа требует TLS, а станция поддерживает только basic auth, рукопожатие сразу завершится ошибкой.

Нет. Версия OCPP определяется при рукопожатии WebSocket через подпротокол (ocpp1.6, ocpp2.0.1), и прошивка станции обычно реализует только одну версию. Платформа направляет соединение к обработчику нужного протокола по BootNotification или по идентификатору в URL. Физически станция не может «перейти» с 1.6 на 2.0.1 на ходу без замены прошивки и перенастройки.

В 1.6, чтобы понять возможности станции, часто нужно вытащить через GetConfiguration множество vendor-специфичных ключей. В 2.0.1 device model стандартизирует дерево EVSE → Connector → Component → Variable, поэтому платформа может точечно читать и записывать значения, например порог температуры конкретного пистолета или состояние реле. Для детального обслуживания и удалённой диагностики это качественный шаг вперёд, но на бэкенде приходится уходить от плоского хранилища ключ-значение к структурной модели.

В 1.6 есть базовый SetChargingProfile (статичный или простой временной график), но нет взаимодействия с сетью и динамической подстройки. В 2.0.1 возможности шире: ChargingStationExternalConstraints, динамические ограничения мощности, групповая работа нескольких станций, а также совместимость с ChargeParameterDiscovery из ISO 15118. Если нужны «упорядоченная зарядка» или управление спросом, станции на 2.0.1 предпочтительнее, но движок графиков зарядки на платформе придётся доработать.

У нас четыре модели: франшиза, закупка оборудования, эксплуатация площадки и корпоративные решения — они покрывают агентов, управляющие компании и застройщиков, операторов автопарков и других. Оставить заявку с описанием площадки и задачи, и наша команда свяжется в течение 24 часов, подготовит расчёт и поможет с обследованием. Также можно написать напрямую через страницу «Контакты».