Power factor isn’t normally sent to emonCMS by default, but there’s absolutely no reason why it cannot be treated in exactly the same way as any other variable. But you can’t quite compare it with an accumulated value like energy. You’d be able to watch it, but emonCMS doesn’t have alarms or anything like that. That would need to be done outside of emonCMS, and others here are better placed to tell you about that.
You’ll have the items you need, but if I understand you correctly (and I’m only trying to infer what you’re connecting where from what’s written), that won’t give you real power or p.f. if you attach the 3 c.t’s to the one emonTx.
I think your set-up will be:
1-off emonPi with 5 V USB power and one c.t. and a.c. adapter to measure real power on phase 1, and the optical sensor for your meter pulses.
2-off emonTx’s, each with one c.t. and a.c. adapter to measure real power on phases 2 & 3.
(But you can put the optical sensor on whichever you like.)
You’ll need to edit the software in the emonTx’s and in the front end (the “emon” part) of the emonPi to report the power factor. And you’ll need a programmer and leads to do that.
The question that drives that is, how accurate is the balance of your phase voltages? If it’s “good enough”, you could get away with a Raspberry Pi, and emonTx and connect the two by wires. The 3-phase sketch phase shifts the phase 1 voltage in software to provide a phase reference to the other two phase currents, but it can’t know the amplitude difference, which is where the error comes in.
Also, the two emonTx’s monitor continuously and report every 10 s (approx), the present emonPi front end software is still the ‘discrete sample’ version, though I’ve had a continuous monitoring version working for many months now, it’s yet to be released because it requires major changes everywhere. I’m still writing documentation.
If the emonPi sampling for 200-300 ms every 5 or 10 s is a problem (and if you have rapidly fluctuating loads, it could well be), and you can’t wait for the emonPiCM, then replace the emonPi with a third emonTx and an emonBase (essentially a Raspberry Pi with a radio receiver, or an emonPi minus the ‘emon’ part).
Alternatively, if you’ve got the expertise in-house, what about a stand-alone 3-phase meter with a Modbus output, which with the addition of a Modbus-Ethernet converter, will feed into your LAN and you can have a RPi or any server running emonCMS where you like.
One immediate advantage I can see for this is the meter will most likely give you vars and kvarh, which the emonTx/emonPi can’t calculate.