GPRS Commands — Flusso operativo#
Diagramma di flusso#
┌────────────────────┐
│ 1. add gprsCommand │ → crea comando, status = pending
└──────────┬──────────┘
▼
┌────────────────────────────┐
│ 2. get gprsCommand (poll) │ → ripeti finché:
│ status == received │ status: received
│ response valorizzata │ response: valorizzata
└──────────┬──────────────────┘
│
│ nessuna risposta dopo ~5 min / 5:30
▼
┌────────────────────┐
│ 3. Timeout │
└──────────┬──────────┘
│
┌───────┴────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ 4a. reset │ │ 4b. retry │
│ gprsCommand │ │ gprsCommand │
│ + nuovo add │ │ (stesso id) │
│ → nuovo id │ │ │
└──────┬───────┘ └──────┬───────┘
└────────┬─────────┘
▼
torna al polling (fase 2)
Fasi#
1.
Add — add gprsCommand crea il comando per un IMEI, stato iniziale pending.
2.
Polling — get gprsCommand ripetuto finché status = received e response è valorizzata.
3.
Timeout — le centraline trasmettono almeno ogni 5 minuti; se pending supera ~5 min 30 sec, il comando è da considerare in timeout.
4.
Recovery — due opzioni equivalenti:reset gprsCommand + nuovo add → nuovo id, si riparte dal polling.
retry gprsCommand → stesso id, reinviato alla prima trasmissione utile, si riparte dal polling.
⚠️ Avvertenze#
Blocco sequenziale per IMEI: i comandi sullo stesso IMEI si eseguono in ordine. Un comando in pending blocca tutti i successivi, a tempo indefinito se non gestito.
Cancellazione in ordine: se cancelli comandi per ID, fallo sempre nell'ordine di inserimento oppure utilizza il reset che cancella tutti i GPRS COMMANDS nel modo corretto reset gprsCommand. Nessun timeout automatico: l'API non scade da sola i comandi; è il client a doverlo rilevare e attivare reset/retry.
Rischio consumo dati: se un comando di disattivazione (es. fine collaudo ad alta frequenza) resta bloccato, il dispositivo può continuare a trasmettere a frequenza elevata, con costi extra sulle SIM IoT.
Procedure di collaudo#
Si possono suddividere in 3 macro aree: FULL, PLUS, OTHERS
Procedura corretta di gestione GPRS COMMANDS#
Ogni volta che faccio un add gprsCommand devo sempre attendere che riceva una risposta.
Per verificare la risposta devo eseguire get gprsCommand e controllare le proprietà status e response. Questo comando lo devo richiamare fino a che la proprietà response viene valorizata e status viene settato a received I GPRS COMMANDS vengono sempre eseguiti in maniera sequenziale.
Se un comando rimane in pending, tutti i comandi successivi non verranno eseguiti!
Se devo cancellare un comando con il suo ID, devo sempre cancellare i comandi in ordine di inserimento.
Le centraline sono configurate per trasmettere come minimo una volta ogni 5 minuti, quindi se un GPRS COMMAND rimane in pending per più di 5 minuti probabilmente il comando è stato mandato alla centralina, ma questa non ha risposto. In questo caso bisogna resettare il comando e rimandarlo e ripetere l'operazione di polling.Il Retry è possibile farlo in due modi:1.
Effettuare il reset completo con reset gprsCommand, inserire nuovamente il comando ottenendo un nuovo id e poi fare il polling sul nuovo comando fino a ad ottenere una risposta. 2.
Usare la route per il retry retry gprsCommand che mette il comando in condizione di essere reinviato alla prima trasmissione utile Procedura Comune/OTHERS#
2.
Attivazione modalità di collaudo per forzare trasmissione ogni 10 secondi: add gprsCommand 3.
Verificare la risposta del comando con get gprsCommand per poter andare avanti.Ripeterlo fino a che non si ottiene una risposta altrimenti i comandi successivi non funzioneranno!
4.
verifica di corretta comunicazione con i server tramite la route qora/vehicles/
Bisogna verificare il signal per stabilire che la centralina comunica.
Vericare la location che non sia 0.0,0.0 5.
Disattivazione modalità di collaudo: add gprsCommand
Per dispositivi FMC650/FMC234Per tutti gli altri dispositivi 6.
Verificare la risposta del comando con get gprsCommand per poter andare avanti.Ripeterlo fino a che non si ottiene una risposta altrimenti i comandi successivi non funzioneranno e se il veicolo rimane in modalità di collaudo rischia di consumare tutto il traffico dati e causare costi maggiori delle sim IoT!
In caso di problemi#
Se la centralina non comunica con i nostri server le possibili cause sono:2.
Mancanza di segnale GPS (se non viene fatto il fix gps la centralina non trasmette)
3.
Errata configurazione del APN
4.
Errata configurazione del server su cui trasmettere
Per i primi due casi la soluzione è quella di provare la procedura di collaudo all'esterno.
Nel caso 3 e 4 bisogna usare i GRPS Command:Caso 3#
2.
Ripeterlo fino a che non si ottiene una risposta altrimenti i comandi successivi non funzioneranno!
4.
Ripeterlo fino a che non si ottiene una risposta altrimenti i comandi successivi non funzioneranno!
Caso 4#
2.
La risposta get gprsCommand deve essere map.bimsat.com per la production e phpdriver.bimsat.com per l'area di testAssicurarsi di ottenere una risposta ripetendo la GET altrimenti i comandi successivi non funzioneranno!
3.
Se fosse diversa bisogna impostare il server con il comando: add gprsCommand 4.
Ripeterlo fino a che non si ottiene una risposta altrimenti i comandi successivi non funzioneranno!
PLUS#
Questo genere di centraline viene installato su veicoli leggeri, come furgoni o auto ed è in grado di leggere i consumi, la percentuale di riempimento del serbatoio e altri dati CAN.Collaudo in condizioni ottimali#
2.
Perchè la comunicazione con il CAN avvenga correttamente il motore deve essere acceso
3.
Verificare che le proprietà fuel_used e fuel_level siano valorizzate con qora/vehicles/ 5.
Ripeterlo fino a che non si ottiene una risposta altrimenti i comandi successivi non funzioneranno!
7.
Un esempio di risposta potrebbe essere CAN1:0x01,CAN2:0x01,CAN3:0x03
8.
In base agli schemi di installazione potrete capire quali CAN bisonga collegare. Nel caso riportato al punto 7 il veicolo va collegato sia al CAN1 che al CAN2 e la risposta dice che il collegamento è stato fatto correttamente.
Per leggere i dati dal CAN bisogna specificare il modello del veicolo sul quale verrà montata la centralina.
Solo impostandolo correttamente si potranno leggere i dati CAN. La centralina dovrà arrivare con già il file OEM impostato, ma se questo non fosse possibile si può attuare la procedura di autoscan che effettua questa operazione in autonomia
Come attuare procedura di autoscan#
1.
È consigliato effettuare l'operazione in un luogo dove si è sicuri che è presente segnale GPRS e GPS.
2.
Quando il dispositivo si accende e lo stato di accensione del motore passa a 1, la funzione AutoScan inizierà a funzionare automaticamente.
3.
Il dispositivo raccoglie i dati dalla linea CAN per alcuni secondi e li invia a FotaWEB.
4.
L'operazione può durare anche 1 minuto o più in base al segnale.
5.
Si può verificare che l'operazione è andata a buon fine tramite la route qora/vehicles/, verificando che le proprietà fuel_used e fuel_level siano valorizzate. 6.
Se l'operazione non va a buon fine entro 3 minuti si può riavviare manualmente con il comando: add gprsCommand 7.
Ripeterlo fino a che non si ottiene una risposta altrimenti i comandi successivi non funzioneranno!
8.
A questo punto si effettua nuovamente la verifica con qora/vehicles/ verificando che le proprietà fuel_used e fuel_level siano valorizzate.Anche questo punto va ripetuto fino a che non si ottiene un risultato positivo, con un eventuale timeout dove si può informare l'installatore di generare qualche evento manuale, per esempio scuotendo la centralina per un 10/15 secondi in modo che generi un record di movimento e lo mandi al server insieme ad eventuali altri dati come carburante.
9.
Se entro 3 minuti le proprietà non vengono valorizzate potrebbe esserci un problema di collegamento hardware oppure il veicolo non è compatibile
FULL#
Questo genere di centraline viene installato su veicoli pesanti e può effettuare lo scarico dei dati TachigraficiCollaudo in condizioni ottimali#
2.
Se la porta FMS è collegata verificare che le proprietà fuel_used e fuel_level siano valorizzate con qora/vehicles/, questo controllo non è bloccante per validare il collaudo, ma dovrebbe solo attivare un allert
3.
Per verificare il collegamento del Tachigrafo il motore del mezzo deve essere acceso
5.
Ripeterlo fino a che non si ottiene una risposta altrimenti i comandi successivi non funzioneranno!
7.
Un esempio di risposta potrebbe essere CAN_2:111,0000, K-Line:1, Addr:251, Baud:250, Ign:1
8.
Ecco una rapida spiegazione della risposta del comando tachocheck:CAN_2 deve essere 111. Se il primo valore è 0 significa che il collegamento al BUS non risponde correttamente. Gli altri due valori si riferiscono alle sessioni di comunicazione e autenticazione e se il primo valore è a 1 e uno degli altri è a 0 allora bisogna aspettare un po' e rimandare il comando tachocheck fino a vederli tutti a 1.
Il secondo set di caratteri indicano la comunicazione con la porta FMS e se sono tutti diversi da 0 allora la comunicazione è attiva
La K-Line serve per i dati in real-time e se è 1 allora è attiva.
Gli altri dati indicano Addr: l'indirizzo di memoria di dove scaricare il file DDD
Il Baud è la velocità di lettura del BUS
Ign è l'ignition che se a 1 il motore risulta acceso
In caso di problemi con il Tachigrafo#
A seguire le procedure di risoluzione della comunicazione con il Tachigrafo:1.
Se il comando tachocheck dà un esito negativo la prima cosa da fare è effettuare un doppio controllo sui collegamenti
2.
A questo punto segue un loop di tenativi con i parametri Baud Rate, Resistenza interna e CAN Address
4.
Se non funziona con Baud Rate a 500, attivare la resistenza interna: add gprsCommand 5.
Se non funziona con Baud Rate a 500 e con la resistenza interna attiva, provo a rimettere il Baud Rate a 250: add gprsCommand 6.
Se arrivati a questo punto ancora non risponde in maniera positiva il comando tachocheck, bisogna cambiare il CAN Address (solitamente il Default è 251, ma è bene verifcarlo dalle risposte di tachocheck): add gprsCommandRimettersi nella condizione iniziale: 7.
Se continua a non funzionare rieseguire in ordine i punti 3 -> 4 -> 5
