I was going through the Xeto specs and noticed that we have power factor units listed as “%”. xeto spec

I understand that some people view power factor that way, but I believe it to be incorrect.

Power factor is the ratio of real power/apparent power or the cosine of the angle between voltage and current. Cosine always produces an output -1 to 1 (not a percentage).

Wikipedia says: "power factor is by definition a dimensionless number between -1 and 1."

The international standards groups IEC and IEEE both use -1 to 1.

• IEC uses the decimal format (0.80) in its standards example
• IEEE also uses the decimal format (0.866) in its standards example

Using "%" for power factor is also inconsistent with the units database (unit db) where we have:

-- dimensionless --
power_factor,pf

I also took a look at how 4 building submeter companies handle this:

• Siemens: 0 to 1 (no units). (ref page 108)
• Schnieder Electric: it seems that this may be a source of the percentage issue. They allow a number between -1 and 1 or as a percentage from -100% to 100% (ref)
• Eaton: -1 to 1 (no units) (ref page 89)
• Veris: 0 to 1 (no units) (ref page 24)

I recommend that we update the spec for power factor points to either not include a unit or use the existing "pf" unit.

Hi Keith,

Thanks for feedback.

I agree we should have the power factor specs default to being in the range of -1 to 1 without units. I mistakenly used the "%" units when I made those Xeto specs and I will make that change.

While we are on this topic, do the items below make sense?

• Angle of voltage and angle of current specs have default units in "deg" and may be negative. (Note: Sometimes in practice this angle is referred to as leading or lagging.)
• THD of voltage and THD of current have default units in "%" units in the range of 0% to 100%.
• Voltage imbalance and current imbalance are measured in "deg" units. (If so, then I also need to make updates for this)

THD = Total harmonic distortion

Does anyone else have feedback on these ideas?

• Agree that PF should be unitless
• Angle is typically expressed in degrees, but in theory could be in radians; is there a way to set a family of units ("angle" units) rather than just degrees?
• THD can also be unitless but is typically expressed in percent; recommend normalizing on percent
• Voltage and current imbalance (or "unbalance") is expressed in percent: see this explanation of the math

Hi Stephen, thanks for the feedback.

We will update the PF specs to be unitless.

As of now we model the imbalance and THD specs associated with voltage and current using percent units and probably we will keep it that way. I have not dealt with voltage and current imbalance before and appreciate the explanation.

Let's defer to Brian on if we can set a family of units rather than just degrees.

Also, feedback from others on these topics is welcome.

The earlier feedback from Keith and Stephen has been applied. Thanks again for their support!

However, today Project Haystack still does not clarify what negative or positive power factor (pf) means exactly.

We discussed this before and how we might not want to because of the following different electric meter implementations:

1. Negative pf is for exported power. Positive pf is for imported power. (Or perhaps negative pf is for imported power and positive pf is for exported power?)
2. Negative pf means that the current leads the voltage. Positive pf means that the current lags the voltage.

After more thought I think we should adopt (2) for Project Haystack’s normalization of pf. This aligns with Keith’s earlier comments that power factor is the cosine of the angle between voltage and current. Also, it helps normalize data from various meter implementations so that other application logic does not need to, which is the intention of Project Haystack.

In the case of (1) I believe two data points would need to be modeled – one for the manufacturer specific data point and one for the Haystack normalized data point that is a computed point based on the manufacturer specific data point. It would be important that the manufacturer specific data point does not have tags necessary for the Project Haystack normalized data point.

How does this proposal sound to the community? Does anyone foresee a problem trying to normalize (1) to (2)?

Thanks!