Only emonPi2 CT inputs 1 and 4 work

Emoncms Installation
1

This feels like a PEBKAC problem, but for the life of me I can’t figure it out:

I have a new emonPi2 (Pi4B) with a 3-phase EmonVS (currently only hooked up to one phase - US split phase power - on V1). The system as a whole is basically working: I can login; see the phase voltage; and see the power/energy from my first CT, a 50A one from the shop, on one leg of a 240V heat pump water heater. I have stumbled my way through doubling the voltage to approximate the full 240V and logging power / energy from that input. I’ve also hooked up the pulse output from a water meter to log water usage. So far, so good.

So now that I have a basic idea of how this all works, I’m hooking up two more CTs, both 20A parts from the shop. I’ve clipped them around my hot wires, and have confirmed they’re working (both by measuring V_AC coming out of them with a DMM, and by plugging them into the CT1 input on the emonPi2 and watching the input get reported (albeit incorrectly, as they’re 20A CTs plugged into an input configured for 50A) in the Inputs list). But when they’re plugged into inputs CT2, CT3, CT5, or CT6, nothing is reported. CT4 reads accurate values (matches my kill-a-watt plug meter), despite never previously having had anything plugged into it.

I’ve plugged the next two CTs I’m installing into CT5 and CT6 inputs and power cycled the emonPi2 because I read there’s some auto-detection that happens at power-on, but to no avail. I even plugged in all 6 CTs (two 50s into CT1 and CT2; four 20s into CT3-CT6), and gave them some dummy load (only about half an amp) and power cycled with that physical setup. Stubbornly, only CT1 and CT4 will return values. The other four inputs report 0 power. They can’t be misconfigured in terms of which voltage input to use, because V2 and V3 have some residual noise on them and report a couple volts: any reading whatsoever should result in some non-zero power value being reported in http://emonpi/input/view

Still, disabled inputs seems like the most likely source of my problems. How do I determine which inputs were auto-detected, and can I force them all to be active? Is there something else I should be doing to trouble-shoot?

Thanks in advance for any pointers y’all can give me!

2

Forgot to mention: emonpiRelease: emonSD-01Feb24

And I think I’ve figured out an answer to one part of my question: in the Serial Config Tool, the console reports iCalx values for the detected CTs:

image
image2880×2422 407 KB

service-runner trigger sent for '/var/www/emoncms/scripts/serialmonitor/start.sh 115200 /dev/ttyAMA0'
Loading configuration, list (l) command sent:

firmware = emon_DB_6CT
version = 2.1.0
hardware = emonPi2
voltage = 3phase
vCal = 101.30
iCal1 = 50.00, iLead1 = 3.20
iCal2 = 50.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
pulse = 3, pulsePeriod = 100ms
RF = off
datalog = 9.80
json = off

…or just iCal1, iCal5, and iCal6 for when I only had those three after a power cycle. Interestingly, in that case, the P4 power input still worked when I hot-swapped the CT from input 6 to input 4. I don’t know if any of that is diagnostically helpful.

3

Welcome, Ben, to the OEM forum.

The emonPi2/emonTx4 3-phase configuration by default pairs the voltage and current inputs as:
CT1 - L1
CT2 - L2
CT3 - L3
CT4 - L1
CT5 - L2
CT6 - L3

So there’s your problem - no voltage on L2 & L3, power calculation comes to zero. (And if your emonVs were the single phase version, some components for L2 & L3 are omitted. :cry: )

I don’t have an emonPi2 (even though I wrote the library it uses!) so I don’t know how the serial config tool works and whether it allows you to change the pairing of current and voltage. If you can, that’s the easy way.
The second easy way is you have a 3-phase emonVs: link L1-L2-L3. It will work as 6 single phase single channel monitors, and give you the correct values for 120 V loads, but you’ll still need to double the power for 240 V loads.
The third, probably hard, way is to edit the sketch in the Emon part (not the Raspberry Pi part) of your emonPi to use the correct pairing of voltage and current. You can link any CT (current) to any voltage - the limitation is purely in the default software in the Emon part. I can give you the changes if this is what you want to do. (And you’re not the first in N.America to have this problem.)

4

Thanks so much!

I wondered if the 1-and-4 pairing was a clue:) But I talked myself out of it being due to phase voltage because L2 and L3 are both reporting about 3V. I guess there’s some input sanity checking where those are treated as exactly zero when computing power (rather than ~3V * ~500mA is ~1.5W)?

If I’m willing to edit things as you suggest, would that let me correctly monitor 240V split-phase circuits (CT1 and CT2 will both be large 240V loads, so they should use L1+L2 as their voltage) too? Or is that already built into the software, rather than being part of the CT<–>phase assignment you’re talking about, and I just need to RTFM some more? I hacked in the factor of 2 as a ‘good-enough’ option to move forward, but I do intend to eventually hook up both phases, which is why I picked the three phase emonVS.

I’m more of a hardware guy than a software guy; how much tinkering are we talking about here? ssh in and modify a config file sort of thing? I haven’t gotten that far yet, but the docs say a long press on the button will enable ssh (until next reboot?) so that should be readily doable.

P.S. Is the default binding between CT inputs and emonVS phases documented somewhere that I’ve missed (got a link?)? Probably there’s other useful information nearby that I should be reading too.

5

No, the question is: Where did the 3 V come from, and what does it look like - wave shape and phase? Because 3 V rms × 500 mA ≠ 1.5 W if the 3 V comes from random noise or the wave is somewhere close to 90° out of phase in relation to the current. The power is the average of the instantaneous samples of voltage and current multiplied together - so if you do the maths for the particular case where you have two pure sine waves 90° apart, the average over on cycle is exactly zero. If one is exactly n times the frequency of the other, the same applies. If one is pure random noise, then “big numbers” theory says the long-time average is again zero. There is a check for “acPresent” in the library - but Trystan decided for some reason not to use it in the sketch. So I think no real power detected is the more likely explanation - power rounded in the library and sent to emonCMS as an integer in watts. So < 1 W would report a zero.

Yes, the library is capable of this.

It’s a bit more involved that that. The way I’d advise (and bear in mind I’m a Chartered Electrical Engineer by profession - it’s just that as part, only part, of my job I’ve been writing software since the days of 110 baud teletypes :sob: ) is to download the Arduino IDE and the libraries you need and compile the front end sketch on your main computer, then transfer it to the Pi and thence to the Atmel-DB processor in the ‘Emon’ part. I know the Docs recommends something called platfromio, I can’t help you if you go that route, because I tried it and it screwed my machine up - once bitten, twice shy.
The instructions for setting up the IDE and libraries are here: Firmware — OpenEnergyMonitor 0.0.1 documentation

What you need to change in the file emon_DB_6CT.ino:
(Before you do, I suggest doing a test compile as it comes to prove everything works.)

Lines 289 - 294 are where you do the changes. In the emonLibDB documentation (which you downloaded), the API is explained in detail.

  EmonLibDB_set_pInput(1, 1); // Phase 1
  EmonLibDB_set_pInput(2, 2); // Phase 2
  EmonLibDB_set_pInput(3, 3); // Phase 3
  EmonLibDB_set_pInput(4, 1); // Phase 1
  EmonLibDB_set_pInput(5, 2); // Phase 2
  EmonLibDB_set_pInput(6, 3); // Phase 3

My guess for your changes based on what you’ve written will be:

  EmonLibDB_set_pInput(1, 1, 2); // Legs 1+2
  EmonLibDB_set_pInput(2, 1, 2); // Legs 1+2
  EmonLibDB_set_pInput(3, 1); // Leg 1
  EmonLibDB_set_pInput(4, 2); // Leg 2
  EmonLibDB_set_pInput(5, 1); // Leg 1
  EmonLibDB_set_pInput(6, 2); // Leg 2

We describe your supply as a single phase, split into two legs, because they come from a single centre-tapped winding on the transformer.

Note - it takes a bit longer to do the calculations using the two voltages, so the sample rate is necessarily reduced. This is automatic. You’ll still get 24 samples per channel per 60 Hz mains cycle based on all 12 CT channels in use.

Yes, here: Firmware — OpenEnergyMonitor 0.0.1 documentation

No, it’s short presses to cycle round the menu until it asks the question, and then it sticks until you do it again. :smiley:

Your problem - a big one - will be detecting what you don’t need to read immediately. There’s a huge amount of stuff here in Docs, so don’t try to take it all in unless you have a photographic memory.

6

Thanks again, Robert! That’ll keep me busy for a while.

It gave me the nudge I needed to go find the emonPi2 schematics, whereupon it became clear that ‘sketch’ means AVR code specifically, so I anticipated that part of your answer. Probably there’s a clear line in there as well for switching one of the external temp sensor inputs to pulse sensing, if I decide I want another water meter input. And then I’d have to figure out the corresponding emon changes so that’s a project for another day. I’m not sure what the “SL” refdes means (“shorting link” is my best guess), and I’m not familiar with the decal in the PCB either, but once I open the thing up it’ll be clear how to move that around.

I’d made the simplifying assumption that probably the V1 input was coupling into the adjacent V2 and V3; V2 does report slightly higher than V3. But you’re right that it could just be random noise, and it could be both together: it wouldn’t take much random noise to push the voltage measurement up to ~3V while the in-phase component coupled in from line 1 would result in <1W of measured real power. I hadn’t thought of that.

Time to go get familiar with the AVR toolchain…

7

Yes, sorry. It’s Aduino-speak for the application software.
(I’d probably use “schematic” and “layout” or collectively “drawings” for what you found. To me, ‘sketch’ when not in Arduino context means a rough hand-drawn diagram, illustration or plan.)

There’s only one pulse input set up, lines 327 & 328

  EmonLibDB_setPulseEnable(PULSE_PIN, EEProm.pulse_enable);
  EmonLibDB_setPulseMinPeriod(PULSE_PIN, EEProm.pulse_period, FALLING); // Trigger on the falling edge

Your lifeline is the emonLibDB documentation - just replicate those two lines for your second pulse input and tweak accordingly. If in doubt, look at the examples that came with the library - every API call is illustrated (though most do nothing extra/different because they set the default value!). Do read about PulseMinPeriod, because the ‘sketch’ default is often not appropriate.

Details of the solder links for pulse counting are here: Other sensors — OpenEnergyMonitor 0.0.1 documentation

There are worse. And some a lot better. Try Arduino 1.8.19 rather than 2.x.x. At least it allows your choice of editor, which 2.x doesn’t. (or which the Linux version 2.x doesn’t.)