Temperature Spikes


Hi,

I decided to “wake up” this old thread since I have a similar issue with the temperature measurements.
In my case there is a patern. Almost everyday for some peculiar reason there is a temp spike around 10:00 AM. It’s actually consists by two spikes very close the one to the other. The first is lower and the second is the higher.

I did a bit of research just to check if some load turns on at this specific time each day but I couldn’t figure out a definitive patern or something that may affect the readings in the temperature sensor.

As depicted in the screenshots, this doesn’t happen every day and when it happens it happens in a very specific way. It didn’t create +20C or -20C readings but it adds around 7 to 10 degrees on the actual reading.

Any ideas ?

thanks in advance!

I moved this to a new topic.

How are you measuring the temperature?

In short - no.

I am fairly confident that the wrong values you are seeing are not errors coming from the DS18B20 sensor, the data from the sensor is protected by a checksum and if the data itself were being corrupted in transit, the checksum would surely fail.

I think your first suspicion - that it is something external that happens at the same time each day - is the likeliest explanation, but it might not be on your premises, it could be mains-borne.

I hope it’s a silly question - you, or someone within radio range, don’t have another node with the same ID also sending temperature data? There is nothing to prevent that from happening, so although highly unlikely, it is possible.

Hi Robert,

Nice to talk you again :slight_smile:

I only have an emonPi and the DS18B20 is soldered on the board. The whole device (emonPi + Raspberry) are installed outside my home inside the box that the mains cables are being connected to the home. I don’t use any radio node but I don’t know if there is any in the neighborhood but it’s very unlikely to exist. It’s not a very populated area.

I’m straggling to think of any possible cause for this discrepancy. For sure it’s not the sensor otherwise the spike would be random. I also checked if some scripts are running by cron or systemd timer but didn’t find something.

Any other possible or impossible ideas ?

What exactly have you got? The “shop” emonPi has the Raspberry Pi inside the aluminium box, and the temperature sensor is normally external, connected using the RJ45 connector.

I would have thought so too, but I would not rule it out until it is proven good. Is yours a genuine Dallas/Maxim DS18B20, or could it be a “clone” - see Ds18b20 and emonTX3CM firmware - post 78 in particular.

Hello Robert

I bought just the emonPi board along with the AC adapter. I connected it on a raspi 3B+. It runs perfectly so far except the issues with the temperature sensor. The sensor had a cable around 50cm I suppose with shielding. I didn’t crimple a connector on the cable. It was easier to solder it on the board.

The sensor was bought many years ago for some arduino project from China but haven’t been used since till now. It’s supposed to be an original but I can’t be sure without removing the shrink tube and inspecting the chip.

That’s todays spike. This time with a delay of 11 minutes.

And a comparison with power graph.

I’d pretty much guarantee that something is warming the sensor. That isn’t a ‘spike’ it is a gradual warming and cooling.

An animal sitting on the sensor, something heating the box (the sun?).

Put in a time lapse camera and see what you find.

Hello Brian,

thanks for the reply

Well, you may be right. The box is located mostly in the shade except of the morning hours. Meanwhile, I have moved the sensor location from it’s original place when I was trying to arrange the boards inside the main connection box. I will put some insulation foam or something outside the box in the spot where the sensor is installed and check again the temperature readings.

I’ll get back here to report the findings.

BTW, do you or Robert have a clue on how to read the UID of the sensor ? Do you report it somewhere in a log file during the initialization of the microcontroller ? I have compiled a small sketch to read the ID but I have to load it in the MC to run it and I don’t want to mesh with something and get into troubles.

No, the serial number is read and stored by the sketch that runs in the Atmel ATMega 328P on the emonPi Shield, but it never normally leaves that, it’s not written anywhere. If you have the emonPiCM software, then this can report the serial number, the ‘standard’ software cannot.

I think Brian is right - that is a genuine temperature change, it is rising by about 0.3°C per minute. There is no doubt in my mind that the sensor is reading correctly.

I would try something that will reflect the heat away, like aluminium foil, on top of the insulation.

Yeah, I think Brian is right. I just didn’t realize how much difference they make some minutes of direct sun during winter. I thought that impact would be more or less a couple of degrees.

Yes I will insulate using some blanket like those being used in ovens and other similar appliances or I will DIY something.

Thank you all for your help!

I saw a post of yours describing some different versions of FW for the MC but to be honest I didn’t understand too much of what are the differences and why should I use it. If you can elaborate a bit on my specific case applied to the emonPi only, then I might give it a try.

All it is, is it makes the emonPi measure in exactly the same way that the latest emonTx measures - continuously like your electricity meter does, rather than taking a short sample every 5 or 10 seconds and assuming that’s representative.

OK I got it!

It’s the firmware you were referred to when you told me that I could calibrate the CT values from within the serial monitor.

Since I have already done this in the current firmware I will just add the correct calibration factor value to the sketch and just compile and upload. Then I can check and change the values (if needed) through the serial monitor.

EDIT

Compilation with pio run succeeded but I can’t upload it. I used --upload-port /dev/ttyAMA0 but avrdude spits out some sync errors. This never happened with the “standard” firmware.

Any help would be great (and appreciated)

EDIT 2
I compared platformio.ini of the standard and CM firmware and there are quite a few differences. I suppose that I have to adjust some variables in order to compile and upload without issues…?

I cannot recommend platformio - it destroyed my system when I tried it, and it took hours to put everything back in the right places. I only ever use the Arduino IDE, so I’m afraid I cannot help you.

seen that, but it worked fine eventually.

Are you uploading from the Pi? I did some docs a while ago about how to do that GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware) and this post emonTx not sending CT data - #21 by borpin

PIO is fine, and anyway, by this point, you are not using it.

Did you stop emonhub first?

It’s OK Robert. Your help so far is priceless to me. I too don’t use pio but I wanted to compile the firmware on the raspberry so to make things simpler. The obvious solution was pio.

Hi Brian,
Yes, I compile and upload from the Pi where the emonPi is connected to.

Yes I did but the result was the same. See what I did in short:

I cloned this repo locally on the Pi and compiled it (after installing the necessary dependencies) with pio run.

After I saw that the test run was OK I did a sudo pio run -t upload

The output is the following.

Warning! Please install `99-platformio-udev.rules`.
More details: https://docs.platformio.org/page/faq.html#platformio-udev-rules

Error: Please specify `upload_port` for environment or use global `--upload-port` option.
For some development platforms it can be a USB flash drive (i.e. /media/<user>/<device name>)
*** [upload] Explicit exit, status 1

I Ignored the warning for the udev rules because I don’t think is the case since I have uploaded before the “original” firmware without issues and I just added the --upload-port=/dev/ttyAMA0 to the command input. After issuing again the command (and having stopped emonhub service) I got the following output:

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x1c
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x8e
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x70
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xe0

And the upload failed.

Please let me know if something in the procedure above is wrong.

Thank you!

Did you read the instruction link I sent?

That command doesn’t work for a number of reasons.

Should I use this instead?

avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:output.hex