OpenEnergyMonitor Community

EmonTX keeps disconnecting from EmonBase

Tags: #<Tag:0x00007f681c24a050>

I bought an emonTX unit with 4 CTs a few weeks ago along with an emonBase. So far I’m really disappointed with the units.
After one or 2 days of running, the feeds all go red in emoncms and all input stops. I can see the red LED flash periodically on the emonTX. The emonBase is up & emoncms can be browsed but no inputs.
The units are about 9 inches apart!

I have just checked again & I can see it’s been down for 2.5 days.
The only way to get it back up is to power cycle the emonBase. Reboot doesn’t work nor does power cycling the emonTX.
I’m going to hardwire the units together to eliminate the rf connection. I also want to find a way of getting an email or alert of some sort when feeds go down.

Hi, welcome.

Sorry to hear this. It is unusual so something is definitely amiss.

Did you buy a complete EmonBase (Pi and RFM card) or are you using your own Pi? Did you get the SD Card from the shop as well?

The first log to look at is the EmonHub log in /var/log/emonhub/. Older logs will be found in /var/log.old/emonhub/

Emonhub is the subsystem on the Pi (EmonBase) that handles the RF data coming from the EmonTX to the EmonBase.

I have been following the community for about 2 years now, and I haven’t noticed
many posts such as yours. Could be a defective component, it happens.

Concerning the email, I am working on a custom email alert program. When complete my
alert with email every hour if a water leak is detected. I have it completed using MQTT connection,
but am rewriting using JSON, because then I won’t need to log the input, saving data storage.
When complete, and tested I will post it. Other people have shared in the community about emailing at post:
"Email Alert when Input Threshold Reached.
Following are some links to help you get started:


I agree - this is unusual and something is definitely wrong.
The main thing I noticed is

Although I’ve had an emonTx and emonBase even closer - the aerials were actually touching - I’d recommend moving them further apart, because it’s possible that the radio receiver is being overloaded.

You should see a flash a fraction under every 10 s, and you should see a corresponding flash on the RFM69Pi card plugged into your emonBase. Do you see that, even when it’s stopped recording the data?
Also check that the card isn’t tilted over and is not touching the other GPIO pins that it shouldn’t touch.

To save Keith having to answer this, I can see that we supplied the full emonBase kit: Pi, RFM card, SD card and power supply plus cable.

If we fail to get to the bottom of this here, please contact us (the OpenEnergyMonitor Shop) at [email protected] and we’ll sort it out for you.

1 Like

Thanks for the reply Borpin. I checked the old emonhub log & the entries just stopped at 12:28 on Jan 4th. No errors, the log just stopped. I checked the syslog and messages logs, but there was nothing to indicate what caused the issue. On Jan 7th at about 01:30, when I rebooted the system entries started to appear in a new emonhob log, but these seem to be related to initialisation. There were no data entries from emonTX until I shutdown the emonbase, pulled the power & put it back again. A few seconds later the log started to receive entries every 10 seconds or so. I think there may be a hardware issue. I’ll maybe open the box & have a look to see if there are any obvious loose connections or dry joints when I get time.

Thanks for the response. I’ll take a look at these & look forward to seeing your solution.

Hi Robert. Thanks for getting back. I neglected to mention in my first post that I had move the emonBase from another room in the house to be close to the emonTX because the connection was dropping. I also didn’t mention that I’m using a wired LAN connection for the emonBase not WiFi, in case that makes a difference. I can see the flash on the emonTX card, but other than the LAN LEDs I can see no lights on the emonBase. Perhaps it’s inside. I’ll find out when I open it up.

Hi Gwil. OK Thanks for that. I don’t really need the RF connection, so I was thinking of directly connecting the emonBase to the emonTX. I saw a Wiki article on how to do this using 3 wires. The only question I have is about this the PSUs. The emonBase and TX have individual PSUs. The one on the TX is also (I think) used to monitor the mains voltage? I remember reading somewhere about a jumper (J2?) needing to be removed if moving power supplies. So, if I directly connect the units, should I remove the jumper?

I doubt very much that the WiFi vs Ethernet will affect the problem you appear to have.

When you connect the emonTx to the Pi, the documented connection carries the power as well. If you do that, the a.c. adapter stops being a power supply and reverts to its primary function as a voltage for measurement purposes only. The link is where voltage measurement and power supply connect together. (It’s on the right-hand edge when you’re looking at the jack sockets.)
But if you do the connection between the emonTx and the Pi on TWO wires - the emonTx’s Rx (which despite the most confusing name is where the outgoing data appears) and GND, then you can keep the a.c. adapter as the emonTx’s power source.
You can turn the emonTx’s radio off in software. If you have a programmer, use that; if not you need to connect the data line going the other way (the emonTx’s Tx line to the appropriate GPIO Tx pin) so that you can use the Pi to send the appropriate configuration command.


Will be worth a read. Really need writing up properly. I think Julian did at one point in the second thread.

Two of my three PiZero / emonTx combo’s have run impeccably since I installed them (unlike the previous emonTx / ESP8266 arrangement), and I have been most happy. Not a single drop out.

I never did get to the bottom of what happened to the third one, but will try to get it right soon. Meantime I have been upgrading my Home Assistant install from a Pi to a NUC and it is soooooo much faster :laughing:


1 Like

From the sound of it, he has an emonPi vice an emonBase.

Not according to Gwil in post 5: EmonTX keeps disconnecting from EmonBase

Is there a Pi case that’s big enough to take the RFM69Pi as well? But if Keith is going for a direct serial connection, then it may well be a Pi in a custom Pi case.

Not that I’ve seen for sale, but one could be made on a 3d printer.

Actually the rfm2pi boards are so small that they can fit in almost any RPi case. I have yet to find a RPi case that won’t house a rfm2pi and I’ve tried a fair few over the years. In fact I have even fitted a Pi A with rfm2pi in an emonTH case without a struggle (IIRC I posted about it on the old forum).

The shop’s emonBase options include a RPi case that doesn’t look modified or especially large.

That has all the hallmarks of a locked up rfm device, most likely caused by a power supply brownout if the rfm2pi board is sitting firmly and there is adequete gap between the Pi’s GPIO pins and the underside of the rfm2pi board.

Once you check the board is sitting ok, if you wish to pursue this further there is a way to test this by resetting the rfm2pi programmatically when it next cuts out. If/when you get the case off, if you look closely whilst it is all working, you can see there is a very small LED on the rtfm2pi board that flashes in sync (ish) with the emontx’s LED when sending data. When it stop’s, can you check to see if that LED stops flashing.

If it is the rfm2pi locking up, it might be as simple as updating (incl firmware) via the emoncms GUI, IIRC last time we looked at this the rfm69pi’s weren’t being shipped with the latest FW, but that may have changed.

I guess I have better luck at finding stuff like this than you do. :wink:
Or maybe I just have crappy luck. :grin:

I’ve got two of them.

here’s a side by side view of the two:

As can be seen, the black one is just a tad shorter than the clear one, so no joy with that one as well.
(I realize two is definitely not a good “sample size” to base anything on)

No it just seems you have a very early rfm2pi with a dil packaged processor, fitted into a dil socket. They stand soooooo proud, the effective fitted height is many times higher than an smt rfm2pi.

With a later rfm2pi the highest point is probably the rfm module itself IIRC.

How old is that? Does it have a key to wind it up? :rofl:. No, seriously, is that an attiny model perhaps?

Not a key. That’s much too new-fangled. :wink: A rubber band! :smile:

Indeed it is.

2014, 10th manufacturing week.