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
You should follow the whole set of instructions as it creates the HEX file to upload. You can’t just pick and choose bits of a set of instructions.
Note the line “If the emonTX is connected to the RPi via the serial interface” (which perhaps could be clearer).
Also, you may need to edit the file /opt/openenergymonitor/avrdude-rpi/autoreset and change the pin number to 12.
Brian,
I managed to upload the firmware I didn’t anyway strictly follow the document but it was a success.
The problem is that all the feeds and graphs stopped working. I confirmed that firmware is indeed OK by using the serial monitor. There I saw that FW version is 1.0 and I saw readings coming in but feeds were all dead.
Do I have to reconfigure everything ? And if yes, what about the previous records ?
EDIT
I think I found what I missed out. It’s the emonhub.conf…Right?
Quite possibly.
What serial data are you seeing and what is your emonhub.conf?
Well,
I don’t feel quite comfortable to manipulate the databases and the rest parts of the emoncms in order to migrate my history data to the new feeds/inputs so I just changed the reporting FW version from emonPiCM to the old emonPi inside the ino sketch and then added the new names, datacodes, scales, units to the emonhub.conf and now it works like before.
