Regarding the picture above,
I’ve change it according to @ScruffR suggestion.
As we can see in the picture EEPROM.get only get the first summation right. But then, the summation process got a negative sign number.
I guess, this is because the address. Means that, the space is not enough.
Maybe…
Do you have any suggestion and opinion regarding this matter?
I have only outlined what needs to be done. Can you show the entire code after you applied the principles illustrated above to the rest of your code too?
Here I attach my code…
#define LM35 A1
#define READSAMPLES 100
// this constant won't change:
const int buttonMeasure = D5; // the pin that the pushbutton is attached to
const int buttonReset = D6; // the pin that the pushbutton is attached to
const int ledPin = D7; // the pin that the LED is attached to
// Variables will change:
int BStateMeasure = 0; // variable for reading the pushbutton status
int BStateReset = 0; // variable for reading the pushbutton status
float bt, sum, t;
int sample[READSAMPLES];
int EEPROM_START;
int EEPROM_END;
int address;
int count;
void setup() {
// initialize the button pin as a input:
pinMode(buttonMeasure, INPUT);
pinMode(buttonReset, INPUT);
// initialize the LED as an output:
pinMode(ledPin, OUTPUT);
}
void loop() {
char msgMeasure[64];
char msgReset[64];
// read the pushbutton input pin:
BStateMeasure = digitalRead(buttonMeasure);
BStateReset = digitalRead(buttonReset);
EEPROM_START = 0;
EEPROM_END = count;
//Particle.publish("EEPROM_ENDe: ", String::format("{\"number =\": %d}", count));
if (BStateMeasure == HIGH) {
t = writeTemp();
EEPROM.put(address, t); //write value to current address counter address
count++;
snprintf(msgMeasure, sizeof(msgMeasure)
, "{\"temp\":%0.2f"
",\"address\":%d"
",\"Contcount\":%d"
"}"
, t
, address
, count);
Particle.publish("ON1", msgMeasure, PRIVATE);
address += sizeof(t);
delay(1000);
//Particle.publish("Button press count:", String::format("{\"count =\": %d}", buttonPushCounter));
}
else if (BStateReset == HIGH) {
float mean;
for (int i = EEPROM_START; i < EEPROM_END; i++)
{
sum = sum + EEPROM.get(i, t);
Particle.publish("Summation:", String::format("{\"sum =\": %d}", sum));
delay(2000);
}
mean = sum / count;
snprintf(msgReset, sizeof(msgReset)
, "{\"sum\":%0.2f"
",\"mean\":%0.2f"
"}"
, sum
, mean);
Particle.publish("ON2", msgReset, PRIVATE);
//Particle.publish("ON2", msg, PRIVATE);
delay(1000);
//Particle.publish("Button press count:", String::format("{\"count =\": %d}", ButtonPushCounter));
}
delay(2000);
}
float writeTemp()
{
int j;
float average = 0;
//Particle.publish("Data count entering: ", String::format("{\"Data No. =\": %d}", buttonPushCounter));
for (j = 0; j < READSAMPLES; j++)
{
average += analogRead(LM35); //read sensor value
delay(50);
}
average /= READSAMPLES;
float mv = ( average / 4096.0) * 3300;
float cel = ( mv / 10 );
/*if(address == EEPROM.length()) //check if address counter has reached the end of EEPROM
{
address = 0; //if yes: reset address counter
}*/
return cel;
}
Below is the other picture of the result, just now…
or
Did you notice these statements in my earlier posts?
That's why this can't work
this is correct right, the address will automatically change according to the size of t value..
OH…
now I understand…
the i value right?
Correct, you’d need to increment by sizeof(float) (=4).
I’ll try this…
sum = sum + EEPROM.get(i*2, t);
No, not *2 
haha…
+4
Above picture shows that, no change occur after I corrected the code.
for (int i = EEPROM_START; i < EEPROM_END; i ++)
{
sum = sum + EEPROM.get(i + 4, t);
Particle.publish("Summation:", String::format("{\"sum =\": %d}", sum));
delay(2000);
}
Let the sum as below:
if,
i = 0, address = 4
i = 1, address = 5
Therefore, above is incorrect.
Let the sum as below:
for (int i = EEPROM_START; i < EEPROM_END; i + 4)
{
sum = sum + EEPROM.get(i, t);
Particle.publish("Summation:", String::format("{\"sum =\": %d}", sum));
delay(2000);
}
if,
i = 0, address = 0
i = 4, address = 4
i = 8, address = 8
Seems correct. However, still not solve.
I guess you need to step back a bit and get a feeling for what you are doing.
You had this
Where the idea was right, but the factor was wrong.
Then you got
Where the "factor" was right, but the operation wrong.
Hence this was wrong too (as you correctly noticed)
But now you have introduced a new issue by doing this
The width of your steps ("factor") is correct now, but how many steps are you making now? 
(and you are never really changing i - the console log should give you a clue what I mean with that).
To me it looks you are just trying out combinations without first contemplating what all the effects of a given change would be.
The i value will increment one by one as i++.
So, if I want it to increment by four, I need to do as i+4 in the for statement.
Because, if I change i value in address by i+4, the i value will stay increment by one and just plus by four.
When you know that this is short hand for i = i+1 (or i += 1) then you might see what's wrong with the following
So no, when you do that you just add 4 and i but don't do anything with the result.
If you want to increment you'd write i = i+4 or shorter i += 4.
However, that would only bring you one step closer to the solution as there is another issue in the for() statement 
As an alternative you could persue your other thought you had earlier
How about
sum += EEPROM.get(i*sizeof(t), t);
You increment i by one but factor in the size of your variable (4 in this case)
i (i*4)
0 0
1 4
2 8
3 12
I never thought it to be like this…
sum += EEPROM.get(i*sizeof(t), t);
I’ll give it a try…
That’s how I would write it (short and flexible).
The longer, literal version would look like this
sum = sum + EEPROM.get(i * 4, t);
(but I don’t like the look of that and the potential risk that I’d have to revisit the code if I ever decided to change float t to double t or so)
The above picture shows that the result of sum and mean is correct by using the code improved by @ScruffR. But I’m want to know why the operation of sum has negative sign.
What datatype is sum and what do you see in your output?
The sum datatype is float.
What I can see in the output is…erm…
Maybe 8-bit unsigned integers…
