Is it possible to flash the underlying emonTx via an emonESP?
Are there plans to add this capability in the future?
(I need to switch to 3-phase Firmware)
No, it’s not possible; and it’s unlikely to be added in the foreseeable future. The reason is, the ESP generates random characters at startup that apparently can’t be inhibited, and which can (and have) reset the calibration of the emonTx and caused no end of trouble, and this is why the Tx pin on the ESP is cut off.
By far the easiest way to reprogram is to remove all power from the emonTx, unplug the ESP8266, connect your programmer, upload and calibrate the new sketch, save the calibration in EEPROM (or edit the defaults in the sketch and reload), remove all power and restore the ESP.
Any idea if those come from the esp SDK or the hardware?
I don’t think I need calibration, so I will just build the firmware with the appropriate #defines, including replacing RFM69CW with EMONESP and flash via a usb serial adapter?
I build using PlatformIO for VSCode, what should I use to do the flashing, emonUpload? This will be on a remote computer, not where I am building.
Editing the sketch as you suggest is fine, I can recommend only the Arduino IDE for compiling and uploading the sketch. I shall never again try to use platformio. It moved files and destroyed my system when I tried it. I’m afraid I can’t help you if that’s what you are trying to use.
I got my .hex files fine, will use avrdude.
Now I’m struggling with pinout.
What is the pin between 5V and GND?
I don’t understand where to connect my UART, wiki and repo aren’t helping 
Edit: Finally found Learn | OpenEnergyMonitor
I get stk500_getsync() attempt 1 of 10: not in sync: resp=0x4d 
Does it need CTS and RTS?
Flashed, now the emonTx isn’t printing anything
Nothing even if uncommenting DEBUGGING and SERIALPRINT with both EMONESP and RFM69CW disabled.
I’m confused. If you uploaded .hex files, then you can’t be using the C++ source files where the debugging etc statements are. Changing those will have no effect, until you compile that source with the requisite libraries and then upload again to the emonTx.
I’m assuming you have the 3-phase sketch, as you mentioned that one.
You should have
#define EMONESP
for ESP-format serial output. For the 3-phase sketch, you must drop the baud rate to 9600, and do the same with the ESP8266. There are details in the 3-phase sketch documentation.
Even if you don’t change the baud rate, defining EMONESP should be enough to generate an output. If you’re not using the programmer from the shop, remember that Tx and Rx are not labelled conventionally. As I’ve written so many times I daren’t try to count them, “Tx” on the emonTx is the pin where it receives data from another ‘Tx’, and “Rx” on the emonTx is the pin it sends data from to another ‘Rx’.
I build .hex files using PlatformIO for VSCode (platformio.platformio-ide) from this repository: GitHub - qm3ster/emontx-3phase at esp.
I then transfer them over and flash them with
until [ -e /dev/ttyUSB0 ]; do sleep 0.1; done;
avrdude -uV -c arduino -p ATMEGA328P -P /dev/ttyUSB0 -b 115200 -U flash:w:firmware.hex;
screen /dev/ttyUSB0 115200
With my builds (both ESP and DEBUGGING+SERIALPRINT) and with the two latest builds published to Releases · openenergymonitor/emontx-3phase · GitHub I have absolutely no output on serial.
With Release v2.1.0 · openenergymonitor/EmonTxV3CM · GitHub (non-3phase firmware) I get normal greeting output
(I don’t seem to be able to press +++ though, strange)
Yes, we already went through “this wants Tx, not is Tx” phase, and then the “oh well, guess we will have to populate flow-control pins on our UART adapter”.
Our adapter is this, our emonESP is from the shop (I successfully flashed it over WiFi to enable EmonCMS on non-80 ports (PR) and got data from non 3-phase firmware.
Currently for debugging I am just connecting with
screen directly after flashing.
Excellent, screen /dev/ttyUSB0 9600 works, thank you so much!
I assumed wrong baud rate would print at least some garbage.
I still don’t seem to be able to type +++ (or anything else), which seems odd.
I guess I’ll have to flash the emonESP with a 9600 firmware too?
Is this the highest value possible?
stock
OpenEnergyMonitor.org
emonTx V3.4 CT1234 Voltage 3 Phase PLL example - Firmware version 1.40
Using RFM69CW Radio
Loaded EEPROM config
Calibration:
vCal = 268.97
i1Cal = 90.91
i1Lead = 2.00
i2Cal = 90.91
i2Lead = 2.00
i3Cal = 90.91
i3Lead = 2.00
i4Cal = 16.67
i4Lead = 0.20
Network: 210
Node: 11 Freq: 433MHz
POST.....wait 10s
'+++' then [Enter] for config mode
0.00 0.000 0.000 0.000 0.000 0.00 0.00 0.00 0.00 0.000 0.0000 0.0000 0.0000 0.0000 300.00 Pulses=1 PLL is unlocked
0.66 0.000 0.000 0.000 0.000 0.00 -0.76 -1.56 0.00 49.940 0.0000 0.0000 0.0000 0.0000 300.00 Pulses=1 PLL is unlocked
0.42 0.000 0.000 0.000 0.000 0.00 -0.07 -0.12 0.00 49.564 0.0000 0.0000 0.0000 0.0000 300.00 Pulses=1 PLL is unlocked
debug
OpenEnergyMonitor.org
emonTx V3.4 CT1234 Voltage 3 Phase PLL example - Firmware version 1.40
Loaded EEPROM config
Calibration:
vCal = 268.97
i1Cal = 90.91
i1Lead = 2.00
i2Cal = 90.91
i2Lead = 2.00
i3Cal = 90.91
i3Lead = 2.00
i4Cal = 16.67
i4Lead = 0.20
Network: 210
Node: 11 Freq: 433MHz
POST.....wait 10s
'+++' then [Enter] for config mode
Phase shift coefficients:
x1 = 1.00 y1 = 0.00
x2 = 1.00 y2 = 0.00
x3 = 1.00 y3 = 0.00
x4 = 1.00 y4 = 0.00
0.00 0.000 0.000 0.000 0.000 0.00 0.00 0.00 0.00 0.000 0.0000 0.0000 0.0000 0.0000 300.00 PLL is unlocked
0.63 0.000 0.000 0.000 0.000 0.00 -0.77 -1.52 0.00 49.979 0.0000 0.0000 0.0000 0.0000 300.00 PLL is unlocked
0.43 0.000 0.000 0.000 0.000 0.00 -0.01 -0.07 0.00 49.542 0.0000 0.0000 0.0000 0.0000 300.00 PLL is unlocked
ESP-only
OpenEnergyMonitor.org
ct1:0.00,ct2:0.00,ct3:0.00,ct4:0.00,vrms:0.00,t1:300.00,t2:300.00,t3:300.00,t4:300.00,t5:300.00,t6:300.00,pulses:0
ct1:0.00,ct2:-0.80,ct3:-1.55,ct4:0.00,vrms:0.66,t1:300.00,t2:300.00,t3:300.00,t4:300.00,t5:300.00,t6:300.00,pulses:0
ct1:0.00,ct2:0.00,ct3:-0.03,ct4:0.00,vrms:0.43,t1:300.00,t2:300.00,t3:300.00,t4:300.00,t5:300.00,t6:300.00,pulses:0
for some reason miniterm --rtscts /dev/ttyUSB0 9600 gets it in the right sense of mind (I can later interact using screen)
but if I start with even screen -f /dev/ttyUSB0 9600,crtscts I can never send anything again, even with miniterm --rtscts /dev/ttyUSB0 9600
Oh well, guess I’ll have to use miniterm
Finally got everything working, and I’m getting measurements of the type
| k | v |
|---|---|
| ct1 | -40.66 |
| ct2 | -93.04 |
| ct3 | 0.02 |
| ct4 | -45.55 |
| vrms | 244.95 |
… I wonder what any of that means xD
Especially, who is ct4, when that’s the neutral.
It often does, but not always.
It is. Above that, the PLL loses lock, which means the data, although still available, is almost certainly meaningless.
The latest version is 1.9 I don’t understand Github, so I release the latest on the forum here Update to 3-Phase PLL sketch - #21 by Robert.Wall, Github tends to lag behind.
You should never need to put a c.t. on the neutral of a 3-phase supply. If you know your 3-phase theory, the neutral current ideally is zero, in reality it is the imbalance current - the vector sum of the three line currents. If you read the documentation that’s in the zip file when you download from here, you’ll see where you can use CT4.
Thank you, I’ll try it now.
I got it to build by doing the following: Apply changes · qm3ster/emontx-3phase@896799c · GitHub
Are there any reasons, like licensing, that the libraries should be distributed separately?
Sorry, but I have nothing to do with Github.
That’s fine, it seems to be working.
I am getting lines like ct1:151.51,ct2:92.32,ct3:72.79,ct4:-69.64,vrms:245.26,t1:300.00,t2:300.00,t3:300.00,t4:300.00,t5:300.00,t6:300.00,pulses:0 
That looks reasonable - a temperature of 300.00 °C means no sensor is connected.