We have just merged commits to the xeto and haystack-defs repositories that help improve elec metering for Project Haystack.

Thanks to Keith Bishop for reporting Xeto elec specs used the incorrect units for power factor. Also, thanks to Stephen Frank and members of the Labs working group for their contributions.

In the coming months we hope to stabilize the Xeto API for elec point specs. So now is still a great time for more feedback!

Hi Rick/Community,

I have a few questions:

1. What is the difference in intended use cases between the ph.points.elec/sensor.xeto & ph.points/elec.xeto libraries? It seems there are similar concepts within both.
2. What is the distinction betwen how the demand and power tags should be used? As related to the SkySpark v3.1.11 Build Notes and Project Haystack Demand definition.
3. As an example, how should a point that will carry the monthly peak demand values be tagged? This data may come from billing data imports, or calculated from trended power readings.

Please let me know if these questions should be posted elswhere.

Thanks, Sade

Hi Sade,

What is the difference in intended use cases between the ph.points.elec/sensor.xeto & ph.points/elec.xeto libraries? It seems there are similar concepts within both.

We placed what we felt were the most common electrical point specs into the ph.points library. For example, these specs include total energy and demand.

The remaining specs have been placed into the ph.points.elec library for more advanced electric power monitoring applications.

What is the distinction betwen how the demand and power tags should be used? As related to the SkySpark v3.1.11 Build Notes and Project Haystack Demand definition.

Please refer to the definitions for power and demand in the docs here.

As an example, how should a point that will carry the monthly peak demand values be tagged? This data may come from billing data imports, or calculated from trended power readings.

Assuming electricity is only in the import direction, you might want to use the Xeto spec ElecTotalImportAcActiveDemandSensor defined in the ph.points library for interval data. Please note we will likely soon be modifying this spec to clarify it is for power demand and not current demand. This change will also change how instantaneous power measurements are queried.

I am not sure what the best practice according to Project Haystack would be for modeling peak demand presented by the electric utility in a bill. Also, I am curious what others in the community think about this topic.

-Rick

Hey Rick, taking a look at what you've got so far for electric points, and a little confused about this one: // Sensor for metric of AC electric voltage ElecAcMetricVoltSensor : ElecAcVoltSensorX <abstract> {

elecAcWaveformMetric: ElecAcWaveformMetric
unit: Unit <fixed> "%"

}

Is this meant to be a base class for any sensor that measures a proportion of a type of a voltage waveform?

Hi Andrew,

Is this meant to be a base class for any sensor that measures a proportion of a type of a voltage waveform?

Yes. This sensor is abstract and requires a choice per ElecAcWaveformMetric. Each of these choices represent a measurement in % units.

Also, see the concrete implementations ElecAcLineMetricVoltSensor, ElecAcLineAvgMetricVoltSensor, ElecAcPhaseMetricVoltSensor, and ElecAcPhaseAvgMetricVoltSensor which should ideally be used in Xeto templates that you would use.

Bringing this all together you would apply the spec like this for total harmonic distortion of voltage measured between line 1 and line 2:

ElecAcLineMetricVoltSensor {
  totalHarmonicDistortion
  lineVolt: "L1-L2"
}

Please note these APIs are subject to change still.

Great, ok I think that makes sense. Another question I had is transients, I'm wondering if ElecAcPeakToPeakWaveformMagnitude or ElecAcPeakWaveformMagnitude is semantically synonymous with transient peak voltages? Some devices have event storage for transients that may include a very high resolution snapshot of peak (>256 samples/cycle) where others may just be the peak to peak average over some integration time.

I was just following the thought line of what are things I might want to call a metric about AC power that weren't percentage of power/voltage/current in a harmonic band.

Most of my experience with PQM has been with standalone units or lab settings, not long term monitoring, but as more of that seems to be built into the metering platforms... I guess we have to call scope at some point, right?

Based on this discussion and some other related topics I think there is more work for us to do on ElecAcWaveformMetric.

Another question I had is transients, I'm wondering if ElecAcPeakToPeakWaveformMagnitude or ElecAcPeakWaveformMagnitude is semantically synonymous with transient peak voltages?

We are considering to introduce semantics to differentiate between raw and steady-state waveforms. Raw waveforms would cover the very high resolution snapshots you are referring to.

If we do that, then we might want to establish that ElecAcWaveformMetric and ElecAcWaveformMagnitude apply only to steady-state waveforms, which are not semantically synonymous with transient peak voltages as far as I understand. (Although I am not 100% sure if that aligns with how these meters are implemented, so we would need to check that with a few manufacturers before freezing the API.)

Also, I think we might want to rename ElecAcWaveformMetric to be specific to power quality metrics or consider combining ElecAcWaveformMagnitude and ElecAcWaveformMetric into a single choice for describing metrics for steady state waveforms. If we combine the two, then we have another interesting problem dealing with various units.

I was just following the thought line of what are things I might want to call a metric about AC power that weren't percentage of power/voltage/current in a harmonic band.

Considering how the more common RMS voltage and current measurements use non-percent units and are technically metrics of a steady state waveform, I can see your point. Please see earlier mentioned proposals being reviewed.

Most of my experience with PQM has been with standalone units or lab settings, not long term monitoring, but as more of that seems to be built into the metering platforms... I guess we have to call scope at some point, right?

This discussion is within the scope of Project Haystack and I believe the outcome of this work is essential to Haystack's reach in critical power applications.

Take a look at ElecAcSpectralContent which already exists. I am wondering how we might use this choice if we introduce a distinction between raw and steady state waveforms to address the use cases that you mention.

Andrew, what do you think about these ideas, specifically the semantics for distinguishing raw vs. steady state waveforms?

Does anyone else have feedback for us to consider?

Thanks!

Weighing in on a couple points made here in the past.

I am not sure what the best practice according to Project Haystack would be for modeling peak demand presented by the electric utility in a bill. Also, I am curious what others in the community think about this topic.

demand, in general, is used to discuss peak (maximum) required power and (that is, energy within a specific interval). In my opinion, if you only have a monthly demand reading, you would still just tag it as demand. Demand points should be rolled up using MAX.

In practice, we either have interval demand, which is the average power within a repeating interval (e.g. a fixed or rolling window) or we have peak demand, which is the maximum observed interval demand within a larger time span (e.g. max. 15-min demand within 1 month). We may want to consider subtyping demand into interval and peak, which also allows interval demand to be further subtyped later (if desired) based on how the interval is calculated.

If we do that, then we might want to establish that ElecAcWaveformMetric and ElecAcWaveformMagnitude apply only to steady-state waveforms, which are not semantically synonymous with transient peak voltages as far as I understand.

I would agree with this. With AC power quality meters, most of the time the time series data are properties of the periodic waveform, either basic measurements (like magnitude) or computed metrics (like total harmonic distortion). I understand part of Rick's challenge has been coming up with words (like "metric") to describe, in the abstract, what some of these quantities are. In the context of the work done so far, they really are waveform metrics, that is, computed characteristics that describe the waveform:

• Total harmonic distortion
• Total demand distortion
• Crest factor
• Etc.

There are also metrics that require computation across multiple waveforms:

• Power factor (voltage vs. current, or active vs. reactive power)
• Displacement power factor
• Distortion power factor
• Imbalance (across all phase/line voltages or phase/line currents)

(I should note that right now we treat power factor as a primary measurement quantity, which really it is more of a metric like imbalance. We should consider re-classifying it as a metric.)

Hi-frequency snapshots of transient voltage, current, power probably deserve to have something other than the ac or dc tags, and probably need a different framework for any metrics that apply to them (e.g. transient peak voltage within a time interval or window).

Hi Stephen,

Thanks for the feedback. We seem to agree on some key topics and I look forward to any additional feedback.

Has Project Haystack defined how to specify a rollup for point entities?

If so, I would not know how to specify a rollup using Haystack conventions. Specifically I wonder how someone would know when is the start and end timestamp associated with each timestamp.

FYI, some electric meters expose rolled up data (e.g., max voltage based on a minutely interval).

Demand points should be rolled up using MAX.

I do not think it makes sense to use points to model electric utility billing determinants (e.g., peak demand) because the his samples lack context to be meaningful.

For example, to understand a 500kW sample at 12:00:00AM on July 15, 2025 you would need to know the specific utility's bill start and end times. It is important to be able to get to the desired context without time consuming to develop queries and data transformation scripts.

I would propose we introduce events to Project Haystack, which each contain data required for the necessary context (e.g., start time, end time, peak demand, total energy consumed, etc.).