Peaks on my temperature graphs


Well, it’s a “little” more involved than just calling OneWire::crc8. :wink:

Skim through this,

Read this,

Let me know if you have any questions.

I think OneWire::crc8 is the best solution. A more simple solution would be to test for temperature outliers. You’re reading the temperature every five seconds. I’m not sure how much the temperature of a cold chamber can change in five seconds, but let’s assume the most recent temperature sample indicates it changed by 10 degrees. That’s a pretty good indication the temperature sample is invalid. Just re-read it. You could experiment with smaller deltas.

Again, I vote for OneWire::crc8. If you find it too involved, try the outlier method.



The ESP-01 needs 3.3v. If you power it with 5v you’ll kill it.

It’s generally accepted that the Arduino 3.3v supply rail isn’t sufficient to power the ESP-01 reliably, so you you should be using a separate 3.3v supply, but the ground of that supply and the Arduino supply should be connected together. (Or you should ditch the Ardiono/ESP-01 combo all together and use a Wemos D1 Mini or NodeMCU instead and simplify the whole setup).




Perhaps it depends on the ESP8266 but the NodeMCU ESP8266s I am using do allow 5V power input on its VIN pin.



Yes, that’s why I specified ESP-01, which is what most people use as a Wi-Fi modem.


1 Like


@wickedbeernut, Thank you! I’ll take some time reading the content you shared.
In 5 seconds the actual temperature would NOT change more than 0.1 degrees.

@PeteKnight and @DaleSchultz Thanks! If I use only NodeMCU ESP8266s may I throw away the Arduino One and ESP8266?

Thanks you, gentlemen! You are awesome!



It might be worth you reading this:

Your sensors are 3v to 5v compatible, so will work with a NodeMCU without the need for any level shifting.




I’ll follow your advice! Thanks again!
(I have short attention span also :smile:)

1 Like


Getting 100% accurate readings all the time when using $10 worth of hardware is mostly wishful thinking I guess :sunglasses:

I too had random spikes in my otherwise so pretty graph from time to time that I couldn’t derive to something specific. So instead of doing a ton of trouble shooting I just added some “sanity code”.

Readings that deviate more than +/- 30 degrees from the previous are simply ignored and a notice is printed in my terminal window:

void startSensorConversation() {
	newTemp = true;

void getSensorData() {
	if (newTemp) {

		float temp1E = DS18B20.getTempC(sensor1E);
		float roundedValue1E = ceilf(temp1E * 100) / 100;

		if (roundedValue1E < (lastValue1E - 30) || roundedValue1E > (lastValue1E + 30) ) {
			terminal.println("Error reading sensor 1E !");
		else {
			lastValue1E = roundedValue1E;
			Serial.print("Bedroom: ");
			Blynk.virtualWrite(6, roundedValue1E);

		float temp4B = DS18B20.getTempC(sensor4B);
		float roundedValue4B = ceilf(temp4B * 100) / 100;
		if (roundedValue4B < (lastValue4B - 30) || roundedValue4B > (lastValue4B + 30) ) {
			terminal.println("Error reading sensor 4B !");
		else {
			lastValue4B = roundedValue4B;
			Serial.print("Living room: ");
			Blynk.virtualWrite(5, roundedValue4B);
		newTemp = false;

The code is from my old 433 Mhz project

1 Like


More data!
Checkout these readings when business is not running. No spikes.



Might indeed be interference.
Or someone is placing their hot coffee/iced tea next to the thermometer :stuck_out_tongue_winking_eye:
Can we see a picture of the thing?




I’ll upload more pictures tomorrow when I get to work.
BTW, all the schematic is hidden from people messing around.



You just have to live with it! Reading each sensor every 5 second yields a whopping 34.560 reads every single day(!). If you didn’t have any anomalies among those, that itself would be an anomaly IMHO!

In the DallasTemperature.h you can see that a loss of communication results as these values as an “error code”:

// Error Codes

Does your spikes correspond to any of those values?

Are you feeding your sensors with 3.3 or 5 V and are they in a parasitic configuration?

My standard tips for the DS18B20 is to lower the resolution a bit (10-bit is 0.25 increments) to speed things up. Use the DS18B20.requestTemperatures() function to speed things up even more :slight_smile: Talk to your sensors with their individual address.

Can you post your complete sketch? Sometimes you’re blind to your own code so a peer review never hurts! :man_student: Unless you’ve made an embarrassing error :rofl: We’ve all been there hehe



So what’s not running at night? Fluorescent lighting? Motors (e.g., blowers, …)? Pumps?

Even if you can eliminate most of the interference, I still think it makes sense to guard against bad samples.

I definitely think it’s worthwhile to evaluate whether all of the bad samples involve failed CRC checks. I suspect they do. It’s not that the samples are inaccurate. They’re simply garbage. The CRC check let’s you easily identify these bogus samples.

Again, try to identify the root cause of the interference. However, even if you think you’ve eliminated the source of the interference, there’s absolutely no harm in guarding against future interference.

Keep us updated,




Btw, to me the fact that the error patterns seem to line up between the two thermometers is pretty strong evidence that it’s interference.
The high peaks could also be explained by someone opening the cold chambers at similar times, but that wouldn’t explain the dips.

You might try to wrap the wire that comes out in tin foil to shield it a little and connect the foil to the GND pin, and see if it does it any good.
Careful to not short anything with it.

Also, maybe put a ferrite core filter on the power cable coming in.

Filtering the error with logic as some suggested is also a good idea, but I like physical solutions :stuck_out_tongue_winking_eye:



I also suspect some other electric device (computer monitor perhaps) is causing interference. Ensure the wires to the probes are twisted together and well shielded.



I think the problem is the wire between the Arduino UNO and the DS18B20’s. How long is this wire? It’s running through the wall adjacent to AC wires (e.g., light switch)?

If I were you, I’d jettison the Arduino UNO. I’d dedicate a $2.50 NodeMCU (12-E) to each DS18B20. And I’d either stick each NodeMCU / DS18B20 directly into the cold chamber or I’d co-locate the NodeMCU’s directly adjacent to the cold chambers. Can you get 5VDC into the cold chambers (obviously you can … that’s how it currently works)? Would the construction of the cold chambers allow wi-fi connectivity?

The operating temperature range of the ESP-12E is -40 °C to 125 °C. You’d need to check the operating temperature range of the NodeMCU. For $2.50, it would be worth a try.



You won’t believe. As I put my hands in the hardware it stopped spiking. That way, I suspect some kind of bad pins connections :roll_eyes:.
What’s weird: why would the hardware work well during night and spiking in the morning/afternoon?

@distans spikes are around 12-15 degrees from actual temperature. Never -127°C.
DS18S20 are plugged in to 5V and GND. I believe my error was embarrassing :joy:

@wickedbeernut Great point. What’s not running during night: fluorescent lights, motors (it’s a industrial kitchen), some computers (6 or 7).

@Gspin Yes! Opening the chambers brings variation, but they’re much softer than the spikes. Opening door and spikes are not simultaneous. As soon as the DS18S20’s leave the board they don’t run togheter.

@wickedbeernut Yes! I’ll try another approach in 2 cold chambers that are not monitored yet.

Thanks to all of you! You’re great!!



Your hands likely served to ground it.



Or perhaps a loose connection, that when the door opens/shuts wiggle the wires going to the board?



Just to share a few info about DS18B20.
As it has been already mentioned, temperature measurement is effected in two stage.
Temperature conversion
Reading of the result
When temperature conversion is not successful, reading the result always returns a +85 result (this value is hardwired into DS18B20’s logic).
This explains the rising spikes.
Main cause of unsuccessful temperature conversion is insufficient power supply, either when DS18B20 is parasite or externally powered.
I guess crc error checking is already applied into OneWire as well as DallasTemperature libraries.