Gateways and Energy Servers
Schneider Electric support forum to share knowledge about product selection, installation and troubleshooting for EcoStruxure Panel Server, PowerTag, Com'X, Link150…
User | Count |
---|---|
81 | |
46 | |
28 | |
28 |
Link copied. Please paste this link to share this article on your social media post.
Good Morning,
we often receive the question about "data dimension" to send logs to Energy Online.
I mean the weight (in KB or MB) of the file that Com'X200 is sending to the cloud portal.
This is an important data to calculate the GPRS traffic and so the cost of the SIM contract (usually M2M SIM)
Is there a kind of formula that links the number of devices/number of mesaures for each device/logging time and time of exportation (every day - every week , etc...)
Has someone any ideas?
Thanks!
Link copied. Please paste this link to share this article on your social media post.
Hello,
The format for the publication to Energy Online is CMEP (http://www.smi-ieso.ca/sites/default/files/resource_files/California%20Metering%20Exchange%20Protoco...).
Estimating the size of the file before sending it is quite complex because the size of each text field depends on a user input (e.g. the name of a device) and the sampled values.
For example, energies are sent as intervals. If there is no consumption, the value will be 0 (= 1 byte). If the consumption is 3.6546kW, the value will be 3.6546 (= 6 bytes).
(I did not take into account all the commas in the previous examples).
So the final size of the file will depend on each client case.
Nevertheless, I will try to give you are very rough method to estimate the size of one periodic publication.
Consider the following variables:
C1 depends on the user inputs. I used 200 after analysing a example of file. The longer the devices and measure names are, the bigger the value will be.
C2 depends on the installation life. I used 7 because there are 3 bytes for 3 commas. The 4 more bytes came from the average between 1 byte and 7 bytes numbers.
Example with the following configuration:
Thus the estimated cost of a periodic publication is:
C = 110800 bytes (108KB)
As I already told, this is very rough and have to be confronted to the reality of each client case.
Moreover this does not take into account the transport protocol cost (FTP, HTTP, HTTPS or SMTP).
It could be considered as insignifiant. To be checked.
I hope this will help.
Sylvain
Link copied. Please paste this link to share this article on your social media post.
Hello,
The format for the publication to Energy Online is CMEP (http://www.smi-ieso.ca/sites/default/files/resource_files/California%20Metering%20Exchange%20Protoco...).
Estimating the size of the file before sending it is quite complex because the size of each text field depends on a user input (e.g. the name of a device) and the sampled values.
For example, energies are sent as intervals. If there is no consumption, the value will be 0 (= 1 byte). If the consumption is 3.6546kW, the value will be 3.6546 (= 6 bytes).
(I did not take into account all the commas in the previous examples).
So the final size of the file will depend on each client case.
Nevertheless, I will try to give you are very rough method to estimate the size of one periodic publication.
Consider the following variables:
C1 depends on the user inputs. I used 200 after analysing a example of file. The longer the devices and measure names are, the bigger the value will be.
C2 depends on the installation life. I used 7 because there are 3 bytes for 3 commas. The 4 more bytes came from the average between 1 byte and 7 bytes numbers.
Example with the following configuration:
Thus the estimated cost of a periodic publication is:
C = 110800 bytes (108KB)
As I already told, this is very rough and have to be confronted to the reality of each client case.
Moreover this does not take into account the transport protocol cost (FTP, HTTP, HTTPS or SMTP).
It could be considered as insignifiant. To be checked.
I hope this will help.
Sylvain
Posted: 2014-09-29 08:10 AM
Link copied. Please paste this link to share this article on your social media post.
Hello,
I recently have a bad surprise when I receive the first invoice from the SIM contract provider.
I use a Com'X200 with a GPRS dongle and exporting through FTP to Energy Operation.
I've estimated the total monthly need by browsing the FTP server content of previous exports (significant periods).
I did the sum of all the zip files uploaded on the ftp site and estimate the maximum monthly need.
The effective data volume on the invoice was much more than the one I had calculated (10 times more for some months).
One of the explaination I see is that the difference between usefull data and effective data going through GPRS is due to crashes during export and retries.
Dimitri.
Link copied. Please paste this link to share this article on your social media post.
Hello Dimitri
Could you share your figures?
You said 'months' , so I think you have few invoices with valuable information.
Anyone else?
Carlos
Posted: 2014-09-30 01:29 AM
Link copied. Please paste this link to share this article on your social media post.
We are working with Com'X since the begining of 2013.
It's an R&D project, we are working with prototypes and the Com'X version is not the sold one (The current software version is 1.0.3 : sept 2013).
5 Com'X200 are installed and get measurements from sensors (ZigBeeGP) and export every 10min between 100 and 250 measurments (zip files size on ftp server are between 1ko and 2.5ko)
We have experimented several GPRS configurations (e.g. each Com'X with it's own dongle and SIM) but the current installation is with a single modem (DIGI) with a single SIM and the GPRS connexion is shared between the 5 Com'X + 1 EGX300.
The maximum sum of the zip file size (observed on the ftp server side) for one month is less than:
4.5Mo (Com'X1) + 9Mo (Com'X2) + 11.5Mo (Com'X3) + 10Mo (Com'X1) + 7Mo (Com'X1) + 3Mo (EGX1) = 40Mo
We have 2 invoice examples with a total amount of data of 180Mo and 476Mo...
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.