power factor

[SteveMarquess2]

With apologies to David for piling on, here's another non-urgent query. I'm seeing occasional implausible power factors in the default Individual CT Data dashboard:

A pf of .4 is waaaay lower than I thought I'd ever see here, especially on a load center that has almost exclusively 240V large appliance circuits. This screenshot shows the unbelievable pf on CT2, but at other times it's been other CTs. Then I can come back a little later and they're all .95+, i.e. it's pretty intermittent. I've also seen PFs as low as .1-ish. Good thing I have a residential tariff and don't get dinged for power factor.

So I dug out one of my old power quality monitors, a Amprobe HA-2000 Harmonalyzer. Watched quite a while (multiple samples) through the same time period in the screenshot, it consistently showed a pf of .99 on the CT2 conductor.

Also ran power_monitor.py --mode terminal for quite a while afterwards, it never showed low PFs.

The Amprobe HA-2000 doesn't do continuous PF monitoring, so I suppose I should drag out the Dranetz 658 and see if it still works. But I'm finding it hard to believe my PF on that panel is getting that low even for brief intervals. Perhaps some artifact of the fact that this panel is backfed by a PV inverter that is hovering around the break even threshold? Thoughts anyone?

[David00]

Steve, thanks for bringing this up. I think it's happening because there is very little current flowing on the conductor that the CT is monitoring. To get a good PF reading, we'll have to have a good quality measurement of the amperage and voltage waves. In your screenshot, I can see that the amperage on both CT1 and 2 have dropped down to near zero, and when this happens, the sample points for the amperage wave suck because it's too low for the intended resolution of the sensor.

The only "fix" I can think of is to not generate a PF value when the measured amperage is too low, but this minimum threshold in terms of amperes will vary based on the sensor used.

[SteveMarquess2]

Ok, makes sense. Fortunately I don't really care about PF, as for this application I know it's always very close to one and not an issue in any event. It's just an esthetic glitch ... here's another even more egregious example:

These CTs are on the two 200A service entrance panels for a building with true 400A (320A continuous) service, and those conductors could potentially see 100A+. But, one SE is backfed with PV designed for average net zero, so that panel will see extended periods with very low net wattage at least twice a day. In hindsight I should have used 100A or 150A CTs. Part of my reason for the 200A CTs is inspection; the inspectors are big on ratings and may not be convinced that a 100A CT is still safe on a conductor carrying 200A. I'll have enough of an argument as it is with use of CTs at all, and their UL listing.

[David00]

Yikes! I'd personally rather have no data than bad data, so, I've just implemented a fix for this, which you can pull down with the same git fetch && git pull that I shared in the other discussion.

Alternatively, you can set the watts_cutoff_threshold to a higher value for the CT channel in the config to get rid of all low values on that channel (including PF, power, and amperage) if the measured power falls below the watts_cutoff_threshold.

The fix I just pushed handles the case where watts_cutoff_threshold is set really low and the data is not good enough to calculate pf.

[David00]

Also, on the subject of CT rating, it's ok if the current exceeds the rating of the CT. The CT core itself just becomes saturated and won't report accurately, but there's no risk to the CT or the monitoring system in this case. While the CTs don't have the UL stamp, they are all UL certified and I can provide the certification details if needed - just shoot me an email!

[SteveMarquess2]

One I figured out I needed to copy over the new plugin_handler.py I get a cleaner PF:

The PF pf .88 is still suspiciously low, but so are the amps.