EmonPI periodically stops working. Alays managed to get back on track with hard reset... 'till now

Emoncms
1

Hi there,
my EmonPI periodically stops working letely (say once every 6-9 months. I always managed to get back on track with hard reset… 'till now.
Emonpi is acceccible trough the network. Services look up and running, web inerface just worksfine but inputs page doesnt’s show any meaninfigul input anymore.

Tried full update,
Tried multiple hardwar rests
Tried stopping and restarting revices
Tried updating components

Help would be highly appreciated

2

Hello @CrisPastore what do you see in the emonHub log? Do you have any radio nodes or is it just the emonPi?

This might be useful? emonHub Troubleshooting — OpenEnergyMonitor 0.0.1 documentation

3

Hi,
I don’t have any radio nodes.
my feeds look stuck since yesterday
in particular
node:emonpi:power1_grid_input
node:emonpi:power2_solar_output
aren’t updated since 19 hours.

I’m pasting here a chunk of the EmonHub Log that might be useful

2024-12-24 10:57:21,178 INFO     MainThread EmonHub v2.7.1
2024-12-24 10:57:21,180 INFO     MainThread Opening hub...
2024-12-24 10:57:21,181 INFO     MainThread Running as user: pi
2024-12-24 10:57:21,182 INFO     MainThread Logging level set to DEBUG
2024-12-24 10:57:21,183 INFO     MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
2024-12-24 10:57:21,186 DEBUG    MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
**2024-12-24 10:57:23,190 WARNING  MainThread Device communication error - check settings**
2024-12-24 10:57:23,191 INFO     MainThread Setting RFM2Pi baseid: 5 (5i)
2024-12-24 10:57:24,193 INFO     MainThread Setting RFM2Pi frequency: 433 (4b)
2024-12-24 10:57:25,196 INFO     MainThread Setting RFM2Pi group: 210 (210g)
2024-12-24 10:57:26,198 INFO     MainThread Setting RFM2Pi quiet: 1 (1q)
2024-12-24 11:00:16,872 INFO     MainThread Setting RFM2Pi calibration: 230V (1p)

any clues of what this communication error at line 2024-12-24 10:57:23,190 WARNING could be?

thanks

4

How old is the EmonPi/SD Card? Odd things happeneing are often attributed to and SD card starting to fail.

Could be full with logs.

Try SSH in and df -h to see if the card is full.

5

Hi there,
the SD card look still having plenty of room

image
image1247×517 28 KB

emonpiRelease dates as follows:

image
image708×264 13.5 KB
.

I dunno if helps but the built in display shows _ _ _on both Power 1 and Power 2, which makes me thinking of a faulty EmonPI board (probaly the UART sending data to the Raspberry PI)
BTW did you noticed the /dev/ttyAMA0 communication error? Doesn’t this sounds as an HW error to you? BTW I tried to dial down the communication speed to 9600 bps, gettin the same error.

6

@CrisPastore
I don’t think I can help with the emonPi (presumably V.1) stopping working, but seeing

reminded me that you might want to look at the topic

When the CM (continuous measurement) method was introduced instead of the previous DS (discrete sampling) method some time ago, the format for the radio transmissions was changed from the Jeelib format to the LPL (Low Power Labs) format. This required new firmware in the emonPi board for the CM and LPL updates.

When this happened there were problems with incorrect results showing oh the emonPi LCD display, so there may not be a hardware problem with your emonPi board.

From memory, the other things that changed in the CM/LPL update were

  1. the /dev/ttyAMA0 baud rate increased from 38400 to 115200
  2. the emonHub config for the emonPi changed as the CM/LPL format included a message number at the beginning of the data and extra pulse2count,E1,E2 measurements
  3. the CM node name for the emonPi in emonHub was originally suggested as emonpiCM. As the original DS node name was emonpi, this meant that the CM data did not appear in the original inputs, unless the CM node name was changed back to emonpi.

So you might want to check what updates you’ve done.

Don’t know if this helps! Apologies in advance for any mistakes!

7

In between those two was RFM69Native format, which I spent many months developing at Trystan’s request, only for it never to become the default format in The Shop.

@CrisPastore As you don’t have anything sending data to your emonPi by radio, you can choose whichever you prefer. If you did and changed to LPL radio protocol, anything transmitting to the emonPi would also need changing.

8

SD Card at least 4 years old. I’d be inclined to move to a new card and see if that helps. Import / Backup / Restore / Update — OpenEnergyMonitor 0.0.1 documentation

A failing SD card creates some weird behaviour.

9

Hi Rupert,
i tried to swith to CM (continuous measurement), as per your directions and my inputs are now back on track.

For some reason something is now messed with my feeds, (swapped solar and mains exchnge, and some wrong scaling) but I’m positive I’ll sort this out.

MANY THANKS!

10

You haven’t swapped the CTs around by accident, have you? That, especially if you’ve tweaked the calibration of one or both, would fit both symptoms. Other than that, I can’t think of a good reason for either problem. The calibration constants for both emonLib and emonLibCM are the same (the current for 1 V at the ADC input), and the powers are sent in the same order.

11

@CrisPastore

That’s good!

The default CTs used with the emonPi1 are the YHDC SCT-013-000 Current Transformers, as shown below

image
image650×510 36.4 KB

As @Robert.Wall has already suggested, I was also going to ask if you haven’t accidentally swapped over the 3.5mm jack plugs from the CTs into the emonPi CT1 and CT2 inputs?

Alternatively, are the two blue CTs still clamped on the original cables, or have they been moved/swapped?

If the blue CTs have been moved, it might be worth checking that the clamps are fully closed. Any gap or grit between the mating ferrite faces will affect the calibration.