EasyManua.ls Logo

LEM DCBM 400 Series - 7.2.4. Memory Depth; 7.2.4.1. Required Action Following a Transaction; 7.2.4.2. Fallback Procedure for Unavailable Upload

LEM DCBM 400 Series
95 pages
Print Icon
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
Page 73/95
21January2021/Version 0
LEM International SA
Chemin des Aulx 8
1228 PLAN-LES-OUATES Switzerland
www.lem.com

The DCBM transaction storage is limited to 20399 transactions. Once this threshold is crossed,
oldest transactions are successively erased. This requires the charger controller to save the
transaction elsewhere in order to comply with national regulation.
Following sections o󰀨er solutions for the charger controller to periodically and safely retrieve past
transactions.
 
In order to prevent data loss, individual backup shall be observed:
• Achieve a transaction stop
• Read the data using /ocmf API
• Backup the response in the backend.
 
In case individual backup is temporarily unavailable, transactions can be backed up subsequently.
The charger controller must count the number of transactions that could not be uploaded.
Once communication is back, all the unsaved transactions can be retrieved recursively (using
mode “Retrieve by chronogical storage index”, see "7.2.3. Transaction readouts")
• Retrieve last transaction
GET request on http://192.168.1.2/v1/ocmf
• 2. Retrieve the one before
GET request on http://192.168.1.2/v1/ocmf/-1
• 3. Retrieve the one before
GET request on http://192.168.1.2/v1/ocmf/-2
• X. And so on until all unsaved transactions are successfully backed up.
If a total of 20399 were not saved, the charger controller shall prevent any new transactions until
upload is possible. Otherwise, the oldest transaction is deleted each time a new one is started.
!

Table of Contents