My EmonTx is unstable

Bill.Thomson · 2020-06-17T12:04:56.924Z

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.

Robert.Wall · 2020-06-17T12:14:26.362Z

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.

cmcg · 2020-06-17T13:24:54.187Z

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.

Robert.Wall · 2020-06-17T14:08:54.768Z

cmcg:

and go over the board for dry joints.

And loose screw terminals? In fact, every connector is worth looking at.

cmcg · 2020-06-17T22:56:35.412Z

Meanwhile, @borpin waits patiently for me to admit that he probably is right!

We’ll see.

cmcg · 2020-06-18T09:04:18.462Z

borpin:

That is quite common. If the ESP → TX data line is connected (which it used to be) the older firmware sent ‘data’ that causes the TX to stop.

Is this ESP header arrangement what you mean by the TX line being disconnected Brian?

image640×550 76.4 KB

Robert.Wall · 2020-06-18T10:39:52.695Z

borpin:

If the ESP → TX data line is connected (which it used to be)

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!)

borpin · 2020-06-18T12:07:01.907Z

Robert.Wall:

I understand from Gwil that all the “Shop” versions have the Tx pin cut off, which yours appears to have.

Is that the right way up?

Is ground left or right? If right, both TX & RX are connected.

Robert.Wall · 2020-06-18T12:30:32.551Z

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.

cmcg · 2020-06-19T08:29:10.559Z

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.

Robert.Wall · 2020-06-26T10:08:51.784Z

Nothing for a week suggests all is well - or am I tempting fate?

djh · 2020-06-27T22:07:27.979Z

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

cmcg · 2020-06-30T11:38:28.764Z

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?

Robert.Wall · 2020-06-30T12:02:08.509Z

cmcg:

shows “disconnected” in the EmonCMS section

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.

borpin · 2020-06-30T12:16:46.125Z

cmcg:

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?

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.

cmcg · 2020-08-22T06:21:07.600Z

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.

Robert.Wall · 2020-08-22T12:18:35.461Z

cmcg:

The continuous monitoring version of the EmonTx firmware did not seem to be compatible with EmonESP

Where does it say that?

cmcg · 2020-08-22T12:44:56.015Z

Robert.Wall:

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.

Robert.Wall · 2020-08-22T17:59:38.150Z

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.

cmcg · 2020-10-27T10:13:13.240Z

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.