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:
Introduces phase:"N" for the total points to avoid queries that have tag exclusions such as and not phase when querying.
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.
Introduces one of the following tags to each power point: real | apparent | reactive
We have found that modelling the apparent and reactive power is of value in certain markets and thus should be added to the standard.
Introduces a power tag to accommodate reactive and apparent power. The kw tag did not fit as well with the new points.
Adding the power tag necessitated adding a consumption tag to keep tag symmetry.
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 OlmstedWed 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:
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.
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 HarkerWed 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 GonzalezSun 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: }
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 JenningsThu 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:
Type of electrical service that an elec equip is installed within
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”
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.
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:
phase:"N"
for the total points to avoid queries that have tag exclusions such asand not phase
when querying.real
|apparent
|reactive
power
tag to accommodate reactive and apparent power. Thekw
tag did not fit as well with the new points.power
tag necessitated adding aconsumption
tag to keep tag symmetry.kw
|kwh
tags have been kept to maintain legacy support. I am open to suggestions on what we do with these tags.Consumption
{ kwh, consumption, sensor }
Power
{ phase:"N", kw, power, real, sensor}
{ phase:"A", kw, power, real, sensor}
{ phase:"B", kw, power, real, sensor}
{ phase:"C", kw, power, real, sensor}
{ phase:"N", power, apparent, sensor}
{ phase:"A", power, apparent, sensor}
{ phase:"B", power, apparent, sensor}
{ phase:"C", power, apparent, sensor}
{ phase:"N", power, reactive, sensor}
{ phase:"A", power, reactive, sensor}
{ phase:"B", power, reactive, sensor}
{ phase:"C", power, reactive, sensor}
Power Factor
{ phase:"N", pf, sensor }
{ phase:"A", pf, sensor }
{ phase:"B", pf, sensor }
{ phase:"C", pf, sensor }
Frequency
{ freq, sensor }
Current
{ phase:"N", current, sensor }
{ phase:"A", current, sensor }
{ phase:"B", current, sensor }
{ phase:"C", current, sensor }
Voltage
{ phase:"N", volt, sensor }
{ phase:"A", volt, sensor }
{ phase:"B", volt, sensor }
{ phase:"C", volt, sensor }
{ phase:"LL", volt, sensor }
{ phase:"AB", volt, sensor }
{ phase:"BC", volt, sensor }
{ 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:
phase: "n"
would make a lot of sense for a neutral line label.phase
that isn't a phase.Specifics (including some nitpicking):
kw
andreal
+power
tags are redundant as kW is a unit of power and in electrical systems, real power.apparent
andreactive
tags, then it makes sense to be consistent and keep itreal
.kw
andkwh
tags, we could usekva
andkvar
instead or theapparent
andreactive
tags.kw
andkwh
are replaced, let's do the same forpf
and expand it topower
andfactor
.phase: "N"
tag above does not represent a phase so why have aphase
tag on that point at all?phase: "N"
would make more sense for the neutral line of a three-phase system.total and real and power
(ortotal and kw
) tags would work.Nicholas Harker Wed 12 Feb 2014
Thanks for the feedback Chris, some comments on your notes above:
I agree that if that wire exists, the
phase:"N"
convention should be reserved to model that point, were it to be trended.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 atotal
tag which could be used to uniquely identify the point. Another proposed value for the total demand point had beenphase:"LN"
, but I feel like that would also not be accurate based on your other statements.I personally feel that the
kw
andkwh
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 taggedcfm
instead ofair and flow
? My vote would be to remove thekw
andkwh
tags in favor of the more descriptive tags.I also like the idea of separating
pf
topower
andfactor
.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:
I think Jose’s proposal for a “service type” is on the right track. I would like to offer a few suggestions:
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 unitinputLineToNeutralVolt:
Haystack defined Number with volt unitinputMaxCurrent:
Haystack defined Number with ampere unitNotes:
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.