I wonder if anyone can help me with a recalcitrant EmonPi? Sometime yesterday afternoon my EmonPi stopped picking up data from temperature sensors and CT sensor. I’ve done a reboot of the Pi, and done a software update…but nothing seems to have helped? What should my next step be?
The system is using the emonSD-24Jul20 image, and it’s been working perfectly up to yesterday
Thanks
Robin
Can you be a bit more explicit? Where are you seeing the data loss? Where are the sensors in relation to the emonPi - connected directly to it? This sort of information is important - otherwise the problem is like “how long is a piece of string?”
Hello @rdavies6 are you able to access the emonPi user interface ok? Can you see anything in Setup > EmonHub > View Log, is there any sign of data coming in, or any errors that might indicate something has changed?
Hi Robert/Trystan
Apologies for the vague initial question.
I’m assuming the device stopped getting feeds, based on this screen…but that’s probably a naïve assumption
The hardware has been running for a number of years…the CT sensor is plugged straight into the EmonPi, and there are a couple wireless temp sensors dotted around the house. Nothing has changed (hardware, software or config wise) before the feeds stopped.
Let me know if there’s more data that would be useful. Since the issue started I’ve done one update, two reboots and mistyped my password once logging on…but I’ve done nothing else. The emonhub, update and emoncms logfiles are attached.
logfiles.zip (159.3 KB)
The data comes in first to the “emon” part of the emonPi. This either generates (in the case of the c.t. and voltage) the numbers, or receives the data packet by radio (I assume you mean the emonTH when you write “wireless”) and passes it via a serial link into the Pi, where it’s first handled by emonHub. EmonHub then passes it to the Inputs page and only after the input processing does it appear on the Feeds page. You’re actually looking for it at almost the final stage.
The data was certainly getting as far as emonHub, and being forwarded to emoncms.org.
These lines in emonhub.log show that happening:
The “emon” part:
2021-10-07 13:33:21,304 DEBUG RFM2Pi 522093 NEW FRAME : OK 5 0 0 31 3 31 3 158 90 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (-0)
The emonTH (I can only find one)
2021-10-07 13:33:23,235 DEBUG RFM2Pi 522094 NEW FRAME : OK 23 247 0 240 0 168 1 24 0 1 0 0 0 (-86)
and sending to emoncms.org:
2021-10-07 13:34:22,075 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json? data=[[1633610036.320914,5,0,773,773,232.79,0,0,0,0,0,0,0],[1633610041.3597727,5,0,723,723,232.95000000000002,0,0,0,0,0,0,0],[1633610046.2913313,5,0,728,728,232.94,0,0,0,0,0,0,0],[1633610051.3249702,5,0,776,776,232.88,0,0,0,0,0,0,0],[1633610056.3679194,5,0,724,724,232.97,0,0,0,0,0,0,0]]&sentat=1633610062&apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y
2021-10-07 13:34:22,221 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org
But then, it stopped until 9:16 am the next day, when it couldn’t open the serial port to receive the data from the front end:
2021-10-08 09:16:17,713 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2021-10-08 09:16:19,716 WARNING MainThread Device communication error - check settings
So my immediate reaction is - the baud rate setting in emonhub.conf is wrong, or something else is hogging the port. The baud rate has been 38400 for a long time, so it’s not likely to be that (but you could try all the baud rates - 9600, 115200 or 57600 have been used at various times).
I don’t understand Github nor MQTT, so @TrystanLea will have to look at that aspect.
Thanks for the analysis @Robert.Wall
The events in the log from around 9:16 on the 8th Oct were me recognising that there had been no readings since 13:33 the day before, so I then did the usual IT troubleshooting step of a reboot 
The baud rate in emonhub.config is set to 38400 baud…and nothing has been changed on this setup for months.
I’ll try and get to the emonPi later today(it’s buried at the back of a full cupboard) to check the physical hardware
What happened at 13:33? Was there a power cut, or something of that nature?
As everything else appears to be working, it’s unlikely the SD card is corrupted, but the possibility is there.
Hi Robert
As far as I’m aware nothing happened…no power outage, or anything unusual. Routers and switches all remained up and running, and there was plenty of other network traffic on the home network. When I noticed the next day, I checked and the RaspPi was pingable and alive, and reachable on it’s normal IP address and VLAN, and the EmonPi responded via the web interface…and allowed me to try a reboot and software update (all to no avail). I’m kind of mystified why the feeds just stopped.
Thanks
Robin
We know why the feeds have stopped, what we don’t know is why the Pi can’t open the port and get the data from the front end. And that is indeed a mystery. Something has changed.
In case the front end has scrambled its brain, have you done a controlled stop and a power-down before restarting? Because rebooting does not reboot the “emon” part, only the “Pi” part.
Hi Robert
Sorry for the delayed response. I/ve just managed to clear a pathway to the EmonPi, and did a controlled shutdown, power down and restart. During the restart sequence I saw a message saying “Updating…Do Not Power Off”, and then it was followed by another reboot. The EmonPi came back up successfully and feeds have restarted. After the issue started last week I did initiate a full update…so maybe the firmware update was a consequence of that? I’ve attached the Update log. Thank you for helping out
update.zip (3.9 KB)