I’ve been folowing the threads you reference, but what makes it weird is his hardware is almost
5 years old. Seems like it would have gone belly up a long time ago.
1 Like
Intermittent. Getting more frequent. 5 years old? I’m thinking “Dry Joint”. Especially if restarting involves the slightest movement, which is just enough to get it going again for a few days.
2 Likes
Interesting theory. I’ll open it up again and go over the board for dry joints.
Thanks for the input guys. I’ll let you know how it goes.
And loose screw terminals? In fact, every connector is worth looking at.
1 Like
I don’t have an ESP8266, but I understand from Gwil that all the “Shop” versions have the Tx pin cut off, which yours appears to have. The problem is when a non-Shop ESP is connected and the software with the “On-line” RF configuration (an later calibration) is connected. Then, random characters emitted by the ESP reconfigure the emonTx.
Note a very big problem that continues to confuse everyone: Tx and Rx are swapped on the emonTx pcb, so as I’ve written so many times here, the emonTx is sending data on the pin labelled “Rx”, and it’s looking for data coming in on the pin labelled “Tx”. That’s contrary to convention (unless the emonTx is a modem!)
Is that the right way up?
Is ground left or right? If right, both TX & RX are connected.
It’s not plugged in. It’s leaning on the Aerial socket. You’re looking at the bottom of the emonTx pcb, and the bottom of the ESP module. So GND is on the left in both cases, even though it’s off the picture for the emonTx.
So in Colin’s photo, the pin that IS connected (4th from the left) goes across to the 5th from the left, which is the one labelled “Rx” on the emonTx but is the one it sends on.
(If you remember the very first information published about the ESP, the photo showed the Tx & Rx pins twisted around each other (but not touching) to make the crossover Tx→Rx & Rx→Tx (in real terms - not labelled pins 
)
This I think is a later picture: Using the EmonTx v3 with the ESP8266 Huzzah WIFI module
Colin’s appears to be OK, even if the emonTx has the later software that does accept serial input.
3 Likes
A brief update. I reflowed all the joints on the back of the TX board at lunchtime yesterday and it’s been running fine overnight. I’ll update again in a few days. Thanks for all your input.
1 Like
Nothing for a week suggests all is well - or am I tempting fate?
1 Like
FWIW, one of my emonTx just died for no apparent reason a couple of weeks ago (it’s a couple of years old). Power-cycling brought it back again. I’ve no idea what the issue was.
No ESP here (except on my UEFI-based computers of course, but I suspect that is a different ESP 
Sadly, I’m afraid you are. There have been two crashes since I last posted. Both required a restart. Most recently I have reconfirmed that the ESP is still online and accessible when data stops flowing but shows “disconnected” in the EmonCMS section. Do you think it may therefore be receiving data from the TX and is unable to pass it on or is the disconnection between the TX and the ESP?
I know nothing about the ESP, sorry, so I can’t guess what’s happening. But the emonTx on its own has proven very reliable, it’s people who have connected a non-shop ESP to it that has caused problems because the ESP sent data that it should not have done, which was interpreted as configuration instructions and, whilst it continued to run, setting the calibration to zero meant the emonTx showed zero voltage and hence zero power.
The way to test will be to hook it up via the UART to a PC or if you have a spare Pi (any flavour), connect that via the UART.
An update to this ageing thread. The issue continued exactly as before, often freezing and needing to be restarted. In fact, I added a smartplug to the 5v supply so I can remote power cycle it, because the issue happened so often.
This did not used to happen and so we all looked at issue around the age of the EmonTx board etc, but it also did not used to have four CTs plugged in so I am thinking more about that now. Could a timing issue in an older EmonTx firmware cause it to freeze?
Since getting a UART adapter, I have updated both the EmonTx and EmonESP firmware to versions 3.3.0 and 3.0.0 respectively. The continuous monitoring version of the EmonTx firmware did not seem to be compatible with EmonESP, unless I’m missing something.
In the past week, this has been stable. I will report back further after a longer test period.
Where does it say that?
That’s a good question, it doesn’t as far as I can see. And since the continuous monitoring version is now the standard version I naturally started there. But the data pairs shown in the ESP webpage were along the lines of…
AC Power OK : NaN
…rather than the expected…
CT1 : 1234
CT2 : 5678
etc.
So it seemed kind of like the firmwares were both working but not understanding each other. So I switched the TX to discreet sampling and it worked straight away.
It certainly occurred to me that some people must be using CM with an ESP but it didn’t work for me and since I’ve only used DS in the past, I don’t know what I’m missing. If this config is stable then I’m happy.
I don’t have an ESP8266, I’ve never tracked down any meaningful documentation for it, so I really can’t help you.
Did you change the output format of the CM sketch to suit the ESP8266? I can’t see AC Power OK in the copy of the source code that I’m looking at. What there is is a one-off message at start-up: “AC present” or “AC missing”, then unless you have turned on the serial output (for sketches downloaded before 18th of this month) you see nothing. If the serial output is on - as it is for downloads since then, it sends “MSG:nnn,Vrms:vvv,P1:pppp,P2:pppp…” etc. And that is what you will see when you connect a programmer. How this is presented in the ESP8266 I have no idea.
I think it’s about time I returned to and closed off this thread in case it helps anyone.
TL:DR Update your firmware
My EmonTX and EmonESP have worked together flawlessly in the two months since I updated their firmwares per the post above, which I will mark as a solution.
We’ll not be able to say which device was causing the issue given I updated both but since the problem seems resolved it really doesn’t matter.
My inability to to get the continuous monitoring version to work was likely because I had not enabled serial output, as @Robert.Wall says. This was because I really wanted to install specific precompiled versions. Since serial output is now enabled by default, I would advise others to go with this rather than the older discrete monitoring version like me.
Thanks for all of your work and support.
1 Like