FAQ

Tres requisitos para conectar un cargador:

• el cargador dispone de una conexión a internet estable (preferiblemente por cable);
• el cargador dispone de una herramienta de administración a la que puede acceder para cambiar la URL del CSMS;
• el cargador tiene el firmware actualizado antes de su primera conexión al CSMS.

El cargador solo puede actualizarse a distancia después de su primera conexión. Atención: una actualización de firmware puede causar fallos o regresiones. Recomendamos probar siempre antes el firmware en un cargador de pruebas.

Si el cargador usa una red local, el equipo informático debe permitir el tráfico saliente de los cargadores hacia el dominio charge-angels.com (puerto TCP 443) y desactivar el cortafuegos de salida, o bien autorizar las direcciones IP de nuestro servidor (que debe solicitar a un administrador).

La red debería ser por cable siempre que sea posible, para evitar límites de distancia y de ancho de banda. La latencia de red tolerada debe ser inferior a 500 ms.

Los cargadores pueden utilizar varios modos de comunicación: LAN (Ethernet) o WAN (Wi-Fi). En la mayoría de los casos, el cargador se comunica por defecto con el DHCP (Dynamic Host Configuration Protocol) de la red local y obtiene una dirección IP automáticamente; de lo contrario, debe configurarse una dirección IP manual en el cargador. El router se conecta a internet a través del proveedor del cliente: ADSL, fibra o GSM.

Si prefiere una red 4G, necesitará tarjetas SIM M2M (dedicadas a IoT), preferiblemente con roaming. En cuanto al volumen de datos, cuente 200 kB por punto de recarga.

• La configuración del APN depende del operador.
• Son preferibles las tarjetas SIM con roaming activado: la mejor red se elige en tiempo real. El roaming puede ser en Francia o en todo el mundo, según sus necesidades.
• En general, prevea un plan de datos de 200 MB por punto de recarga para un uso intensivo.
• Una VPN no es útil si el cargador se comunica mediante WSS.

ChargeAngels utiliza una conexión WebSocket segura (WSS) entre el cargador y el backend. Solo admitimos TLS 1.3 (TLS 1.2 está obsoleto). ChargeAngels admite certificados SSL RSA y ECDSA. Utilizamos Node.js con la biblioteca uWebSockets.js para gestionar los WebSockets.

• Creado en 2011, WebSocket (WS) es un protocolo de red de la capa de aplicación «bidireccional, asíncrono y full-duplex» entre cliente y servidor, normalizado por el IETF en la RFC 6455 y por el W3C.
• WebSocket abre una conexión permanente full-duplex entre el cliente y el servidor: el servidor puede enviar datos a un cliente por iniciativa propia, a diferencia del protocolo HTTP.
• WebSocket Security (WSS) utiliza la capa de transporte TLS, como HTTPS, para cifrar las comunicaciones: por tanto, es más seguro.

Tal como describe la especificación «OCPP 1.6 security whitepaper edition 3», admitimos:

• Perfil de seguridad 1: WS con autenticación básica (usuario / contraseña o clave de autorización, a su elección);
• Perfil de seguridad 2: autenticación básica o WSS TLS con el certificado raíz del servidor (ISRG Root X1);
• Perfil de seguridad 3: WSS TLS tanto en el punto de recarga como en el servidor (probado, pero no oficialmente en producción).

Pruebas OCA: los casos de prueba TC_085_CSMS (autenticación básica, combinación válida de usuario / contraseña), TC_086_CSMS (TLS, certificado de servidor válido) y TC_087_CSMS (TLS, certificado de cliente válido) se superan con la herramienta de pruebas de la Open Charge Alliance.

Clave de autorización (Authorization Key): mínimo 16 caracteres y codificación hexadecimal, entre 20 y 40 caracteres.

Recomendamos probar siempre la primera conexión del cargador con el perfil de seguridad 1 (WS), después con el 2 (WS y WSS) y por último con el 3 (WSS).

Un Tenant es un subespacio del dominio principal, por ejemplo cpo1.charge-angels.com.

• Si ha elegido la solución SaaS, organiza su Tenant en la pestaña «Organización» del CSMS.
• Si ha elegido la solución Full Cloud, tiene acceso al «Master Tenant» y puede crear tantos «Cloud Tenants» como necesite.

El Tenant dispone de una base de usuarios común, cuya clave central es la dirección de correo electrónico. Puede desglosarse en varios niveles jerárquicos: empresas, emplazamientos y zonas.

• Los emplazamientos pueden ser zonas geográficas distintas de un mismo cliente (por ejemplo, depósitos de autobuses).
• Los emplazamientos también pueden ser subclientes distintos que comparten una base de usuarios común.
• Una zona es un grupo de cargadores; define la topología física del lugar: una zona puede equivaler a un cuadro general de baja tensión (TGBT) o a un contrato de potencia (por ejemplo, un suministro de 220 kVA).
• El SmartCharging se gestiona por zona (potencia máxima declarada en el cuadro general).

Un «token» es una URL de conexión WSS que el cargador utiliza para conectarse a los servidores del CSMS de ChargeAngels. El token es único y específico de una zona.

Una vez creada su organización, puede crear uno o varios tokens de conexión al backend desde el menú «Cargador» y después «Conectar un cargador»: créelo, añada un título, una fecha de validez y una zona, y guarde.

Puede copiar el token para usarlo más tarde o de inmediato (por ejemplo, «OCPP 1.6 JSON»). Puede transmitirse a los equipos que despliegan cargadores sobre el terreno. Por razones de ciberseguridad, ChargeAngels optó por crear tokens dinámicos con fecha de validez, a diferencia de otros CSMS.

El token (o URL) se compone de 4 partes

• el prefijo: HTTP / HTTPS / WS o WSS;
• «OCPP16» u «OCPP201», según la versión de OCPP;
• la primera parte del token es el identificador único del tenant;
• la segunda parte es el identificador del propio token, vinculado a una zona;
• la última parte es el nombre del cargador: el ChargeBoxID.

wss://charge-angels.com/OCPP16/<tenant-id>/<token-id>/CHARGER-01

Una vez copiado el token en la administración del cargador, el cargador abre un socket hacia los servidores del CSMS. El cargador (aquí CHARGER-01) aparece automáticamente en el panel, sin ninguna acción en el backend. Cuando el cargador es visible, edite sus atributos (potencia máxima, ubicación, conectores, etc.).

En la administración de algunos cargadores, la URL y el ChargeBoxID se dividen en varios campos: «Host», «Port», «Path» y «ChargeBoxID» (el nombre del cargador). A veces hay que comprobar la URL así construida (atención a las distintas barras).

Nombrar sus cargadores

Recomendamos definir una convención de nomenclatura para los cargadores. El ChargeBoxID está vinculado en la base de datos a toda la información y al historial de cargas del cargador: no puede cambiarse después sin perder ese historial. Ejemplo de convención: «CIUDAD-LUGAR-CARGADOR-01». Atención: el ChargeBoxID está limitado a 48 caracteres (límite de Gireve).

Una vez añadidos el token y el nombre del cargador, este apunta al tenant, al token y, por tanto, a la zona correspondiente. A veces hay que reiniciar el cargador para que se apliquen estos ajustes. Mientras el cargador no aparezca en el panel, o bien la URL está mal formada o bien el cargador está desconectado: consulte los registros.

Caducidad del token

CHARGER-01 debe ponerse en servicio y conectarse con el token creado antes de que este caduque; de lo contrario, se rechazará el BootNotification de OCPP. Una vez que el backend haya aceptado el cargador por primera vez, el token se guarda en la base de datos: incluso tras la caducidad, el cargador puede reiniciarse sin problema.

Recomendamos conservar los tokens, incluso los caducados: para otras puestas en servicio, basta con ampliar su fecha de validez. En cambio, puede eliminar los tokens no utilizados, lo que evita errores.

Aconsejamos supervisar los registros de ChargeAngels durante la puesta en servicio y consultarlos con regularidad.

Algunos cargadores necesitan el certificado raíz de nuestro servidor: ISRG Root X1 (Let’s Encrypt). Podemos facilitarlo bajo petición, pero también puede obtenerlo desde una línea de comandos de Linux o macOS con el siguiente comando:

curl https://letsencrypt.org/certs/isrgrootx1.pem

Copie el certificado que aparece en la respuesta (ISRG Root X1), péguelo en un archivo de texto y guárdelo como «ISRG Root X1.crt». Consérvelo localmente y en el cargador: al reiniciarse, el cargador utilizará este certificado y la URL WSS para conectarse al backend.

Este certificado se utiliza en OCPP con el perfil de seguridad 2 y el certificado del lado del servidor.

Una vez conectado el cargador al backend, puede modificar a distancia todos los parámetros OCPP. Algunos parámetros están normalizados en la especificación OCPP; otros son opcionales o incluso personalizados.

Lista de parámetros que conviene comprobar, según sus necesidades:

Algunos cargadores tienen un campo «CSMS URL» y «ChargeBoxID»: permite cambiar a distancia la URL del backend o el nombre del cargador, sin acceder a la configuración del cargador in situ.

Puede exportar todos los parámetros OCPP para compararlos después con los de otros cargadores. Algunas claves son de solo lectura.

Lo primero que hay que vigilar durante la puesta en servicio es la estabilidad de los WebSockets. La apertura de un WebSocket depende únicamente del cargador, no del CSMS.

Los registros están disponibles en la sección «Registro» del CSMS, donde puede filtrar por cargador, gravedad y acción. Son útiles dos familias de registros: los de WebSocket (conexión) y los de OCPP (mensajes intercambiados), detallados en las dos preguntas siguientes.

Si los WebSockets no son estables (aperturas y cierres no deseados), el cargador no puede arrancar correctamente por OCPP y quedará en un estado incierto.

En la sección «Registro», filtre las acciones WsServerConnectionOpen y WsServerConnectionClose.

• WsServerConnectionClose indica que el socket se cerró por parte del cargador (por iniciativa del cargador), por ejemplo: Close > WS Connection ID 'FsRi9' closed with code '1000', reason: 'Normal closure'.
• El CSMS no dispone de más información sobre el motivo de esta desconexión. Lo más frecuente es que se deba a un corte de red (los momentos de cierre y apertura son entonces los mismos para todos los cargadores) o a un corte de corriente.
• Puede vigilar el número de eventos WsServerConnectionClose: no debería haber más que unos pocos al día.

El CSMS envía un «ping» al cargador cada 60 segundos; si fallan 2 pings, cerramos el WebSocket. El cargador también envía un ping a nuestro servidor cada 30 segundos. La frecuencia de los pings puede ajustarse con el parámetro OCPP WebSocketPingInterval.

En la sección «Registro» puede filtrar por su cargador y por algunas acciones sencillas, por ejemplo: OcppBootNotification, OcppStatusNotification, OcppStartTransaction, OcppStopTransaction, OcppMeterValues. Los registros se leen de abajo arriba (el más reciente es la primera línea).

Existen cuatro niveles de gravedad, como en cualquier sistema informático:

• ERROR: crítico, nunca debe aparecer;
• WARNING: grave, pero sin consecuencias para el funcionamiento;
• INFO: información legible (textual);
• DEBUG: información de depuración, con las solicitudes y respuestas JSON.

En DEBUG, el detalle de los mensajes incluye el sentido de las solicitudes, con la siguiente convención:

• << = solicitud / respuesta del cargador al backend;
• >> = solicitud / respuesta del backend al cargador.

La misma convención se utiliza para el servidor JSON, OCPI, OICP, Batch o las API externas (con el backend a la derecha).

Los registros correspondientes a los comandos OCPP JSON también pueden leerse a un nivel aún más bajo, observando los mensajes WebSocket yuxtapuestos: WsClientMessage para la solicitud y WsServerMessage para la respuesta, con un identificador único (UID) para cada mensaje en el lado del CSMS y del cargador. Por ejemplo:

Message > Send WS Message Request: '[2,"f3f0e8b8-59a2-4f4c-816a-fce3b059f0a0","ClearChargingProfile",{"connectorId":1}]'

Message > Received WS Message: '[3,"f3f0e8b8-59a2-4f4c-816a-fce3b059f0a0",{"status":"Unknown"}]'

A veces se necesita este formato para comunicarse con los fabricantes de cargadores durante la depuración.

ChargeAngels dispone de una base de usuarios común por Tenant. Los usuarios tienen 3 niveles de permisos (roles):

• Administrador: todos los derechos sobre el Tenant;
• Estándar: derechos de los clientes finales que cargan vehículos eléctricos;
• Administrador de emplazamiento: un usuario «Estándar» con derechos de administración sobre uno o varios emplazamientos.

El detalle de los permisos por rol se describe en la documentación de integración, disponible bajo petición.

También existe un cuarto rol, «Demo», para la visualización pública anonimizada. Además hay un rol específico para la comunicación entre servidores (API): puede activarse en un usuario genérico, el «usuario técnico», que no puede utilizarse para iniciar sesión desde el frontend (aplicación web o móvil).

Las tres preguntas siguientes detallan las reglas generales, la asignación a emplazamientos y los estados de la cuenta.

Los nuevos usuarios pueden crear su cuenta:

• a través de la interfaz web, directamente en la página https://<subdominio>.charge-angels.com/auth/register;
• a través de la aplicación móvil, tras escanear el código QR de la organización para los clientes «SaaS», o directamente al abrir la aplicación para los clientes «Full Cloud».

En ambos casos deben aceptar el «Acuerdo de licencia de usuario final» (EULA), tal como lo define el RGPD (Reglamento General de Protección de Datos).

• La dirección de correo electrónico es la clave única de un usuario en la base de datos.
• Por razones de seguridad, las contraseñas se almacenan cifradas en la base de datos: no son visibles en texto claro, ni siquiera para los administradores.
• Un usuario que introduce 3 veces una contraseña incorrecta queda bloqueado; solo un administrador puede desbloquear la cuenta previa solicitud.
• Un usuario que olvida su contraseña puede solicitar su renovación automática por correo electrónico, desde la aplicación web (https://<subdominio>.charge-angels.com/auth/reset-password) o desde la aplicación móvil («¿Ha olvidado su contraseña?»).
• Solo un administrador puede elevar los permisos de un usuario «Basic» a «Administrator» o a «Basic / Site Administrator». Del mismo modo, un administrador de emplazamiento puede designar a otro administrador de emplazamiento en los emplazamientos que tiene asignados.

Como la base de usuarios es común al Tenant, el administrador puede elegir la estrategia de asignación de usuarios a los emplazamientos: o bien la opción «Asignar automáticamente los nuevos usuarios a este emplazamiento» está activada en todos los emplazamientos, o bien está desactivada.

1. Opción desactivada: el nuevo usuario no ve ningún cargador tras crear su cuenta. El administrador (o administrador de emplazamiento) debe asignarlo manualmente. El usuario podrá entonces ver todos los puntos de recarga del emplazamiento e iniciar una sesión de carga.
2. Opción activada: el nuevo usuario se asigna a todos los emplazamientos donde la opción está activa; puede ver todos los puntos de recarga de esos emplazamientos e iniciar una sesión de carga. El administrador (o administrador de emplazamiento) debe entonces desasignar a los usuarios que no deban ver los emplazamientos en cuestión.

Notas:

• Todos los usuarios «Administrator» se asignan por defecto a todos los emplazamientos creados en el Tenant.
• Un administrador puede crear un usuario manualmente con una contraseña de su elección. En ese caso, también debe asignar manualmente al usuario a los emplazamientos sobre los que tendrá derechos.
• La opción «Este emplazamiento es público» solo afecta al escenario de roaming (Gireve / Hubject).

También puede activar o desactivar, para todo el Tenant, la estrategia de creación de nuevas cuentas de usuario, desde la sección «Ajustes técnicos» / «Usuarios»:

• si está activada: todos los nuevos usuarios pueden crear su cuenta automáticamente;
• si está desactivada: se le envía una alerta push y un correo electrónico para que decida si activa o no la cuenta. Debe entonces comprobar la asignación automática en los emplazamientos o realizarla manualmente, según la estrategia definida anteriormente.

Si un cliente decide crear varias cuentas de cliente en un mismo Tenant, es responsable de gestionar correctamente a todos sus usuarios (antiguos y nuevos).

Una cuenta de usuario puede encontrarse en varios estados:

• Activa: habilitada, disfruta de todas las funciones del sitio;
• Suspendida: cuenta desactivada por un administrador, puede reactivarse más tarde;
• Inactiva: cuenta sin uso durante más de 6 meses (sin inicio de sesión en la plataforma);
• Bloqueada: bloqueo automático tras tres intentos con contraseña incorrecta;
• Pendiente: a la espera de que un administrador valide la cuenta.

Un mecanismo automático comprueba y desactiva las cuentas de usuario inactivas de la plataforma ChargeAngels, de conformidad con el RGPD europeo.

Cómo funciona

La tarea se ejecuta cada lunes a medianoche (Europe/Paris). Solo afecta a los usuarios activos con el rol Basic (se excluyen las cuentas técnicas). El proceso tiene dos etapas:

1. Aviso (tras 6 meses de inactividad): los usuarios que no han iniciado sesión durante 6 meses reciben una notificación de aviso, que les da tiempo para volver a iniciar sesión y evitar la desactivación.
2. Desactivación (tras 7 meses de inactividad): si un mes después del aviso el usuario sigue sin iniciar sesión, la cuenta pasa automáticamente al estado Inactiva y se envía una notificación de cambio de estado.

Criterios comprobados: fecha del último inicio de sesión, fecha de aceptación de las condiciones (EULA), fecha de la última transacción de carga. Configuración actual: umbral de inactividad de 6 meses, ejecución cada lunes a las 00:00.

Un cargador puede ser totalmente abierto o muy seguro según los ajustes de ChargeAngels (Organización / Zonas), pero sobre todo según los ajustes del propio cargador (y de su modelo).

Cuando el control de acceso está desactivado en ChargeAngels, sean cuales sean los ajustes del cargador, ChargeAngels acepta todos los inicios de transacción de carga solicitados por el cargador. En ese caso es imposible bloquear a usuarios concretos o facturar.

Cuando el control de acceso está activado, el comportamiento depende de los ajustes del cargador: FreeVending, RFID, Autocharge o Plug&Charge. ChargeAngels puede gestionar un número ilimitado de tokens de tipo RFID, eMAID o dirección MAC, de forma automática, manual o mediante importación CSV.

• Gireve define un token como una cadena de 4 a 7 bytes, es decir, de 8 a 14 caracteres hexadecimales. Recomendamos respetar esta regla para que el roaming funcione correctamente. Solo se recomiendan tarjetas NFC/RFID de tipo MIFARE.
• Cuando un nuevo usuario crea una cuenta a través de la interfaz web (https://<subdominio>.charge-angels.com/auth/register) o de la aplicación móvil, se crea automáticamente una tarjeta virtual de 4 bytes y se asigna a ese usuario.
• Los tokens pueden crearse manualmente, uno a uno, o mediante importación CSV. Si se crea un token manualmente, el administrador debe asignarlo a un usuario.
• Un usuario puede tener un número ilimitado de tokens, entre ellos uno por defecto: es el que se propone automáticamente al iniciar una sesión de carga.

Información solicitada al crear un token

• el Badge ID o UID: el código grabado en el interior de la tarjeta RFID física;
• el número de tarjeta: el número visible grabado en la tarjeta RFID;
• la descripción (texto libre);
• el usuario vinculado a la tarjeta;
• el estado de la tarjeta;
• tarjeta por defecto: la que se propone automáticamente al iniciar una sesión de carga;
• permitir que esta tarjeta inicie varias cargas simultáneamente en cargadores distintos.

¿Cómo añado una tarjeta física (o un eMAID virtual) si no conozco su UID?

1. En la sección «Registros», añada un filtro por su cargador y por la gravedad ERROR.
2. En el filtro «Acción», busque la acción OcppAuthorize.
3. Acerque su tarjeta al cargador.
4. Aparece un registro ERROR con el UID (idTag) en los detalles del error.

Guarde este UID para usarlo más tarde o vaya al menú «Tarjeta» para añadirlo. También puede exportar todas las tarjetas con el botón de exportación.

Importación CSV

También es posible importar en formato CSV, con la coma como separador: cree un archivo XLS con las propiedades obligatorias id y visualID y las propiedades opcionales description, limitKwh, email, firstName, name, siteIDs y guárdelo como CSV. Haga una prueba con unas pocas tarjetas antes de importar una lista de miles.

Los fabricantes de cargadores suelen ofrecer soluciones de terminal de pago (TPV) como estas:

Principio: el TPV se conecta al cargador a través del puerto serie (MDB).

1. El conductor acerca su tarjeta bancaria al terminal de pago integrado en el cargador (Nayax, Ingenico o Payter).
2. El back office del servicio de pago bancario comprueba y autoriza la transacción de carga.
3. El terminal de pago envía al cargador un token predefinido para solicitar una autorización, mediante el protocolo MDB.
4. El cargador envía al backend de supervisión una solicitud de autorización con el token e inicia la carga.

Si todo está configurado en el lado del TPV (nube del fabricante), al acercar una tarjeta bancaria el cargador envía un StartTransaction OCPP que contiene un idTag. Este tag debe introducirse en los parámetros OCPP del cargador: no es un parámetro OCPP estándar y varía según la marca del cargador.

Este tag también debe registrarse como tarjeta virtual y asociarse a un usuario virtual (administrador), para que la supervisión acepte la solicitud de carga. Este usuario debe asignarse además a los emplazamientos correspondientes.

Requisito previo: la configuración de tarifas y la cuenta bancaria de Stripe. Puede configurar las tarifas de forma independiente, sin activar la facturación.

Para flotas cautivas o de empresa, puede facilitar directamente a sus usuarios:

1. la URL de acceso a la plataforma web: https://<subdominio>.charge-angels.com/auth/login;
2. los códigos QR de la aplicación móvil:

3. el código QR de su «Organización», que se solicita al crear una cuenta. Para encontrarlo, vaya al menú «Ajustes técnicos» y después a «Mostrar código QR». Guárdelo como archivo JPG: lo necesitará para elaborar sus procedimientos de usuario. Bajo petición se dispone de una plantilla de cartel para personalizar y pegar en sus cargadores.
4. un código QR por conector: también puede generar uno por conector, para iniciar una carga sin tener que buscar el cargador en la aplicación móvil. La lista de códigos QR puede exportarse para cada emplazamiento desde el menú Organización / Emplazamiento.

Atención: los códigos QR codifican la URL completa de los cargadores (ChargeBoxID e identificador del conector). Al cambiar el nombre de un cargador cambia su código QR: deberá sustituirlo.

Lo primero que hay que vigilar durante la puesta en servicio es la estabilidad de los WebSockets. La apertura de un WebSocket depende únicamente del cargador, no del CSMS. Si los WebSockets no son estables (aperturas y cierres no deseados), el cargador no puede arrancar correctamente por OCPP y quedará en un estado incierto.

Si un cargador no aparece en la interfaz web (panel), pueden existir muchas causas:

• el cargador no tiene alimentación (corte) o está en un estado indeterminado;
• el cargador no está, o ya no está, conectado a la red;
• el cargador pasa por una red protegida (cortafuegos de salida);
• el cargador pasa por una red local: router LAN o WAN;
• la conexión a internet es insuficiente;
• el firmware del cargador no está actualizado.

El orden de la depuración

1. Lado del cargador

• Compruebe las conexiones físicas: cables y routers.
• Apague y vuelva a encender (5 min) el cargador y los dispositivos externos de comunicación (routers).
• Si es posible, consulte los registros del lado del cargador desde la administración del fabricante.

Las conexiones RJ45 suelen ser defectuosas o estar mal cableadas. La mejor prueba es conectar un ordenador en lugar del cargador, con los mismos ajustes de red (DHCP automático o IP fija).

• En un cargador con módem 4G, compruebe que el APN y el usuario / contraseña son correctos y, después, el estado de la señal 4G, que suele consultarse en el cargador o en el router 4G externo.
• Actualice el firmware con la última versión oficial disponible en el sitio web del fabricante.
• Pruebe primero a cambiar el token a WS (sin protección, puerto 80).
• Después, si funciona, vuelva a WSS (protegido, puerto 443).

2. Lado de la supervisión, si todo está bien en el lado del cargador

• Consulte los registros del lado de la supervisión (preferiblemente en la interfaz web), como se describe en las preguntas sobre registros. Si no se recibe ninguna solicitud de apertura de WebSocket, el cargador no se comunica correctamente, sobre todo si ya hay otros cargadores conectados en el mismo espacio en la nube.
• Compruebe también el estado del token (validez y revocación) desde el menú «Cargador / Conectar un nuevo cargador».
• Compruebe si el cargador responde a los comandos OCPP (Reset, StartTransaction…) mientras consulta los registros del backend.

Cuándo y cómo contactarnos

Si ningún cargador responde ya y la red no es la causa, puede haber un error en el lado de la supervisión. En ese caso, contáctenos (categoría «Solicitud de soporte») con la descripción exacta del problema: fecha del incidente, reproducibilidad, nombres de los cargadores afectados, pruebas realizadas, etc.

Si el problema parece estar relacionado con los cargadores, con un cargador concreto o aparece tras una actualización de firmware, recopile los registros del lado del cargador y de la supervisión y abra un ticket con el fabricante.

La depuración es un servicio facturable en ChargeAngels, salvo en caso de error demostrado y documentado en el lado de la supervisión. Solo los cargadores certificados por ChargeAngels están cubiertos por nuestro contrato de soporte. En la mayoría de los casos, los errores se deben a un fallo del cargador, a un problema de red o a una manipulación incorrecta por parte de los usuarios.

Buenas prácticas

• Lo mejor es tener un cargador «de referencia» cerca de sus instalaciones, para depurar y reproducir fallos o errores. Una actualización de firmware es una operación arriesgada que a veces puede inutilizar un cargador de forma definitiva. Sin un cargador de pruebas dedicado, realice las pruebas en un cargador aislado y poco utilizado.
• Al poner en servicio cargadores que no conoce, realice una prueba de puesta en servicio antes de la instalación definitiva.
• En los cargadores 4G, analice previamente la cobertura de la red 4G (existen dispositivos para ello).
• Para las pruebas funcionales existen simuladores de carga para cargadores AC (Tipo 2) de Metrel. También recomendamos probar con un vehículo eléctrico real.

Leer registros JSON o de cualquier otro formato requiere conocimientos informáticos. Los mensajes OCPP entre los cargadores y nuestro servidor están normalizados en la especificación OCPP, que recomendamos leer primero: openchargealliance.org/my-oca/ocpp. También ofrecemos formación sobre este protocolo, así como formación operativa (lectura de registros y depuración), además de la habilitación IRVE P2/P3.

Tres familias de problemas son las más habituales. Se detallan en las preguntas siguientes:

• problemas de conexión del cargador al backend;
• problemas de cierre de sesión: no se recibe ningún StopTransaction;
• problemas de cierre de sesión: se recibe StopTransaction, pero con un estado incorrecto.

Síntoma: el cargador no aparece en el panel del CSMS de ChargeAngels aunque la red funciona, o se reciben solicitudes WS/WSS pero con error.

Explicaciones: la apertura de un WebSocket depende únicamente del cargador, no del CSMS. Si no llega ninguna solicitud WS o WSS al lado de la supervisión y la red funciona (el cargador puede llegar a internet, por ejemplo al DNS de Google), lo más probable es que la URL configurada en el cargador sea errónea, incorrecta o incompleta. Cada marca o modelo tiene sus particularidades y a veces requiere una herramienta específica para configurar esta URL: aplicación web, aplicación móvil, aplicación Windows dedicada, etc.

Soluciones: recomendamos leer primero toda esta FAQ, en particular las preguntas sobre los registros de WebSocket. Después de la red, la configuración de la URL es la causa del problema en el 99 % de los casos: conviene, por tanto, aplicar un método secuencial e iterativo.

Una URL mal formada suele tener varios orígenes:

1. Algunos cargadores solo admiten WS: recomendamos empezar por ahí (quien puede lo más, puede lo menos).
2. Algunos cargadores solo admiten WSS tras la última actualización de firmware.
3. Algunos cargadores requieren una primera conexión en WS y después el paso a WSS (Schneider, según el firmware).
4. Algunos cargadores admiten WSS, pero solo con TLS 1.2 y no con TLS 1.3.
5. Algunos cargadores exigen un perfil de seguridad concreto: no tenemos un perfil específico, pero se acepta el nivel 2 con cualquier contraseña.
6. Algunos cargadores exigen el certificado raíz del CSMS (certificado Root CA).
7. Algunos cargadores requieren el puerto 80 o 443: en ese caso, añádalo a la URL.
8. Algunos cargadores separan el host, el puerto, la ruta y el ChargeBoxID, y después concatenan la URL WSS para realizar las llamadas salientes.
9. Algunos cargadores no ofrecen un ChargeBoxID: en ese caso hay que añadirlo al final de la URL; de lo contrario, la llamada será rechazada por nuestra parte (este campo es la clave primaria de nuestra base de datos).
10. Algunos cargadores añaden una barra al final de la URL y otros no (por nuestra parte no hay ninguna limitación al respecto).
11. Algunos cargadores truncan la URL por ser demasiado larga (cada vez menos frecuente).

Síntoma: en el menú Sesiones / Historial aparecen sesiones fantasma y es imposible detener una sesión de carga en curso. Registro de error: Remote Stop Transaction has been rejected in 1.52s, reason 'Rejected'.

Secuencia en los registros:

EVSE <- CSMS : remoteStartTransaction with transactionID
EVSE -> CSMS : accepted
EVSE -> CSMS : StartTransaction with tagID
EVSE <- CSMS : accepted
...
EVSE <- CSMS : remoteStopTransaction with the same transactionID
EVSE -> CSMS : rejected   <- error message: you are blocked here
EVSE -> CSMS : StopTransaction with same tagID
EVSE <- CSMS : accepted

Explicaciones: la sesión sigue pendiente en el CSMS, sea cual sea el estado real del cargador, ya que no conocemos su estado (no se ha recibido ningún StopTransaction). Reiniciar el cargador no tiene, por tanto, ningún efecto en la sesión pendiente mientras el CSMS no reciba el StopTransaction del cargador con el identificador de transacción correcto. Iniciar otra sesión genera otro TransactionID, es decir, otra entrada en nuestra base de datos.

Solución: solo tiene una opción: pulsar el botón «Force Stop» disponible en cada sesión en curso, desde la interfaz de usuario. Esto fuerza la parada en el lado del CSMS.

Síntoma: en el menú Sesiones / Historial aparecen sesiones fantasma o un estado anormal del cargador (distinto de CHARGING / SUSPENDED / FAULTED / RESERVED).

Caso normal cuando se recibe el StopTransaction

• StopTransaction + AVAILABLE (FINISHING opcional): la transacción se detiene y se finaliza.
• FINISHING no es obligatorio: solo se comprueban AVAILABLE o PREPARING (FINISHING se utiliza para el tiempo de aparcamiento).
• SUSPENDED, FAULTED y RESERVED no influyen en el proceso.

Casos «anormales» que se gestionan automáticamente

1. Se recibe StopTransaction, pero ningún StatusNotification tras X minutos: «Force Stop» automático por una tarea programada del CSMS (retardo de 30 minutos).
2. Se recibe un nuevo StartTransaction sin StopTransaction previo: sin consumo, la transacción se elimina; con consumo, se aplica un «Force Stop» automático.
3. StatusNotification AVAILABLE sin un StopTransaction justo antes: la transacción sigue activa (sin acción inmediata). Si el Stop llega después, el cierre es normal; si no llega, la tarea programada aplica un «Force Stop» (30 minutos).
4. StatusNotification AVAILABLE antes del StopTransaction: el sistema crea artificialmente un StatusNotification a partir del estado actual del conector (Available) y de la marca de tiempo del StopTransaction, para calcular correctamente el tiempo de inactividad adicional.

Ejemplo de una cronología real:

T1: Available received   -> no action (no StopTransaction)
T2: Stop received        -> detects connector = Available
                          -> creates a synthetic StatusNotification
                          -> finalises the transaction

Solución: en todos los casos distintos de los descritos arriba, puede detener la transacción manualmente desde las sesiones «en curso», con el botón «Force Stop».