Feeds Stop, Have to Reboot EmonBase

Tags: #<Tag:0x00007f6e0f9b67a0>

I am using an EmonTX with one temperature sensor and three CT sensors. Located within a few feet, I have an EmonBase that was built from an existing Raspberry Pi, plus a RFM69Pi module purchased from the OpenEnergyMonitor store.

On a seemingly-random basis (could be hours, could be days), the EmonBase stops collecting data or stops feeding the data–I’m not entirely certain which. I can still remotely connect to the EmonBase, and all I do to get it working again is click the Restart button under Setup > EmonHub. I realized early on that I don’t have to restart the EmonTX at all.

I am using this setup to remotely monitor the pumps in our neighborhood pump house–one CT sensor each for two well pumps and a pressure pump. Sometimes when I go to the Emoncms website I will find no live data, and that’s when I will go restart the EmonHub.

I have looked through the community posts and found one similar complaint, but that was a while ago and it sounded like an update of the EmonHub software (which I did a few weeks ago) should have installed the latest code that was supposed to address this issue, so I assume this is a different problem than the one that was reported there.

I would upload a couple of log files, but I can’t since I an a new user to this forum. What I see when I log in after I notice a failure is the following line every thirty seconds in the log, :

2017-11-03 10:23:00,348 INFO emoncmsorg sending:

In this log, this is what immediately precedes the lines above:

2017-11-03 10:23:00,345 DEBUG emoncmsorg acknowledged receipt with ‘ok’ from
2017-11-03 10:23:00,346 DEBUG emoncmsorg Sending bulkdata, success: True
2017-11-03 10:23:00,347 DEBUG emoncmsorg Current queue length: 0

Any help is appreciated, as I need to get a point where I can count on this data always being collected and available. More than once already I’ve missed data I was eager to collect because the failure occurred overnight and it was a few hours before I knew to restart EmonHub.

Thank you!

Hi David, Can you tell us what happening with the LED on the RFM69Pi? Is flashing when it’s working? Does it stop flashing when the data stops? If si is it constantly off or constantly on?

I’ve bumped your user level up so you can post some logs, emonhub.log is usually the most useful.

How old is the emonTx? Do you have a USB programmer if needed?

How is your emonBase powered? Do you have an alternative PSU you can try if needed?

Can you create a file /homp/pi/ containing the following

#!/usr/bin/env python

__author__ = 'Paul Burnell (pb66)'
__date__ = '14-05-2015'

import RPi.GPIO as GPIO
import time

pin = 7 # P1-7 (BCM pin 4 or WiringPi pin 7)

	GPIO.setup(pin, GPIO.OUT)
	GPIO.output(pin, GPIO.HIGH)
	GPIO.output(pin, GPIO.LOW)
except Exception as e:

make it executable with

chmod +x /homp/pi/

and next time the data stops (after checking the LED) run


from the command line and let us know if that gets things moving again without restarting emonhub. This little script should just pulse the reset line of the RFM69Pi which maybe why restarting emonhub works, not because emonhub needs restarting but the knock on effect is the RFM69Pi gets reset.

Thank you for the response, Paul.

I can’t immediately answer your question about the LED on the RF module. Next time the failure occurs I will go the pump house to look (it’s a couple of blocks away).

I will post logs tomorrow when I have better access to the remote file system.

The emonTX v3 was purchased on 1 May 2017, and the RF module was purchased on 22 May 2017. I used a Raspberry Pi 2 and SD card that I already had available to finish the build-out of the hub.

I do have a USB programmer but limited experience with it. I should be able to suss it out, though.

Strange that I don’t remember exactly how the emonBase is powered, but I believe it is a wall wort-style power adapter with a micro USB plug for the RPi. 120v, but I don’t remember the amperage rating on it–I believe I it’s relatively high for an RPi power supply, probably 2 or 2.5 amp, so the USB wi-fi would have adequate power. I’ll verify that tomorrow.

I’ll get the script on there and will test it out next time I see the failure.

Thanks, again!

Saw that data recording had stopped some time in the last couple of days, so I stopped by the pump house this morning and found no lights at all on the RFM2pi (the Pi itself was working fine).

Created the py script you suggested and ran it, which did successfully get it reporting again without any other actions. Will have to stop by the pump house again to see the status of the LED on the RFM2pi.

Forgot to look at the power supply.

Latest log attached with plenty of fail to look through. Thank you again for your assistance!


emonhub (8).txt (916.5 KB)

That confirms the RFM2Pi is stalling, this could be due to a power supply issue so it would be real useful if you could check the power supply, even if it is spec’d high enough, do you have another one to swap to test?

All the fails in the emonhub.log relate to networking issues eg SSL errors and DNS lookup errors, not necessarily linked to the issues you have. Although I could not rule out a poor power supply might cause the WiFi dongle to cause network issues but that would be really jumping the gun, there could also be several other (more likely?) causes.

The power supply is 5v 2200mA, which I expected to be plenty of power. I am sure I have another one around here somewhere that may put out a bit more current.

The emonPi’s wi-fi connects to a wi-fi amplifier in the pump house which maintains a line-of-sight connection to my home wireless network. Although the signal is pretty good for the distance, it’s still somewhat weak and tenuous. That could contribute to networking errors, especially if the house loses its internet connection like we did early Monday morning.

Seems like I could script a timed restart of the RFM2Pi, but that’s attempting to treat the symptom and not the cause.


So would I, but I have been surprised in the past, it’s not just about the available current, but also about the stability of the voltage. Plus we cannot rule out a fault with it. Does the PSU have an integral lead or is it a USB type with a detachable USB to micro USB lead?

Indeed, Doing a “quick fix” like that actually makes it much tougher to locate the issue. But I fully understand you need to get things back up and running any which way you can sometimes. It’s just a little frustrating as your not the first to suggest something like this and if fewer users followed this route perhaps it would be fixed by now.

Where is the emonBase? Could temperature be a factor? Only a couple of days ago I said “It’s been a while since we’ve had any cases like this” and (sod’s law) since then we have possibly seen a couple more cases. I wonder if it’s due to a drop in temperature?

Is it feasible for you to be able to get the emonBase and the PSU to co-habitat a project enclosure together? perhaps by using a short extn lead? I’m wondering if the enclosed heat from the PSU and Pi might improve things?

For once I don’t have an extra power supply available, so I’ll order a new one. The one I have is straight micro USB, there is no detachable lead.

I am more interested in a permanent fix than a workaround. Yes, it would be nice to have consistent data, but it’s not critical. We’ve gone 50 years without any monitoring at all, so this is still an improvement.

The emonBase sits on top of one of our pressure tanks and the emonTX is about six feet away next to the pump controllers. It has been colder here recently, but the pump house stays around 6 degrees even when it’s freezing outside, but we had this issue even in the warmer months. I’ll work on an enclosure since I had planned to do that, anyway, but that will take me longer than replacing the power supply.

I’ll post an update in a couple of days. Thanks for the continued help!


IMO that’s the better option, one less connector set to potentially cause an issue and integral lead also makes the PSU smaller and less prone to knocks. The only time a detachable lead is beneficial is when the PSU is used with multiple devices needing different connectors/leads or if a lead could fail due to portable use and/or high number of connect/disconnect cycles. For a fixed install you cannot beat an integral lead.

If you do go for a detached lead type, be sure to get a power rated lead, USB leads are not all the same and outer cable dimension doesn’t always reflect the conductor core size.

Ever considered connecting the emonTx serially rather than RF?

New 3A power supply was connected yesterday. Had a network connectivity issue overnight and was pleased to find out that the data wasn’t lost. As far as I can tell, the device has been working for the past 15 hours.

I read about connecting the devices serially and I will give that some serious thought. There’s no reason I can’t, I just expected wireless connectivity to work better than it has. I’d still like to understand better what’s causing the RF module to crap out.

Updates to follow, and thanks again for your help!


Hi everybody
i to am having simular -issue but mine is more consistent -after about 6 day the emonbase stops receiving data
i have 5 sensor sending info and all is lost till a reboot occurs
even the local service via the emonbase inputs fails so i don’t thinks its a rf issues
the unit in indoors -in a tamper proof box
i can only access the webpage as the unit is many kms away in a clients home and physical ass is limted
what logs do i need to get hold of fault the issue

running the lastest firmware and software

4 posts were moved to another topic: Wi-Fi Comms Fail - Emonpi

The power supply replacement has not worked for my issue with the RF dropping. I am still having to reset the RFM2Pi on a daily basis. I have not enclosed the devices yet, and I will be testing out the serial connection in the coming week.

Vicbitter57, are you saying that your network connection is dropping (wi-fi) or that the RF connection is dropping (data from emonTX)? There would be different troubleshooting paths depending on which.