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.
and
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 
Julian
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 - #5 by Gwil
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. 
Or maybe I just have crappy luck. 
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? 
. No, seriously, is that an attiny model perhaps?
Not a key. That’s much too new-fangled. A rubber band! 
Indeed it is.
2014, 10th manufacturing week.
Yesterday the emonBase went offline. I couldn’t connect to emoncms nor could I ping or SSH to the unit.
This morning it was the same. There were no lights on the RJ45 LAN socket. Since I don’t have a console connected to the device, I had to pull the power. I took the opportunity to take off the lid. The exposed copper end of the aerial cable appeared to be touching one of the GPIO pins. So I put a bit of tape over the end.
I removed the rfm card & had a look. It’s possible that the aerial solder point on the underside of the board may have been touching a GPOI pin. Just to be sure I put some tape over the solder joint.
I put it all back together, plugged in the LAN & power & it all came back up.
When I connected to emoncms I noticed that it had actually been recording data right up to the moment I pulled the power. So it wasn’t totally dead, it was just the LAN that was down?
I’ll see how it goes for a few days now that it’s been taped up.
1 Like
Interesting - I have an emonPi using the old WiFi USB dongle that loses the WiFi connection. Pulling the dongle out, waiting a moment or two and then replacing it restores the WiFi, and the Pi and emonHub/emonCMS carry on regardless throughout. It’s probably not related, but worth mentioning.
[When I replaced the Pi’s OS/emonCMS with the July 20 version, I didn’t do anything special for the WiFi dongle, which is the original shop Edimax (?) one.]
Apologies Paul but I didn’t read your reply properly until after I had removed the RFM module & connected the devices together. So I never checked the LED inside 
.
I connected the devices directly because after taping up the exposed metal parts of the RFM last weekend, it only stayed up for 12 hours then connection was lost again.
The devices are now communicating via direct connection (once I got past the issue with using /dev/serial0 instead of /dev/ttyUSB0 it was quite easy).
I seem to have lost a lot of sensor options with the new config (see the screenshots). However, this doesn’t bother me yet as I’m only using the CTs for input.
I did take a look at the interfacer files to maybe sort the lack of sensor inputs myself. But I soon gave this up because I don’t know Python (nor do I really know what I’m doing yet).
I’ll leave it running now to see if it stays up.
Can you clarify that?
Hi Robert
If you look at the screenshot, the top input is what I have now (only 3 power sensors and no temperature sensors).
The lower one that I was using when I used the RFM module had many more options.