In Sptember 2021 I built an emonPi from an emonPi Shield KIT, an emonPi Enclosure Kit and a Raspberry Pi 3B that I already had. It has been running happily since then, recording data from a DS18B20 temperature sensor on the emonPi, and energy data from an emonTx3 using the Jeelabs radio format.
In late April 23 I updated the emonPi firmware to emonPi_CM/LPL (v1.1.4) so that I had continous sampling and the LPL radio format (to use with my emonTx4). I added a Jeelink USB module to keep receiving the data from the emonTx3. Everything worked!
Since then, twice in May and four times in June, the emonpi has stopped receiving LPL radio data from the emonTx4, while continuing to record the Jeelabs data via the Jeelink.
So it would seem that the software in the Pi has continued to function.
To get the emonPi working again, I have to shut it down using the button on top, and unplug/re-plug the mains power.
Surprisingly, most times when the emonPi shield has stopped receiving the LPL data, it has continued recording the temperature, so (some?) of the the firmware in the atMega328 has continued to work. Perhaps the RFM69 module is locking up?
Has anyone else seen this behaviour or know what the problem is?
Hello @rupert sorry to hear that. I have not noticed this in my testing with the emonPi_CM but we’ve had similar radio related issues before. Does the energy monitoring continue working on the emonPi_CM as well as the temperature sensing? It seems strange that temperature sensing would continue to work but not the electric monitoring…?
Hi @TrystanLea Thanks very much for the reply. Sorry if the previous post wasn’t very clear.
I don’t use the emonPi now for electric monitoring, just for receiving, storing and displaying data from my emonTx4, emonTx3 and Mk2pvrouter. From previous use, the emonPi does have logged feeds set up for power1. Vrms and T1. The only sensors plugged into it now are a DS18B20 and the AC-AC voltage sensor. There are no CTs.
Using the graph page on the emonPi and looking at the historical logged feeds, the emonPi Vrms measurement continues when the emonTx4 LPL Vrms is lost. Also the power1 measurement continues at zero watts with no lost data. So from this I would assume that energy monitoring firmware in the emonPi Shield atMega328 is continuing to run ok when the shield stops receiving LPL data.
As another data point, I also have a DIY emonBase (old version) consisting of a Pi3B, RFM69pi (the old atMega328 version, with LPL firmware), and a Jeelink USB. This is used as a backup for the emonPi. It is located adjacent to the emonPi and hasn’t suffered any LPL data dropouts, so it seems the the emonTx4 is not the problem, nor radio signal strength/path/interference problems.
Another data point is that when the emonPi stops receiving LPL data, it remains stopped, even after a few days. It is only fixed when the emonPi is shutdown, and power is removed then replaced.
My emonPi stopped logging data from my emonTx4 (node 14) again on July 9. However it continued logging emonPi data (node 5) from the emonPi Shield, so communication between the Shield and the Pi over ttyAMA0 was still working.
Looking at the emonHub log, there was nothing there from the emonTx4 (node 14), but there were entries from the emonPi (node 5).
After noticing in a helpful post from @Robert.Wall in the topic:
that there was a serial monitor in the EmonCMS Admin page, I stopped emonhub and had a look at what was appearing on ttyAMA0, at 115200 bps. This was while the emonTx4 data was not apparently being logged. The result was:
So the data was present from node 5 (the emonPi Shield) as expected, but also from node 14, my emonTx4 - but was not being logged.
And when I restarted emonHub, the data from the emonTx4 was now being logged again …
The graph below shows the two feeds for Vrms from the emonPi and emonTx4. Note at the extreme right that the emonTx4 feed starts working again after emonHub has been restarted
You should be able to answer this by downloading the emonHub log file and looking at the times, if you get a period when there’s only the “emon” front end (Node 5), then it’s the radio or the emonTx at fault. If there’s a discontinuity in the times, you can’t say whether emonhub stopped or the data didn’t make it to emonCMS and to the log.
Have you expanded the graph, and does it still show a flat line even when every data point is graphed? It’s almost inconceivable that you could have hit null data points in between valid data over such an extended period, unless each and every one was a null, but something to rule out.
I tried downloading the the emonHub log file using the button on the emonHub page, which gave me a 3.3MiB file called emonhub.log. Unfortunately this only seems to span a few hours of today.
I’ll have to wait until the next drop out to check what’s happening in the emonHub log. Going by my previous post, and the graph, the emonPi (Node 5) data was present during the emonTx4 drop out and as far as I remember was in the emonHub log.
On the graph I posted, the straight line disappears when I tick the ‘Show Missing Data’ button.
If I adjust the time span to cover either a small part or most of the straight line period, there are no points shown on the graph with ‘Show Missing Data’ ticked or unticked; and the y axis scale changes to -1 to +1. Looking at the CSV output, the data is all ‘null’.
So I would assume that during the straight line period that there is no emonTx4 data being transferred over ttyAMA0 to the Pi and emonCMS.
During the drop out period my emonBase continued to log the data from the emonTx4, so I don’t think there is a problem in the emonTx4.
All this would imply a problem with the radio (RFM69) in the emonPi. The thing that puzzles me is that stopping and starting emonHub to use the serial monitor seems to have restarted the emonTx4 (node 14) data flow from the radio - unless it was just a coincidence …
My emonPi receives RF data from an emonTx3 and some emonTxShields (all using the Jeelink format ) via USB from an unmodified Jeelink USB module.
The emonPi also receives receives measurement data from the atmega328 add-on board - e.g. Vrms and temperature measurements, and LPL format RF data from an emonTx4 via the on-board RFM69.
The firmware of the atmega328 in the emonPi has been updated (1.1.4) to allow reception of the LPL format. Although this allows LPL reception. it has corrupted the data shown on the emonPi LCD - see:
My problem:
Apart from the emonPi LCD problem mentioned above, the emonPi now regularly stops recording emonTx4 data, although the measurement data from the atmega328 sometimes continues, so the atmega328 is still working. The failure to reliably log data means the emonPi is unusable.
I also have an emonBase unit which receives the same data as the emonPi (LPL via the RFM69Pi, Jeelink via a USB Jeelink). It shows that the transmitted emonTx4 data is not dropping out. The emonBase is next to the emonPi so I don’t think it’s a signal strength issue. And the emonPi data dropouts didn’t start until I upgraded the emonPi to LPL and added the USB Jeelink.
When the emonTx4 data is lost, it disappears from the emonHub log.
Also when the emonTx4 data is lost, a lot of new spurious input nodes are often created. see
At first I thought the the RFM69 on the emonPi was failing, but the problem can be fixed by halting the emonPi, and turning the power off and back on, or restarting the emonHub.
i.e. by going to
Setup / Emonhub /
and clicking the orange ‘Restart’ button at the top right of the page. This seems a reliable (!) way of getting all my logging going again after a stoppage. No full power cycle is necessary.
I am assuming that this means I have an EmonHub problem … perhaps …
Or is it possible that there are occasional collisions between USB and AMA0 data that are upsetting things?
My emonBase receives LPL RF data using the RFM69Pi board and Jeelink data via the USB Jeelink. It doesn’t suffer from data dropouts.
My emonPi receives the same RF data, LPL via the emonPi measurement board, and Jeelink data via the USB Jeelink. It suffers from data dropouts.
The obvious difference between the two is the RFM69Pi on the emonBase vs the emonPi measurement board on the emonPi. Also the RFM69Pi communicates with the Raspberry Pi over ttyAMA0 at 38400, while the emonPi measurement board uses 115200.
The atmega328 on the RFM69Pi just has to cope with receiving RF data. The atmega328 on the emonPi measurement board has to work harder and have more firmware, to allow it to make measurements, as well as receive RF data.
