Peaks on my temperature graphs

Solved
41

Nice work @wickedbeernut

@kostas is basing his ‘claims’ on the Superchart documentation:

Superchart supports currently 2 types of granularity:

  • Minute granularity - 1h , 6h , 1d ;
  • Hour granularity - 1w , 1m , 3m ;

This means that minimum chart update interval is 1 minute for 1h , 6h , 1d periods. 1 hour for 1w , 1m and 3m periods. As Blynk Cloud is free to use we have a limit on how many data you can store. At the moment Blynk Cloud accepts 1 message per minute per pin. In case you send your data more frequently your values will be averaged. For example, in case you send value 10 at 12:12:05 and than again 12 at 12:12:45 as result in chart you’ll see value 11 for 12:12.

https://docs.blynk.cc/#widgets-displays-superchart

Pete.

42

So you’re suggesting, if I send,

10 at 12:12:00,
11 at 12:12:05,
12 at 12:12:10,

the result for time interval 12:12 is,

A. average(average(10,11) + 12) = 11.25

rather than my theory which assumes,

B. average(10, 11, 12) = 11

That would definitely throw a monkey wrench in my theory.

I think we can all agree, we must be looking at some sort of average temperatures. This is going to tamper the spikes. We’re not looking at the actual spike temperatures in @Rodrigo_Cavalheiro’s chart. With averaging method “A” above, the resulting average will vary depending on where the spike occurred in the one minute interval. We’re not seeing this. The spikes are very consistent. With averaging method “B”, it doesn’t matter where the spike occurs in the one minute interval. The spike will always have the same effect on the average value for the one minute interval.

@Rodrigo_Cavalheiro, you mentioned that you’re sampling the temperature every five seconds. Are you sending each sample to the server? Are you performing any averaging in your firmware?

43

No, I think that what it’s saying is that if you send multiple values within a one minute period then they’ll be averaged. In your example of:

the three values would average-out to 11, as all three are sent within the 1 minute window and (10+11+12)/3 =11

Pete.

44

OK. That’s exactly what I was assuming and what my charts are based on. That implies the server maintains one minutes worth of samples (regardless of how many samples were received) in order to calculate the average.

1 Like
45

Yes, I’m guessing that it buffers them and averages the results once every minute then writes the result to the database and flushes the buffer.

Pete.

46

I just saw where @Erko used this code,

image

And then Googled it. Sure enough. 85 and -127.

1 Like
47

Good work by @wickedbeernut and @PeteKnight :+1:

That code doesn’t make ANY sense (to me :face_with_raised_eyebrow:)?!

I mean, you don’t put that crap in the main loop(), it’s a recipe for disaster! And the vPin only updates if the temp reading is 85.0 OR -127.0. I don’t get it! :thinking: (the complete code referred to is here)

We might be drifting away from topic… But I still believe that a +85.0 °C reading only occurs after cycling the power.

48

It’s a do-while loop. You read and continue to re-read the temperature until it returns a value other than 85 or -127.

I’m not advocating that you apply this logic in the loop() routine with Blynk. Or that you even apply this logic at all. I’m simply pointing out this logic is used all over the Internet to address the problem @Rodrigo_Cavalheiro is seeing. It validates the theories around 85 and -127.

(edit) Let me re-state this …

I’m 99% convinced the DS18B20 is periodically returning both 85 and -127. It may well be that @Rodrigo_Cavalheiro is having “power problems” and the DS18B20 is recycling.

1 Like