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.
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.
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.
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.
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.
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.
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.
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.
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)
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…?
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.