While we wait on Robert, @TrystanLea is it possible to get a copy of the default bootloader on the emonTX? One of the ideas I had was that I may have somehow messed that up (since I can no longer flash the atmega via the UART, only via the ICSP pins) and I’m not sure if that’s connected to the problem I’m facing.
If there would be a way to somehow restore the emonTX to its factory state (including both bootloader & flash), perhaps we can start clean here.
I think the steps for the bootloader upload are here EmonTx V3.4 - OpenEnergyMonitor Wiki its a long time since I have needed to do this on an EmonTx
Thanks I know the steps but I was unable to locate the hex file itself - can you please share that?
Looks like there is one noted as “_bootloader” in the archived repository here, you could try that: emonTxFirmware/emonTxV3/RFM/emonTxV3.4/emonTxV3_4_DiscreteSampling/compiled at master · openenergymonitor/emonTxFirmware · GitHub
As far as I know, @Simsala has been using the sketch in Germany for something over 2½ years, I think with the serial interface and the ESP8266 and in many installations, and I’m not aware of any problems there.
The normal UK domestic supply is single phase, so we’re reliant (mostly) on reports from consumers in continental Europe regarding the long-term reliability of a system.
The line should be #define EMONESP, not commented out in its entirety.
There used to be RS232 monitors sold (this is before portable computers became readily available) that provided a high impedance monitor on both lines, thus making it possible to monitor the traffic in both directions. As long as whatever you are using doesn’t load the signal, then that should work.
But it won’t of course tell you why the emonTx hung, even if it did.
My feeling is this is still a power supply problem. If possible, can the supply voltage (either the 3.3 / 5 V or the mains) be monitored and any brief excursions recorded? (I’m not suggesting you hire a professional mains monitor.)
Could this be an indication of a damaged Atmel ATMega 328P? If the processor is damaged, it could explain your problem.
The line is the following:
#define EMONESP
Regarding the 5V supply, I can’t really monitor that but I can try supplying it from a UPS instead of an outlet; right now it’s a phone charger that powers the emonTX.
I have ordered an AVR ISP MKII to see if I can flash the bootloader & the emonTX with that, as I was using a simple USB to Serial adapter, but I think that one will only arrive next week so I can only do the UPS trick until that.
That is a warning sign. Phone chargers are built down to a price (it’s “free” with the phone, you don’t buy one on its own?) and their sole purpose is to recharge a battery, via a much more sophisticated charge regulator inside the phone. That’s a much different requirement to powering an emonTx that measures down to millivolt signal levels.
Though old now, this is still relevant: Not all USB power supplies are created the same - Blog | OpenEnergyMonitor
And this is worth reading, though not applicable directly to your case: Noise in Arduino based builds. | Archived Forum
OK, UART problem solved. We actually replaced the atmega328p, but turns out the rx/tx lines were connected the wrong way (I connected my serial dongle’s rx to the tx and vice versa) and it has been working all time long. Well, PEBKAC 
But will want to debug the stability problem if persists. I will put the emontx together and connect the charger to the UPS just in case.
Sadly, and I’ve lost count of the number of times I’ve written this here, the last time was just 9 days ago:
@Z0l this may not move you forward much, but the symptoms of our problems are very similar. EmonTx stops sending CT updates to EmonESP. ESP is still online and accessible. My power is single phase though. I think the issue started some time after I added a fourth CT, but that may be unrelated.
https://community.openenergymonitor.org/t/my-emontx-is-unstable
My current status is that it seems more stable after some firmware updates. It’s only been five days so I shouldn’t speak too soon but previously it would stop at least once or twice a week.
Here’s an example where it froze three times in a week.
So it’s fingers crossed for me.
So I’ve been experimenting around but I still have the issue. One interesting find is that pressing the reset button on the emonTX is not enough to make it work again, I have to disconnect the power cord and reconnect to make it work again. I’ve been busy with some stuff lately but I would still like to debug/troubleshoot this to figure out what’s going on. I already received the 2A power supplies and I plan to install those sometime next week.
To me, that is a fairly solid indication that it is not the emonTx that is failing.
I have known the radio to lock up on very rare occasions and, because the RFM’s reset is not connected to the Atmel '328’s reset line and the pushbutton, that has not restarted the emonTx. But you are not using the radio. As soon as RFM69CW is not defined, the code that operates the radio is not included in the compiled version, so that cannot happen.
Isn’t it possible that the ESP8266 module doesn’t recover after a short wifi outage? What is the average RSSI of the module? Do you see wifi reconnects? I’ve seen similar weirdness on Tasmota flashed devices. They were all wifi related.
I’m also suspecting the ESP8266 module, so I will try with a different one hopefully tomorrow. It’s not the wifi that gets disconnected though because I can access the web interface / ping the device, but both the MQTT & the EmonCMS sections say there is no connection.
That only means that the wifi stack/web server is working. The MQTT client can bork, regardless. When the device is not sending data, can you see valid power metrics on its web page? Maybe the MQTT client library exhausts the preconfigured retry attempts and gives up on reconnections. If that’s indeed so, it would be an easy fix upstream.
Nope, the values aren’t changing when the MQTT connection is lost.
I rolled a version of 3.1.0 to see if that works better - in case someone else wants to do it, the serial bitrate value is now in the debug.ino not in the src.ino. If it works, I may spend some time to create a checkbox on the web interface to select between 115200 and 9600 because it’s annoying to roll a new firmware just because the baudrate has to be decreased for the 3phase firmware would be better to use the official one with the switch.
Agreed. Open an issue
Raised #82 for this: No ability to change the serial baudrate · Issue #82 · openenergymonitor/EmonESP · GitHub
Maybe later I’ll also try to submit a pull request, it should be an easy fix.
I hope I won’t jinx it, but I am happy to report that the EmonESP runs flawlessly for 2 weeks now with the compiled version of the new firmware! I’ll consider the stability issues addressed, thank you all for your comments & feedback.
