#148 Elec Meter Point Extension

Nicholas Harker Wed 12 Feb 2014

I'd like to propose an extension to the points defined for electrical meters, outlined below. I've attached the full list of points we have vetted with our own internal projects and feel that are necessary to have in the haystack standard. The changes to the existing tags are as follows:

  1. Introduces phase:"N" for the total points to avoid queries that have tag exclusions such as and not phase when querying.
    1. We have found that tag exclusions dramatically increase the chance of unintended results for basic points, so we have attempted to eliminate them whenever possible in our internal standard.
  2. Introduces one of the following tags to each power point: real | apparent | reactive
    1. We have found that modelling the apparent and reactive power is of value in certain markets and thus should be added to the standard.
  3. Introduces a power tag to accommodate reactive and apparent power. The kw tag did not fit as well with the new points.
    1. Adding the power tag necessitated adding a consumption tag to keep tag symmetry.
    2. The kw | kwh tags have been kept to maintain legacy support. I am open to suggestions on what we do with these tags.

Consumption

  • Consumption { kwh, consumption, sensor }

Power

  • Real Power (Total) { phase:"N", kw, power, real, sensor}
  • Real Power (Phase A) { phase:"A", kw, power, real, sensor}
  • Real Power (Phase B) { phase:"B", kw, power, real, sensor}
  • Real Power (Phase C) { phase:"C", kw, power, real, sensor}
  • Apparent Power (Total) { phase:"N", power, apparent, sensor}
  • Apparent Power (Phase A) { phase:"A", power, apparent, sensor}
  • Apparent Power (Phase B) { phase:"B", power, apparent, sensor}
  • Apparent Power (Phase C) { phase:"C", power, apparent, sensor}
  • Reactive Power (Total) { phase:"N", power, reactive, sensor}
  • Reactive Power (Phase A) { phase:"A", power, reactive, sensor}
  • Reactive Power (Phase B) { phase:"B", power, reactive, sensor}
  • Reactive Power (Phase C) { phase:"C", power, reactive, sensor}

Power Factor

  • Power Factor { phase:"N", pf, sensor }
  • Power Factor (Phase A) { phase:"A", pf, sensor }
  • Power Factor (Phase B) { phase:"B", pf, sensor }
  • Power Factor (Phase C) { phase:"C", pf, sensor }

Frequency

  • Frequency { freq, sensor }

Current

  • Current (Average) { phase:"N", current, sensor }
  • Current (Phase A) { phase:"A", current, sensor }
  • Current (Phase B) { phase:"B", current, sensor }
  • Current (Phase C) { phase:"C", current, sensor }

Voltage

  • Voltage Line to Neutral (Average) { phase:"N", volt, sensor }
  • Voltage Line to Neutral (Phase A) { phase:"A", volt, sensor }
  • Voltage Line to Neutral (Phase B) { phase:"B", volt, sensor }
  • Voltage Line to Neutral (Phase C) { phase:"C", volt, sensor }
  • Voltage Line to Line (Average) { phase:"LL", volt, sensor }
  • Voltage Line to Line (Phase AB) { phase:"AB", volt, sensor }
  • Voltage Line to Line (Phase BC) { phase:"BC", volt, sensor }
  • Voltage Line to Line (Phase CA) { phase:"CA", volt, sensor }

Chris Olmsted Wed 12 Feb 2014

I like the idea of marking the total of kW. As an electrical engineer I see a few problems with the above scheme:

In general:

  1. In three phase power systems the fourth neutral wire is often labeled "N". This line can be monitored, and in that case phase: "n" would make a lot of sense for a neutral line label.
  2. We would be labeling a point phase that isn't a phase.

Specifics (including some nitpicking):

  • I agree that kw and real + power tags are redundant as kW is a unit of power and in electrical systems, real power.

    Real Power (Total) { phase:"N", kw, power, real, sensor}

    • That said, if we use the apparent and reactive tags, then it makes sense to be consistent and keep it real.
    • To maintain consistency with the kw and kwh tags, we could use kva and kvar instead or the apparent and reactive tags.
    • If kw and kwh are replaced, let's do the same for pf and expand it to power and factor.
  • The phase: "N" tag above does not represent a phase so why have a phase tag on that point at all?
    • phase: "N" would make more sense for the neutral line of a three-phase system.
    • For the Real Power (Total) point, I think total and real and power (or total and kw) tags would work.
      • Same for other "Total" and "Average" points above.
  • This convention uses "line" and "phase" interchangeably and assumes a neutral. This is only true for some three-phase systems.

    Voltage Line to Line (Phase AB) { phase:"AB", volt, sensor }

    • If we are going to venture into power systems with Haystack, I think we'll need a more comprehensive tagging model, including distinctions between things like phase, line, ground, and neutral.

Nicholas Harker Wed 12 Feb 2014

Thanks for the feedback Chris, some comments on your notes above:

In three phase power systems the fourth neutral wire is often labeled "N". This line can be monitored, and in that case phase: "n" would make a lot of sense for a neutral line label.

I agree that if that wire exists, the phase:"N" convention should be reserved to model that point, were it to be trended.

We would be labeling a point phase that isn't a phase.

The intent in re-using phase was to keep the standard to a single tag which would indicate which demand the point represents. However, I am definitely open to the idea of introducing a total tag which could be used to uniquely identify the point. Another proposed value for the total demand point had been phase:"LN", but I feel like that would also not be accurate based on your other statements.

I agree that kw and real + power tags are redundant as kW is a unit of power and in electrical systems, real power.

I personally feel that the kw and kwh tags, while certainly shorter, are not descriptive tags for the points they represent. Consider why other points are not tagged like this, why is "Airflow" not tagged cfm instead of air and flow? My vote would be to remove the kw and kwh tags in favor of the more descriptive tags.

I also like the idea of separating pf to power and factor.

This convention uses "line" and "phase" interchangeably and assumes a neutral. This is only true for some three-phase systems.

I am certainly interested in expanding the tagging model to support the different 3-phase systems. If you have additional thoughts on how the tagging could be improved to achieve this, please let me know.

Jose Gonzalez Sun 12 Jul 2015

As a suggestion; If the "service type" that the meter is connected to is identified that would shed light into the type of points outlined under it.

A string property tag for the meter Equip: {serviceType: }

Types:

3WireWye, 4WireWye, 4WireDelta, 3WireDeltaNoNeutral

Then the descriptions Nicholas mentions are easier to relate.

Right now for KW there is a tag "power" and for KWH "energy" the kw and kWh can be units of measurement for the points value and should not be a tag(unless you want it there to search for it).

apparent, reactive describes the type of reading (real can be omitted and implied be the omission).

I agree 100% with the "phase:" property tag.

VOLTAGE is a little different because it is where it is being measured(location description).

A string property tag: {measuredAt: XX (examples: AB, AC, BC, AN, BN, CN)} with(or without) a tag "voltAverage" would be very easy to search and use for reporting and aggregating.

I mentioned these because the objective from what I seen with Haystack is to make it easier to find and identify no so much to truly model piece by piece the system with tags.(all though you can do it too if you want)

This is just a perspective since I think both of you are correct in your remarks.

Looking forward to your replies.

Rick Jennings Thu 11 Apr

Hi, I would like to revisit Jose’s proposal for a “service type” considering a related proposal just introduced here.

The referenced proposal is an important step to help us identify where elec points are located within an AC electric power system. However, I believe there are more opportunities for improvement, which may address how to identify:

  1. Type of electrical service that an elec equip is installed within
  2. Specific electrical wires connected to an elec equip (e.g., Line 1, Line 2, Line 3, or Neutral)

I think Jose’s proposal for a “service type” is on the right track. I would like to offer a few suggestions:

  • The concept of “service type” applies to elec meters and other elec equip, including Uninterruptible Power Supplies, EV chargers, and VFDs
  • “service type” can be addressed with a single tag on elec equip entities
  • We should consider separating “service type” from the number or types of wires connected to an elec equip
  • We might as well now address input voltage and current nameplate (metadata) on elec equip

Preliminary tag proposal for discussion

These tags would be applied to elec equip directly or as attributes.

  • inputElecService: “ThreePhaseWye”, “ThreePhaseDelta”, or “SplitPhase”
  • inputElecWiresConnected: “L1,N”, “L2,N”, “L3,N”, “L1,L2”, “L2,L3”, “L3,L1”, “L1,L2,N”, “L2,L3,N”, “L3,L1,N”, “L1,L2,L3”, or “L1,L2,L3,N”
  • inputLineToLineVolt: Haystack defined Number with volt unit
  • inputLineToNeutralVolt: Haystack defined Number with volt unit
  • inputMaxCurrent: Haystack defined Number with ampere unit

Notes:

  • We assume that the electrical ground wire is always connected to an elec equip
  • The focus is on AC power systems, although during our review we should consider how we may apply these tags to DC power systems

Why is this important?

I have witnessed expensive electrical equipment destroyed because they were installed in an electrical system with a “ThreePhaseDelta” service instead of a “ThreePhaseWye” service as required by the manufacturer. Also, some load management and fault detection algorithms may require metadata about an electrical equipment’s input.

In conclusion, this metadata can be very helpful and even essential for commissioning and troubleshooting certain electrical equipment.

Request for feedback

This is a preliminary proposal which I would like to discuss in more detail at future Project Haystack working group meetings. Your initial feedback would be greatly appreciated to help us develop a formal proposal.

Login or Signup to reply.