FAQ

Tre prerequisiti per collegare una colonnina:

• la colonnina dispone di una connessione internet stabile (meglio via cavo);
• la colonnina dispone di uno strumento di amministrazione a cui si può accedere per cambiare l’URL del CSMS;
• la colonnina ha il firmware aggiornato prima del primo collegamento al CSMS.

La colonnina può essere aggiornata da remoto solo dopo il primo collegamento. Attenzione: un aggiornamento del firmware può causare malfunzionamenti o regressioni. Consigliamo di testare sempre prima il firmware su una colonnina di prova.

Se la colonnina usa una rete locale, il team IT deve consentire il traffico in uscita dalle colonnine verso il dominio charge-angels.com (porta TCP 443) e disattivare il firewall in uscita, oppure inserire in whitelist gli indirizzi IP del nostro server (da richiedere a un amministratore).

La rete dovrebbe essere via cavo ogni volta che è possibile, per evitare limiti di distanza e di larghezza di banda. La latenza di rete tollerata deve essere inferiore a 500 ms.

Le colonnine possono usare diverse modalità di comunicazione: LAN (Ethernet) o WAN (Wi-Fi). Nella maggior parte dei casi, la colonnina dialoga per impostazione predefinita con il DHCP (Dynamic Host Configuration Protocol) della rete locale e ottiene automaticamente un indirizzo IP; altrimenti occorre impostare un indirizzo IP manuale nella colonnina. Il router si collega a internet tramite il provider del cliente: ADSL, fibra o GSM.

Se preferisce una rete 4G, serviranno SIM M2M (dedicate all’IoT), preferibilmente con roaming. Per il traffico dati, conti 200 kB per punto di ricarica.

• La configurazione dell’APN dipende dall’operatore.
• Sono preferibili le SIM con roaming abilitato: la rete migliore viene scelta in tempo reale. Il roaming può essere limitato alla Francia o mondiale, in base alle esigenze.
• In generale, preveda un piano dati da 200 MB per punto di ricarica per un uso intensivo.
• Una VPN non è utile se la colonnina comunica tramite WSS.

ChargeAngels utilizza una connessione WebSocket sicura (WSS) tra la colonnina e il backend. Supportiamo solo TLS 1.3 (TLS 1.2 è deprecato). ChargeAngels supporta i certificati SSL RSA ed ECDSA. Usiamo Node.js con la libreria uWebSockets.js per gestire i WebSocket.

• Nato nel 2011, WebSocket (WS) è un protocollo di rete a livello applicativo «bidirezionale, asincrono e full-duplex» tra client e server, standardizzato dall’IETF nella RFC 6455 e dal W3C.
• WebSocket apre una connessione permanente full-duplex tra client e server: il server può inviare dati a un client di propria iniziativa, a differenza del protocollo HTTP.
• WebSocket Security (WSS) utilizza il livello di trasporto TLS, come HTTPS, per cifrare le comunicazioni: è quindi più sicuro.

Come descritto nella specifica «OCPP 1.6 security whitepaper edition 3», supportiamo:

• Profilo di sicurezza 1: WS con autenticazione di base (utente / password o chiave di autorizzazione, a sua scelta);
• Profilo di sicurezza 2: autenticazione di base o WSS TLS con il certificato radice del server (ISRG Root X1);
• Profilo di sicurezza 3: WSS TLS sia sul punto di ricarica sia sul lato server (testato, ma non ufficialmente in produzione).

Test OCA: i casi di test TC_085_CSMS (autenticazione di base, combinazione utente / password valida), TC_086_CSMS (TLS, certificato server valido) e TC_087_CSMS (TLS, certificato client valido) sono superati con lo strumento di test dell’Open Charge Alliance.

Chiave di autorizzazione (Authorization Key): minimo 16 caratteri e codifica esadecimale, tra 20 e 40 caratteri.

Consigliamo di testare sempre il primo collegamento della colonnina con il profilo di sicurezza 1 (WS), poi con il 2 (WS e WSS), poi con il 3 (WSS).

Un Tenant è uno sotto-spazio del dominio principale, ad esempio cpo1.charge-angels.com.

• Se ha scelto la soluzione SaaS, organizza il suo Tenant nella scheda «Organizzazione» del CSMS.
• Se ha scelto la soluzione Full Cloud, ha accesso al «Master Tenant» e può creare tutti i «Cloud Tenant» necessari.

Il Tenant dispone di un database utenti comune, la cui chiave centrale è l’indirizzo e-mail. Può essere suddiviso in più livelli gerarchici: aziende, siti e zone.

• I siti possono essere aree geografiche diverse di uno stesso cliente (ad esempio depositi di autobus).
• I siti possono anche essere sotto-clienti diversi che condividono un database utenti comune.
• Una zona è un gruppo di colonnine; definisce la topologia fisica del luogo: una zona può corrispondere a un quadro generale di bassa tensione (TGBT) o a un abbonamento di potenza (ad esempio una fornitura da 220 kVA).
• Lo SmartCharging è gestito per zona (potenza massima dichiarata al quadro generale).

Un «token» è un URL di connessione WSS che la colonnina usa per collegarsi ai server del CSMS ChargeAngels. Il token è unico e specifico di una zona.

Una volta creata la sua organizzazione, può creare uno o più token di connessione al backend dal menu «Colonnina», poi «Collega una colonnina»: lo crei, aggiunga un titolo, una data di validità e una zona, quindi salvi.

Può copiare il token per un uso immediato o successivo (ad esempio «OCPP 1.6 JSON»). Può essere trasmesso ai team che installano le colonnine sul campo. Per motivi di cybersicurezza, ChargeAngels ha scelto di creare token dinamici con una data di validità, a differenza di altri CSMS.

Il token (o URL) è composto da 4 parti

• il prefisso: HTTP / HTTPS / WS o WSS;
• «OCPP16» o «OCPP201», a seconda della versione di OCPP;
• la prima parte del token è l’identificativo univoco del tenant;
• la seconda parte è l’identificativo del token stesso, legato a una zona;
• l’ultima parte è il nome della colonnina: il ChargeBoxID.

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

Una volta copiato il token nell’amministrazione della colonnina, questa apre un socket verso i server del CSMS. La colonnina (qui CHARGER-01) compare automaticamente nella dashboard, senza alcuna azione lato backend. Quando la colonnina è visibile, ne modifichi gli attributi (potenza massima, posizione, connettori, ecc.).

Nell’amministrazione di alcune colonnine, l’URL e il ChargeBoxID sono suddivisi in più campi: «Host», «Port», «Path» e «ChargeBoxID» (il nome della colonnina). A volte occorre verificare l’URL così composto (attenzione alle diverse barre).

Assegnare un nome alle colonnine

Consigliamo di definire una convenzione di denominazione per le colonnine. Il ChargeBoxID è legato nel database a tutte le informazioni e allo storico delle ricariche della colonnina: non può essere modificato in seguito senza perdere questo storico. Esempio di convenzione: «CITTÀ-LUOGO-COLONNINA-01». Attenzione: il ChargeBoxID è limitato a 48 caratteri (limite di Gireve).

Una volta aggiunti il token e il nome della colonnina, questa punta al tenant, al token e quindi alla zona interessata. A volte occorre riavviare la colonnina perché queste impostazioni vengano applicate. Finché la colonnina non compare nella dashboard, o l’URL è errato o la colonnina è offline: controlli i log.

Scadenza del token

CHARGER-01 deve essere messa in servizio e collegata con il token creato prima che il token scada, altrimenti il BootNotification OCPP verrà rifiutato. Una volta che la colonnina è stata accettata dal backend per la prima volta, il token viene memorizzato nel database: anche dopo la scadenza, la colonnina può riavviarsi senza problemi.

Consigliamo di conservare i token, anche quelli scaduti: per altre messe in servizio basta prorogarne la data di validità. Può invece eliminare i token inutilizzati, il che evita errori.

Consigliamo di monitorare i log di ChargeAngels durante la messa in servizio e di controllarli regolarmente.

Alcune colonnine richiedono il certificato radice del nostro server: ISRG Root X1 (Let’s Encrypt). Possiamo fornirlo su richiesta, ma può anche ottenerlo da un terminale Linux o macOS con il comando seguente:

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

Copi il certificato mostrato nella risposta (ISRG Root X1), lo incolli in un file di testo e lo salvi come «ISRG Root X1.crt». Lo conservi in locale e nella colonnina: al riavvio, la colonnina userà questo certificato e l’URL WSS per collegarsi al backend.

Questo certificato è usato in OCPP con il profilo di sicurezza 2 e il certificato lato server.

Una volta collegata la colonnina al backend, può modificare da remoto tutti i parametri OCPP. Alcuni parametri sono standardizzati nella specifica OCPP, altri sono opzionali o addirittura personalizzati.

Elenco dei parametri da verificare, in base alle sue esigenze:

Alcune colonnine hanno un campo «CSMS URL» e «ChargeBoxID»: permette di modificare da remoto l’URL del backend o il nome della colonnina, senza accedere alla configurazione della colonnina in loco.

Può esportare tutti i parametri OCPP per confrontarli in seguito con quelli di altre colonnine. Alcune chiavi sono di sola lettura.

La prima cosa da monitorare durante la messa in servizio è la stabilità dei WebSocket. L’apertura di un WebSocket è esclusiva iniziativa della colonnina, non del CSMS.

I log sono disponibili nella sezione «Log» del CSMS, dove si può filtrare per colonnina, gravità e azione. Sono utili due famiglie di log: quelli WebSocket (connessione) e quelli OCPP (messaggi scambiati), descritti nelle due domande successive.

Se i WebSocket non sono stabili (aperture e chiusure indesiderate), la colonnina non riesce ad avviarsi correttamente tramite OCPP e si troverà in uno stato incerto.

Nella sezione «Log», filtri le azioni WsServerConnectionOpen e WsServerConnectionClose.

• WsServerConnectionClose indica che il socket è stato chiuso dal lato della colonnina (per iniziativa della colonnina), ad esempio: Close > WS Connection ID 'FsRi9' closed with code '1000', reason: 'Normal closure'.
• Il CSMS non ha ulteriori informazioni sul motivo di questa disconnessione. Il più delle volte è dovuta a un’interruzione di rete (gli orari di chiusura e apertura sono allora gli stessi per tutte le colonnine) o a un’interruzione di corrente.
• Può monitorare il numero di eventi WsServerConnectionClose: non dovrebbero essere più di qualcuno al giorno.

Il CSMS invia un «ping» alla colonnina ogni 60 secondi; se 2 ping falliscono, chiudiamo il WebSocket. Anche la colonnina invia un ping al nostro server ogni 30 secondi. La frequenza dei ping può essere regolata con il parametro OCPP WebSocketPingInterval.

Nella sezione «Log» può filtrare per la sua colonnina e per alcune azioni semplici, ad esempio: OcppBootNotification, OcppStatusNotification, OcppStartTransaction, OcppStopTransaction, OcppMeterValues. I log si leggono dal basso verso l’alto (il più recente è la prima riga).

Esistono quattro livelli di gravità, come in qualsiasi sistema informatico:

• ERROR: critico, non deve mai comparire;
• WARNING: grave ma senza conseguenze per il funzionamento;
• INFO: informazioni leggibili (testuali);
• DEBUG: informazioni di debug, con le richieste e le risposte JSON.

In DEBUG, il dettaglio dei messaggi include la direzione delle richieste, con la seguente convenzione:

• << = richiesta / risposta dalla colonnina al backend;
• >> = richiesta / risposta dal backend alla colonnina.

La stessa convenzione è usata per il server JSON, OCPI, OICP, Batch o le API esterne (con il backend a destra).

I log corrispondenti ai comandi OCPP JSON possono essere letti anche a un livello ancora più basso, osservando i messaggi WebSocket affiancati: WsClientMessage per la richiesta e WsServerMessage per la risposta, con un identificativo univoco (UID) per ogni messaggio sul lato CSMS e sul lato colonnina. Ad esempio:

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 volte questo formato è necessario per comunicare con i produttori di colonnine durante il debug.

ChargeAngels dispone di un database utenti comune per Tenant. Gli utenti hanno 3 livelli di autorizzazione (ruoli):

• Amministratore: tutti i diritti sul Tenant;
• Standard: diritti per i clienti finali che ricaricano veicoli elettrici;
• Amministratore di sito: un utente «Standard» con diritti di amministrazione su uno o più siti.

Il dettaglio dei permessi per ruolo è descritto nella documentazione di integrazione, disponibile su richiesta.

È disponibile anche un quarto ruolo, «Demo», per la visualizzazione pubblica anonimizzata. Esiste inoltre un ruolo specifico per la comunicazione tra server (API): può essere attivato su un utente generico, l’«utente tecnico», che non può essere usato per accedere dal frontend (applicazione web o mobile).

Le tre domande successive illustrano le regole generali, l’assegnazione ai siti e gli stati dell’account.

I nuovi utenti possono creare il proprio account:

• tramite l’interfaccia web, direttamente alla pagina https://<sottodominio>.charge-angels.com/auth/register;
• tramite l’applicazione mobile, dopo aver scansionato il codice QR dell’organizzazione per i clienti «SaaS», oppure direttamente all’apertura dell’applicazione per i clienti «Full Cloud».

In entrambi i casi devono accettare il «Contratto di licenza con l’utente finale» (EULA), come definito dal GDPR (Regolamento generale sulla protezione dei dati).

• L’indirizzo e-mail è la chiave univoca di un utente nel database.
• Per motivi di sicurezza, le password sono cifrate nel database: non sono visibili in chiaro, nemmeno agli amministratori.
• Un utente che inserisce 3 volte una password errata viene bloccato; solo un amministratore può sbloccare l’account su richiesta.
• Un utente che dimentica la password può richiederne il rinnovo automatico via e-mail, dall’applicazione web (https://<sottodominio>.charge-angels.com/auth/reset-password) o dall’applicazione mobile («Password dimenticata?»).
• Solo un amministratore può elevare i permessi di un utente «Basic» ad «Administrator» o a «Basic / Site Administrator». Allo stesso modo, un amministratore di sito può designare un altro amministratore di sito sui siti che gli sono assegnati.

Poiché il database utenti è comune al Tenant, l’amministratore può scegliere la strategia di assegnazione degli utenti ai siti: o l’opzione «Assegna automaticamente i nuovi utenti a questo sito» è attiva su tutti i siti, oppure è disattivata.

1. Opzione disattivata: il nuovo utente non vede alcuna colonnina dopo aver creato l’account. L’amministratore (o l’amministratore di sito) deve assegnarlo manualmente. L’utente può allora vedere tutti i punti di ricarica del sito e avviare una sessione di ricarica.
2. Opzione attivata: il nuovo utente viene assegnato a tutti i siti in cui l’opzione è attiva; può vedere tutti i punti di ricarica di questi siti e avviare una sessione di ricarica. L’amministratore (o l’amministratore di sito) deve poi rimuovere gli utenti che non devono vedere i siti interessati.

Note:

• Tutti gli utenti «Administrator» sono assegnati per impostazione predefinita a tutti i siti creati nel Tenant.
• Un amministratore può creare manualmente un utente con una password a sua scelta. In tal caso deve anche assegnare manualmente l’utente ai siti su cui avrà dei diritti.
• L’opzione «Questo sito è pubblico» riguarda solo lo scenario di roaming (Gireve / Hubject).

Può inoltre attivare o disattivare, per l’intero Tenant, la strategia di creazione di nuovi account utente, dalla sezione «Impostazioni tecniche» / «Utenti»:

• se attivata: tutti i nuovi utenti possono creare il proprio account automaticamente;
• se disattivata: le vengono inviati un avviso push e un’e-mail per decidere se attivare o meno l’account. Deve poi verificare l’assegnazione automatica sui siti o effettuarla manualmente, in base alla strategia definita sopra.

Se un cliente decide di creare più account cliente sullo stesso Tenant, è sua responsabilità gestire correttamente tutti i propri utenti (vecchi e nuovi).

Un account utente può trovarsi in diversi stati:

• Attivo: abilitato, beneficia di tutte le funzioni del sito;
• Sospeso: account reso inattivo da un amministratore, può essere riattivato in seguito;
• Inattivo: account non utilizzato da più di 6 mesi (nessun accesso alla piattaforma);
• Bloccato: blocco automatico dopo tre tentativi con password errata;
• In attesa: in attesa della convalida dell’account da parte di un amministratore.

Un meccanismo automatico controlla e disattiva gli account utente inattivi sulla piattaforma ChargeAngels, in conformità con il GDPR europeo.

Come funziona

L’attività viene eseguita ogni lunedì a mezzanotte (Europe/Paris). Riguarda solo gli utenti attivi con il ruolo Basic (gli account tecnici sono esclusi). Il processo ha due fasi:

1. Avviso (dopo 6 mesi di inattività): gli utenti che non accedono da 6 mesi ricevono una notifica di avviso, che dà loro il tempo di accedere di nuovo ed evitare la disattivazione.
2. Disattivazione (dopo 7 mesi di inattività): se un mese dopo l’avviso l’utente non ha ancora effettuato l’accesso, l’account passa automaticamente allo stato Inattivo e viene inviata una notifica di cambio di stato.

Criteri verificati: data dell’ultimo accesso, data di accettazione dei termini (EULA), data dell’ultima transazione di ricarica. Configurazione attuale: soglia di inattività di 6 mesi, esecuzione ogni lunedì alle 00:00.

Una colonnina può essere completamente aperta o molto sicura in base alle impostazioni in ChargeAngels (Organizzazione / Zone), ma soprattutto in base alle impostazioni della colonnina stessa (e del suo modello).

Quando il controllo accessi è disattivato lato ChargeAngels, indipendentemente dalle impostazioni della colonnina, ChargeAngels accetta tutti gli avvii di transazione di ricarica richiesti dalla colonnina. In questo caso non è possibile bloccare utenti specifici né fatturare.

Quando il controllo accessi è attivato, il comportamento dipende dalle impostazioni della colonnina: FreeVending, RFID, Autocharge o Plug&Charge. ChargeAngels può gestire un numero illimitato di token di tipo RFID, eMAID o indirizzo MAC, in modo automatico, manuale o tramite importazione CSV.

• Gireve definisce un token come una stringa di 4-7 byte, cioè da 8 a 14 caratteri esadecimali. Consigliamo di rispettare questa regola affinché il roaming funzioni correttamente. Si consigliano solo badge NFC/RFID di tipo MIFARE.
• Quando un nuovo utente crea un account tramite l’interfaccia web (https://<sottodominio>.charge-angels.com/auth/register) o l’applicazione mobile, viene creato automaticamente un badge virtuale da 4 byte e assegnato a quell’utente.
• I token possono essere creati manualmente, uno alla volta, o tramite importazione CSV. Se un token viene creato manualmente, l’amministratore deve assegnarlo a un utente.
• Un utente può avere un numero illimitato di token, tra cui uno predefinito: è quello proposto automaticamente all’avvio di una sessione di ricarica.

Informazioni richieste alla creazione di un token

• il Badge ID o UID: il codice scritto all’interno del badge RFID fisico;
• il numero del badge: il numero visibile inciso sul badge RFID;
• la descrizione (testo libero);
• l’utente collegato al badge;
• lo stato del badge;
• badge predefinito: quello proposto automaticamente all’avvio di una sessione di ricarica;
• consentire a questo badge di avviare più ricariche contemporaneamente su colonnine diverse.

Come aggiungo un badge fisico (o un eMAID virtuale) se non conosco il suo UID?

1. Nella sezione «Log», aggiunga un filtro sulla sua colonnina e sulla gravità ERROR.
2. Nel filtro «Azione», cerchi l’azione OcppAuthorize.
3. Avvicini il badge alla colonnina.
4. Compare un log ERROR, con l’UID (idTag) nei dettagli dell’errore.

Conservi questo UID per un uso successivo oppure vada al menu «Badge» per aggiungerlo. Può anche esportare tutti i badge con il pulsante di esportazione.

Importazione CSV

È possibile anche un’importazione in formato CSV, con la virgola come separatore: crei un file XLS con le proprietà obbligatorie id e visualID e le proprietà facoltative description, limitKwh, email, firstName, name, siteIDs, poi lo salvi come CSV. Faccia una prova con pochi badge prima di importare un elenco di migliaia.

I produttori di colonnine offrono in genere soluzioni di terminale di pagamento (POS) come queste:

Principio: il POS è collegato alla colonnina tramite la porta seriale (MDB).

1. Il conducente avvicina la carta bancaria al terminale di pagamento integrato nella colonnina (Nayax, Ingenico o Payter).
2. Il back office del servizio di pagamento bancario verifica e autorizza la transazione di ricarica.
3. Il terminale di pagamento invia alla colonnina un token predefinito per richiedere un’autorizzazione, tramite il protocollo MDB.
4. La colonnina invia al backend di supervisione una richiesta di autorizzazione con il token e avvia la ricarica.

Se tutto è configurato lato POS (cloud del produttore), quando si avvicina una carta bancaria la colonnina invia uno StartTransaction OCPP contenente un idTag. Questo tag deve essere inserito nei parametri OCPP della colonnina: non è un parametro OCPP standard e varia da una marca all’altra.

Questo tag deve inoltre essere registrato come badge virtuale e associato a un utente virtuale (amministratore), affinché la supervisione accetti la richiesta di ricarica. Questo utente deve anche essere assegnato ai siti corrispondenti.

Prerequisito: la configurazione delle tariffe e il conto bancario Stripe. Può configurare le tariffe in modo indipendente, senza attivare la fatturazione.

Per flotte captive o aziendali, può fornire direttamente ai suoi utenti:

1. l’URL per accedere alla piattaforma web: https://<sottodominio>.charge-angels.com/auth/login;
2. i codici QR dell’applicazione mobile:

3. il codice QR della sua «Organizzazione», richiesto alla creazione di un account. Per trovarlo vada al menu «Impostazioni tecniche», poi «Mostra codice QR». Lo salvi come file JPG: le servirà per creare le procedure per gli utenti. Su richiesta è disponibile un modello di poster da personalizzare e applicare sulle sue colonnine.
4. un codice QR per connettore: può anche generarne uno per ogni connettore, per avviare una ricarica senza dover cercare la colonnina nell’applicazione mobile. L’elenco dei codici QR può essere esportato per ogni sito dal menu Organizzazione / Sito.

Attenzione: i codici QR codificano l’URL completo delle colonnine (ChargeBoxID e identificativo del connettore). Rinominare una colonnina ne cambia il codice QR: dovrà quindi sostituirlo.

La prima cosa da monitorare durante la messa in servizio è la stabilità dei WebSocket. L’apertura di un WebSocket è esclusiva iniziativa della colonnina, non del CSMS. Se i WebSocket non sono stabili (aperture e chiusure indesiderate), la colonnina non riesce ad avviarsi correttamente tramite OCPP e si troverà in uno stato incerto.

Se una colonnina non compare nell’interfaccia web (dashboard), le cause possono essere molte:

• la colonnina non è alimentata (interruzione) o si trova in uno stato indeterminato;
• la colonnina non è, o non è più, collegata alla rete;
• la colonnina passa attraverso una rete protetta (firewall in uscita);
• la colonnina passa attraverso una rete locale: router LAN o WAN;
• la connettività internet è insufficiente;
• il firmware della colonnina non è aggiornato.

L’ordine del debug

1. Lato colonnina

• Verifichi i collegamenti fisici: cavi e router.
• Spenga e riaccenda (5 min) la colonnina e i dispositivi di comunicazione esterni (router).
• Se possibile, controlli i log lato colonnina dall’amministrazione del produttore.

I collegamenti RJ45 sono spesso difettosi o cablati male. Il test migliore è collegare un computer al posto della colonnina, con le stesse impostazioni di rete (DHCP automatico o IP fisso).

• Per una colonnina con modem 4G, verifichi che l’APN e l’utente / password siano corretti, poi lo stato del segnale 4G, spesso disponibile dalla colonnina o dal router 4G esterno.
• Aggiorni il firmware con l’ultima versione ufficiale disponibile sul sito del produttore.
• Provi prima a cambiare il token in WS (non protetto, porta 80).
• Poi, se funziona, torni a WSS (protetto, porta 443).

2. Lato supervisione, se tutto è a posto lato colonnina

• Controlli i log lato supervisione (preferibilmente dall’interfaccia web), come descritto nelle domande sui log. Se non viene ricevuta alcuna richiesta di apertura WebSocket, la colonnina non comunica correttamente, soprattutto se altre colonnine sono già collegate sullo stesso spazio cloud.
• Verifichi anche lo stato del token (validità e revoca) dal menu «Colonnina / Collega una nuova colonnina».
• Verifichi se la colonnina risponde ai comandi OCPP (Reset, StartTransaction…) consultando nel frattempo i log del backend.

Quando e come contattarci

Se nessuna colonnina risponde più e la rete non è la causa, potrebbe esserci un bug lato supervisione. In tal caso ci contatti (categoria «Richiesta di assistenza») con la descrizione esatta del problema: data dell’incidente, riproducibilità, nomi delle colonnine interessate, test effettuati, ecc.

Se il problema sembra legato alle colonnine, a una colonnina in particolare o compare dopo un aggiornamento del firmware, raccolga i log lato colonnina e lato supervisione e apra un ticket con il produttore.

Il debug è un servizio fatturabile presso ChargeAngels, salvo in caso di bug dimostrato e documentato lato supervisione. Solo le colonnine certificate da ChargeAngels sono coperte dal nostro contratto di assistenza. Nella maggior parte dei casi i bug sono causati da un blocco della colonnina, da un problema di rete o da un uso scorretto da parte degli utenti.

Buone pratiche

• La soluzione migliore è tenere una colonnina «di riferimento» vicino alla sua sede, per il debug e per riprodurre guasti o errori. Un aggiornamento del firmware è un’operazione rischiosa che a volte può mettere fuori uso definitivamente una colonnina. In assenza di una colonnina di prova dedicata, esegua i test su una colonnina isolata e poco usata.
• Quando mette in servizio colonnine che non conosce, esegua un test di messa in servizio prima dell’installazione definitiva.
• Per le colonnine 4G, analizzi in anticipo la copertura della rete 4G (esistono dispositivi appositi).
• Per i test funzionali esistono simulatori di ricarica per colonnine AC (Tipo 2) di Metrel. Consigliamo anche test con un veicolo elettrico reale.

Leggere log JSON o in qualsiasi altro formato richiede competenze informatiche. I messaggi OCPP tra le colonnine e il nostro server sono standardizzati nella specifica OCPP, che consigliamo di leggere per prima: openchargealliance.org/my-oca/ocpp. Offriamo inoltre formazione su questo protocollo, nonché formazione operativa (lettura dei log e debug), oltre alla qualifica IRVE P2/P3.

Tre famiglie di problemi ricorrono più spesso. Sono illustrate nelle domande successive:

• problemi di collegamento della colonnina al backend;
• problemi di chiusura della sessione: nessun StopTransaction ricevuto;
• problemi di chiusura della sessione: StopTransaction ricevuto, ma con stato errato.

Sintomo: la colonnina non compare nella dashboard del CSMS ChargeAngels anche se la rete funziona, oppure si ricevono richieste WS/WSS ma in errore.

Spiegazioni: l’apertura di un WebSocket è esclusiva iniziativa della colonnina, non del CSMS. Se sul lato supervisione non arriva alcuna richiesta WS o WSS e la rete funziona (la colonnina raggiunge internet, ad esempio il DNS di Google), è probabile che l’URL impostato nella colonnina sia errato o incompleto. Ogni marca o modello ha le sue specificità e a volte richiede uno strumento specifico per impostare questo URL: app web, app mobile, applicazione Windows dedicata, ecc.

Soluzioni: consigliamo di leggere prima l’intera FAQ, in particolare le domande sui log WebSocket. Dopo la rete, l’impostazione dell’URL è la causa del problema nel 99 % dei casi: occorre quindi applicare un metodo sequenziale e iterativo.

Un URL errato ha spesso più cause:

1. Alcune colonnine supportano solo WS: consigliamo di iniziare da lì (chi può di più può di meno).
2. Alcune colonnine supportano WSS solo dopo l’ultimo aggiornamento del firmware.
3. Alcune colonnine richiedono un primo collegamento in WS e poi il passaggio a WSS (Schneider, a seconda del firmware).
4. Alcune colonnine supportano WSS ma solo con TLS 1.2 e non con TLS 1.3.
5. Alcune colonnine richiedono un profilo di sicurezza specifico: non abbiamo un profilo specifico, ma il livello 2 è accettato con qualsiasi password.
6. Alcune colonnine richiedono il certificato radice del CSMS (certificato Root CA).
7. Alcune colonnine richiedono la porta 80 o 443: in tal caso la aggiunga all’URL.
8. Alcune colonnine separano host, porta, percorso e ChargeBoxID, poi concatenano l’URL WSS per effettuare le chiamate in uscita.
9. Alcune colonnine non offrono un ChargeBoxID: occorre allora aggiungerlo alla fine dell’URL, altrimenti la chiamata verrà rifiutata da parte nostra (questo campo è la chiave primaria nel nostro database).
10. Alcune colonnine aggiungono una barra alla fine dell’URL, altre no (da parte nostra non c’è alcuna limitazione in merito).
11. Alcune colonnine troncano l’URL perché troppo lungo (sempre meno frequente).

Sintomo: nel menu Sessioni / Cronologia compaiono sessioni fantasma ed è impossibile interrompere una sessione di ricarica in corso. Log di errore: Remote Stop Transaction has been rejected in 1.52s, reason 'Rejected'.

Sequenza nei log:

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

Spiegazioni: la sessione resta in sospeso lato CSMS, qualunque sia lo stato reale della colonnina, poiché non ne conosciamo lo stato (nessuno StopTransaction ricevuto). Riavviare la colonnina non ha quindi alcun effetto sulla sessione in sospeso, finché il CSMS non riceve lo StopTransaction della colonnina con l’ID di transazione corretto. Avviare un’altra sessione genera un altro TransactionID, cioè un’altra voce nel nostro database.

Soluzione: ha una sola possibilità: selezionare il pulsante «Force Stop» disponibile su ogni sessione in corso, dall’interfaccia utente. Questo forza l’arresto lato CSMS.

Sintomo: nel menu Sessioni / Cronologia compaiono sessioni fantasma o uno stato anomalo della colonnina (diverso da CHARGING / SUSPENDED / FAULTED / RESERVED).

Caso normale quando lo StopTransaction viene ricevuto

• StopTransaction + AVAILABLE (FINISHING facoltativo): la transazione viene interrotta e finalizzata.
• FINISHING non è obbligatorio: vengono verificati solo AVAILABLE o PREPARING (FINISHING è usato per il tempo di sosta).
• SUSPENDED, FAULTED e RESERVED non influiscono sul processo.

Casi «anomali» gestiti automaticamente

1. StopTransaction ricevuto, ma nessuno StatusNotification dopo X minuti: «Force Stop» automatico da parte di un’attività pianificata del CSMS (ritardo di 30 minuti).
2. Nuovo StartTransaction ricevuto senza uno StopTransaction precedente: senza consumo, la transazione viene eliminata; con consumo, viene applicato un «Force Stop» automatico.
3. StatusNotification AVAILABLE senza uno StopTransaction immediatamente prima: la transazione resta attiva (nessuna azione immediata). Se lo Stop arriva dopo, la finalizzazione è normale; se non arriva, l’attività pianificata applica un «Force Stop» (30 minuti).
4. StatusNotification AVAILABLE prima dello StopTransaction: il sistema crea artificialmente uno StatusNotification a partire dallo stato attuale del connettore (Available) e dal timestamp dello StopTransaction, per calcolare correttamente il tempo di sosta aggiuntivo.

Esempio di una cronologia reale:

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

Soluzione: in tutti i casi diversi da quelli descritti sopra, può interrompere manualmente la transazione dalle sessioni «in corso», con il pulsante «Force Stop».