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!