EmonPi2 12CT not populating Energy attributes

Hi all,

I have an EmonPi2 along with 4x EmonTx. The EmonPi is the 12CT variant, however I’ve noticed when initialising the device with the 12CT firmware, the E1-6 and E7-12 are not populating values from the firmware.

When I flash it with the 6CT firmware the E1-6 populate and calculate the kWh as expected, I found another topic - but specific to the EmonTx with the same issue - however, the advice was to move the EmonTx from USB to RF input to the EmonPi, obviously I don’t have that option for the built-in expansion board.

How might I make the EmonPi populate all E1-6 and E7-12 energy attributes from the 12CT firmware?

Thanks!

Ref link to other thread: Tx4 CT6 not sending Energy data

Looking at the source code for the sketch, it should be, if it’s been compiled with ENABLE_ENERGY defined. I don’t know (and I’ve never found where it’s documented) what the options chosen for the pre-compiled versions are.

This is one for @TrystanLea to answer.

If you want to recompile and upload it, the line to change is 35 - just uncomment it.

Judging based on the other thread I’m not sure that would solve the issue, as it appears that the internal serial connection truncates the message?

Hence the suggestion to send the data over RF?

Really?

firmware = emon_DB_12CT
version = 1.2.0

hardware = emonTx4
voltage = 1phase
No EEPROM config
vCal = 101.30
iCal1 = 20.00, iLead1 = 3.20
iCal2 = 20.00, iLead2 = 3.20
iCal3 = 20.00, iLead3 = 3.20
iCal4 = 20.00, iLead4 = 3.20
iCal5 = 20.00, iLead5 = 3.20
iCal6 = 20.00, iLead6 = 3.20
iCal7 = 20.00, iLead7 = 3.20
iCal8 = 20.00, iLead8 = 3.20
iCal9 = 20.00, iLead9 = 3.20
iCal10 = 20.00, iLead10 = 3.20
iCal11 = 20.00, iLead11 = 3.20
iCal12 = 20.00, iLead12 = 3.20
pulse = off
RF = on, rfBand = 433 MHz, rfGroup = 210, rfNode = 28, rfPower = 25, rfFormat = datalog = 9.80
json = off
vrefa = 1.0274
MSG:1,V1:240.72,F:50.63,P1:0,E1:0,P2:0,E2:0,P3:0,E3:0,P4:0,E4:0,P5:0,E5:0,P6:0,E6:0,P7:0,E7:0,P8:0,E8:0,P9:0,E9:0,P10:0,E10:0,P11:0,E11:0,P12:0,E12:0
MSG:2,V1:240.71,F:50.13,P1:0,E1:0,P2:0,E2:0,P3:0,E3:0,P4:0,E4:0,P5:0,E5:0,P6:0,E6:0,P7:0,E7:0,P8:0,E8:0,P9:0,E9:0,P10:0,E10:0,P11:0,E11:0,P12:0,E12:0
MSG:3,V1:240.63,F:50.12,P1:0,E1:0,P2:0,E2:0,P3:0,E3:0,P4:0,E4:0,P5:0,E5:0,P6:0,E6:0,P7:0,E7:0,P8:0,E8:0,P9:0,E9:0,P10:0,E10:0,P11:0,E11:0,P12:0,E12:0

I haven’t got an emonTx5, nor 12 c.t’s to prove all 12 channels at once, and I haven’t got my c.t. test rig set up anyway. But it seems to be OK so far.

Yup - newly flashed, again, with 1.2.0 12CT:

firmware = emon_DB_12CT
version = 1.2.0

hardware = emonPi2
voltage = 1phase
vCal = 101.30
iCal1 = 100.00, iLead1 = 3.20
iCal2 = 50.00, iLead2 = 3.20
iCal3 = 50.00, iLead3 = 3.20
iCal4 = 50.00, iLead4 = 3.20
iCal5 = 50.00, iLead5 = 3.20
iCal6 = 20.00, iLead6 = 3.20
iCal7 = 20.00, iLead7 = 3.20
iCal8 = 20.00, iLead8 = 3.20
iCal9 = 20.00, iLead9 = 3.20
iCal10 = 20.00, iLead10 = 3.20
iCal11 = 20.00, iLead11 = 3.20
iCal12 = 20.00, iLead12 = 3.20
pulse = 1, pulsePeriod = 0ms
RF = off
datalog = 9.80
json = off
MSG:4,V1:240.02,F:49.98,P1:151,P2:79,P3:61,P4:13,P5:0,P6:0,P7:0,P8:1,P9:0,P10:0,P11:0,P12:0
MSG:5,V1:239.76,F:49.98,P1:151,P2:79,P3:61,P4:13,P5:0,P6:0,P7:0,P8:1,P9:0,P10:0,P11:0,P12:0

I think the key difference here is RF is on in your example, and off in mine due to it being embedded in the EmonPi. As per this answer: Tx4 CT6 not sending Energy data - #7 by TrystanLea

Have you actually read the source code? Please explain to me how having R.F. on or off affects adding the energy output to the JSON string.

Did you recompile and upload your new version of the front-end sketch, or just reload the pre-compiled version that does not have ENABLE_ENERGY defined?

The pre-compiled firmware matches the source code, it is commented out and so the energy values are not printed. For the emonTx4 with an ESP8266 WiFi module the length of the line made a difference for reliability. It’s probably fine to un-comment and print these on the emonPi2.

1 Like

I suppose once you know, that’s obvious; but would be nice to see it mentioned somewhere.

1 Like

So I’ve tried compiling with PIO as per the docs, but it seems there is a library problem?

The code is using Wire1 but further up it has #include <Wire.h>

Processing Upload_USART (platform: atmelmegaavr; framework: arduino; board: AVR128DB48)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelmegaavr/AVR128DB48.html
PLATFORM: Atmel megaAVR (1.9.0) > AVR128DB48
HARDWARE: AVR128DB48 24MHz, 16KB RAM, 128KB Flash
PACKAGES:
 - framework-arduino-megaavr-dxcore @ 1.5.6
 - tool-avrdude @ 1.70100.0 (7.1.0)
 - toolchain-atmelavr @ 3.70300.220127 (7.3.0)
Converting emon_DB_12CT.ino
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 22 compatible libraries
Scanning dependencies...
Dependency Graph
|-- RFM69_LPL @ 0.0.0+20250711120146.sha.2380f1a
|-- emonLibDB @ 0.0.0+20250711120147.sha.c9bd452
|-- emonEProm @ 1.0.0+sha.b0859d6
|-- SSD1306Ascii @ 1.3.5+sha.c43eaa9
|-- EEPROM @ 2.1.3
|-- Wire @ 2.0.10
Building in release mode
Compiling .pio/build/Upload_USART/src/emon_DB_12CT.ino.cpp.o
Compiling .pio/build/Upload_USART/lib196/RFM69_LPL/RFM69_LPL.cpp.o
Compiling .pio/build/Upload_USART/libb81/emonLibDB/emonLibDB.cpp.o
Compiling .pio/build/Upload_USART/lib9f1/emonEProm/emonEProm.cpp.o
Compiling .pio/build/Upload_USART/libbe8/Wire/Wire.cpp.o
Compiling .pio/build/Upload_USART/libbe8/Wire/twi.c.o
Compiling .pio/build/Upload_USART/libbe8/Wire/twi_pins.c.o
Compiling .pio/build/Upload_USART/libc14/SSD1306Ascii/SSD1306Ascii.cpp.o
Archiving .pio/build/Upload_USART/lib196/libRFM69_LPL.a
Compiling .pio/build/Upload_USART/FrameworkArduino/Tone.cpp.o
Compiling .pio/build/Upload_USART/FrameworkArduino/UART.cpp.o
Archiving .pio/build/Upload_USART/lib9f1/libemonEProm.a
Archiving .pio/build/Upload_USART/libbe8/libWire.a
Archiving .pio/build/Upload_USART/libb81/libemonLibDB.a
/Users/mylesgray/Documents/scratch/avrdb_firmware/emon_DB_12CT/emon_DB_12CT.ino: In function 'void setup()':
/Users/mylesgray/Documents/scratch/avrdb_firmware/emon_DB_12CT/emon_DB_12CT.ino:175:3: error: 'Wire1' was not declared in this scope
   Wire1.swap(2);
   ^~~~~
/Users/mylesgray/Documents/scratch/avrdb_firmware/emon_DB_12CT/emon_DB_12CT.ino:175:3: note: suggested alternative: 'Wire'
   Wire1.swap(2);
   ^~~~~
   Wire
*** [.pio/build/Upload_USART/src/emon_DB_12CT.ino.cpp.o] Error 1
Indexing .pio/build/Upload_USART/lib196/libRFM69_LPL.a
Indexing .pio/build/Upload_USART/lib9f1/libemonEProm.a
Indexing .pio/build/Upload_USART/libbe8/libWire.a
Indexing .pio/build/Upload_USART/libb81/libemonLibDB.a
================================================================== [FAILED] Took 4.37 seconds ==================================================================

I don’t use platformio, it screwed my system up when I tried it, I recommend not using it; I can only suggest you install and use the tried and tested Arduino IDE.

I found a fix for PlatformIO - it needed a build flag added in the platformio.ini config - amended to be:

build_flags = -DTWI_USING_WIRE1 -DUSING_OPTIBOOT  ; Upload via uart

With that -DTWI_USING_WIRE1 and running pio run it builds as expected, grabbed the firmware.hex from the build folder, uploaded through the Web UI and seeing all 12 Energy parameters!

2 Likes

Thanks @emonuser should I add this to all the example platformio.ini files e.g: avrdb_firmware/emon_DB_12CT/platformio.ini at master · openenergymonitor/avrdb_firmware · GitHub any thoughts on how I could also specify to use external 24 Mhz external crystal ?

Hey Trys,

I tried building a few of the firmware files as-is, and they compile just fine, the challenge is when compiling with EMONPI2 defined - then we get the Wire1 error.

I edited the platformio.ini file as above, and compiled for EMONTX5 and it seems unaffected, so I think it’s safe to include by default.

On your question on the external crystal - unsure, you mean in the firmware or in PIO?

I dug up this with a quick search, but don’t think it’s relevant: Using external XTAL as clock source? - #2 by maxgerhardt - PlatformIO Community