|
|
Post by altitech on Oct 7, 2021 18:25:39 GMT
It was nice chatting with the Redfish development team on one of the follow up zoom meeting on Wednesday with Legrand. As promised, here are some potential sensors that could be added to ReadingType/ReadingUnit. The only one requirement we have now is for HumidityAbs which is measured in g/m^3. "Useful" represents sensor readings we can also provide today. "Ideas" represent sensors that could be useful in the future, particularly for remote data center monitoring.
ReadingType: - Needed: HumidityAbs // Absolute humidity, (Density) in grams per cubic meter (g/m^3) - Useful (may also be placed in other schemas): ApparentEnergy // Apparent Energy, Volt-Ampere hours (VAh) PhaseAngle // Leading/Lagging Current phase angle in degrees, This also determines the load type for and outlet (0 Deg = Resistive, +Deg = Inductive, -Deg = Capacitive) UnBalanceAmps // 3-Phase un-balanced Current (%, 0 = normal) UnBalanceVolts // 3-Phase un-balanced Voltage (%, 0 = normal) ReactivePower // Reactive Power, Volt Amperes reactive (VAR) ReactiveEnergy // Reactive Energy, Volt Ampere reactive hours (VARh) - Ideas: Acceleration // Acceleration in meters per second squared (m/s^2) Vibration // Vibration in G's - Dynamic (i.e. current site / enclosure vibration) Shock // Shock in G's. - Static (i.e. maximum shock device has encountered) Radiation // Radiation, Sieverts (Sv = J/kg) ReadingUnit: (adjust as needed) NoUnits // Explicit unitless measurement (proposal) VAh // Apparent Energy, Volt-Ampere hours (VAh) G // Acceleration, G-force (g) VAR // Reactive Power, Volt Amperes reactive (VAR) VARh // Reactive Energy, Volt Ampere reactive hours (VARh) g/m3 // grams per cubic meter (g/m^3) Maybe register other SI units as well to get a baseline format (min, s, hr, J, N, cd, m/s2 etc...) Best Regards, Bill
|
|
|
|
Post by jautor on Oct 8, 2021 20:58:17 GMT
Hi Bill, Yes, it was a great discussion and thanks again for showing up to make that post-webinar Roundtable a productive session. I reached the same conclusion on the definition of "AbsoluteHumidity" and I've opened an issue to get that added to the next release of the Sensor schema. I'm going to divide your list into two replies here for clarity... First, as mraineri explained during the roundtable call, if you need to create a Sensor instance that does not match an existing definition of `ReadingType`, there are two ways to proceed. First, as we're doing now, is to bring those missing types to our attention so that we can add them to the standard types for industry-level interoperability. Second, if the sensor is something unique, proprietary, or otherwise non-standard, you can just create a Sensor resource without the `ReadingType` property. That resource is then free to use any `ReadingUnits` value as necessary, because at that point you are not bound by the standard conformance rules (out of scope / un-specified). We like that answer as it gives clients a clear indication of when assumptions can be made about the sensor's purpose. So for sensors without a defined `ReadingType`, we don't have to call out defined units - although its highly recommended that you use a UCUM string value for `ReadingUnits`. From your list of "ideas", let's see if we can get anyone else to chime in with feedback. We want to make sure the definitions are common and we get the normative unit definitions "correct". I will take your list, create some descriptions and post them back here for others to comment. Thanks for the feedback! Jeff |
|
|
|
Post by jautor on Oct 8, 2021 21:24:00 GMT
- Useful (may also be placed in other schemas):
ApparentEnergy // Apparent Energy, Volt-Ampere hours (VAh) PhaseAngle // Leading/Lagging Current phase angle in degrees, This also determines the load type for and outlet (0 Deg = Resistive, +Deg = Inductive, -Deg = Capacitive) UnBalanceAmps // 3-Phase un-balanced Current (%, 0 = normal) UnBalanceVolts // 3-Phase un-balanced Voltage (%, 0 = normal) ReactivePower // Reactive Power, Volt Amperes reactive (VAR) ReactiveEnergy // Reactive Energy, Volt Ampere reactive hours (VARh) ReadingUnit: (adjust as needed) VAh // Apparent Energy, Volt-Ampere hours (VAh) VAR // Reactive Power, Volt Amperes reactive (VAR) VARh // Reactive Energy, Volt Ampere reactive hours (VARh) g/m3 // grams per cubic meter (g/m^3)
Hi Bill, for these sensor ideas - all related to electrical topics and resources, I wanted to make a separate reply to address them... We have properties in Sensor to cover Apparent / Reactive Power, which show up alongside the `Reading` (for real power) in the Sensor excerpts in Circuit and Outlet. We don't have those two included in the "energy" excerpts, but we can certainly add those if that's desired. (EDIT - those properties are tied to power reporting, not energy (kW vs kWh) - so we'd have to create new properties that follow that pattern if this is desired) For the UnBalanceAmps, UnBalanceVolts, and PhaseAngle - those could be covered with the existing "Percent" ReadingType - but I've also got this topic as an open question - because in order to search for "types of readings" you would want these explicitly defined, and not just grouped under "stuff measured in percent units". Regardless, in order to surface those, we would need to add properties for them. Would those appear in particular Circuit instances (I assume so), or would they only be reported at an "equipment" level, such that we should add them to PowerDistributionMetrics? We can do either (or both, if necessary) - and that's easy to add, we just need to get some description text to explain the usage - I assume none of those are valid unless it's a 3-phase circuit... Jeff |
|
|
|
Post by altitech on Oct 13, 2021 16:44:55 GMT
Hi Jeff, So sorry for the long delay. Unbalanceed readings are definitely 3 phase only readings. Phase Angle is the angle between Current and Voltage waveforms and apply to single phase inlet and outlet loads. Legrand Server Technology products use this to show the load type for each outlet (Capacitive, Inductive or Resistive). Legrand Raritan products display the phase angle directly. Seems like this can be consolidated into a PhaseAngle or PhaseShift reading but it should describe phase angle between leading/lagging current and voltage. Perhaps you might be able to come up with a better name: en.wikipedia.org/wiki/Leading_and_lagging_currentI've been hesitant to add sensors without a defined ReadingType because once customers begin using this, it might be difficult for them to switch to a registered version later. Many units in the field are code-locked by customers for asset management purposes. You can imagine large companies with s set of mixed (tracked) units, some with perhaps an older customized sensor and others with newer published sensors. I wonder how their management software / scripts can easily handle these variances for the same reading. Redfish should really create one standard everyone adheres to. Just learned we have a Particle sensor. The ReadingUnits is a mass concentration measurement in µg/m3. Let me know if you might be able to slip that in. Best Regards, Bill |
|
|
|
Post by altitech on Oct 13, 2021 17:54:07 GMT
Jeff,
If you decide to add the Apparent/Reactive energy components, they are metrics provided on some of our products. These are for customers that need enhanced power quality metrics. To my knowledge these were added because of certification requirements to meet new power quality metric standards. However, their prevalence in the marketplace is unknown to me at this time.
This would need to augment existing schemas with energy readings as you mentioned. They can also be reset like any energy reading. Likewise, ReactivePower would need to augment existing power readings.
Bill
|
|
|
|
Post by jautor on Oct 19, 2021 15:06:12 GMT
So talking with some of my folks, here's what I will propose - if this makes sense, I'll take it to the DMTF to get into the schema: - ApparentEnergy, ReactiveEnergy - add two properties to Sensor and include them in the "Energy" sensor excerpt, so they appear in Circuit and elsewhere as part of the "EnergykWh" object - following the pattern of ApparentVA and ReactiveVAR in the "Power" sensor excerpt object.
- ReactivePower - this should be covered already in the "Power" excerpt...
- UnbalancedVoltage, UnbalancedCurrentAmps - add two new sensor excerpts for these (percent units) in Circuit as these have a reading as well as expected thresholds (which may be user-settable).
- PhaseAngleDegrees - New property (not a Sensor) in Circuit, reported in degrees units.
So the "EnergykWh" object in Circuit, with everything implemented, would look like:
"EnergykWh": {
"DataSourceUri": "/redfish/v1/PowerEquipment/RackPDUs/1/Sensors/EnergyA",
"Reading": 325675,
"ApparentkVAh": 2345,
"ReactivekVARh": 674
},
Note that for consistency I've defined the ApparentEnergy and ReactiveEnergy in (equivalent to) kWh units...
And a 3-phase Circuit instance could now have these new properties:
"PhaseAngleDegrees" 15,
"UnbalancedVoltage": {
"DataSourceUri": "/redfish/v1/PowerEquipment/RackPDUs/1/Sensors/BalanceVolts1",
"Reading": 9
},
"UnbalancedCurrentAmps": {
"DataSourceUri": "/redfish/v1/PowerEquipment/RackPDUs/1/Sensors/BalanceAmps1",
"Reading": 14
},
Does that all make sense?
It didn't seem like the phase angle would have thresholds and other sensor-level support, so just made it a simple property. The unbalanced voltage/current are probably a "Synthesized" sensor (not a physical one) - but those may have service or user-defined thresholds assigned, so I made them Sensor excerpts. Note that if you don't need the thresholds, you can just show the Reading alone and not populate the DataSourceUri (and therefore no Sensor resource behind it).
Jeff
|
|
|
|
Post by altitech on Oct 19, 2021 17:42:47 GMT
Hi Jeff,
That looks really good. Spot on with Apparent/Reactive Energy, Reactive Power and Unbalanced Voltage/CurrentAmps. Unbalanced Current/Voltage is definitely a 3 phase "mains" circuit sensor with potential thresholds. This is synthesized based on readings from the 3 phase inlet CT's and how they are wired (delta/wye).
PhaseAngleDegrees should be just fine as the sign will determine inductive/capacitive loads and 0 for a pure resistive load. However, after review, this metric should only apply to outlet loads, not mains circuits. This can be either single phase (typical) or 3 phase. We use a custom test cord with a high voltage cap to simulate low power factors (<0.02). This creates a leading (current) phase shift on specific outlets indicating an inefficient capacitive load. The reading should probably be listed in the same category as PowerFactor on outlets as both use the phase angle component. I concur the at this time we do not have defined thresholds for the phase angle sensor as PowerFactor typically accommodates this.
Bill
|
|
|
|
Post by altitech on Oct 21, 2021 18:14:34 GMT
|
|
|
|
Post by jautor on Oct 26, 2021 3:44:17 GMT
PhaseAngleDegrees should be just fine as the sign will determine inductive/capacitive loads and 0 for a pure resistive load. However, after review, this metric should only apply to outlet loads, not mains circuits. This can be either single phase (typical) or 3 phase. We use a custom test cord with a high voltage cap to simulate low power factors (<0.02). This creates a leading (current) phase shift on specific outlets indicating an inefficient capacitive load. The reading should probably be listed in the same category as PowerFactor on outlets as both use the phase angle component. I concur the at this time we do not have defined thresholds for the phase angle sensor as PowerFactor typically accommodates this. Bill Bill, Do you think PhaseAngleDegrees is better off as part of the Power sensor excerpt, instead of a separate property? That would move the definition into Sensor as part of a "Power" ReadingType, and would be reported alongside PowerFactor, as in: "PowerWatts": {
"DataSourceUri": "/redfish/v1/PowerEquipment/RackPDUs/1/Sensors/PowerA1",
"Reading": 197.4,
"ApparentVA": 182.4,
"ReactiveVAR": 4.8,
"PowerFactor": 0.93,
"PhaseAngleDegrees": -7.3
},That would allow it to show up wherever the Power Sensor excerpt is used (Outlet, Circuit) in context with PowerFactor.
Or we can leave it as a standalone property in Outlet (would it not apply to any output/branch circuit as well?)... Jeff |
|
|
|
Post by jautor on Oct 26, 2021 13:55:23 GMT
One refinement... I realized the "unbalanced" properties need to have "Percent" in the name, as that is the units for both properties.
- UnbalancedVoltagePercent
- UnbalancedCurrentPercent
|
|
|
|
Post by altitech on Oct 26, 2021 17:20:22 GMT
Hi Jeff,
Yes, adding this to the "Power" reading type looks much more concise and really augments power factor (which effectively drops the sign after taking cos() of the phase angle... another way to calculate PF). Very clean. PhaseAngleDegrees is effectively a power "quality" measurement.
This could apply to all power sections. Mains circuit or branches would simply indicate the total phase angle shift in the inlet or branch (single or 3-phase) and show whether the the total loads are generally capacitive, inductive or resistive. This could be useful for PDU's that only support inlet metering. Your call of course.
Thanks for the Unbalanced naming updates.
Best Regards,
Bill
|
|
|
|
Post by altitech on Oct 27, 2021 16:36:35 GMT
Jeff, Just talked to one of our experts in the Legrand Raritan division. He wanted to point out that reactive power, though as unintuitive as it may seem, is officially defined as "var" not "VAR". Not sure if you can or want to adjust the name. en.wikipedia.org/wiki/AC_power#Active,_reactive,_and_apparent_power It was also pointed out that we currently support vibration sensors. This is another sensor that would be immediately useful to us. Best Regards, Bill |
|
|
|
Post by jautor on Oct 27, 2021 23:59:05 GMT
Jeff, Just talked to one of our experts in the Legrand Raritan division. He wanted to point out that reactive power, though as unintuitive as it may seem, is officially defined as "var" not "VAR". Not sure if you can or want to adjust the name. en.wikipedia.org/wiki/AC_power#Active,_reactive,_and_apparent_power It was also pointed out that we currently support vibration sensors. This is another sensor that would be immediately useful to us. Best Regards, Bill Ick... Yeah, I found that I had capitalized a lot of the SI units in the descriptions - I actually have a change pending to try to get everything accurate.
For (var) I can't fix the existing property name for "ReactiveVAR" (I clearly just followed "ApparentVA" and assumed it was following along like a good set of units!), but I will fix the description for that and the new reactive energy property.
But looking at the name of that property, following our design pattern, it would become "Reactivekvarh" which reads like the name of an industrial punk band! So I'm going to suggest that, while not 100% technically accurate, it is much more readable, and consistent with our other (incorrectly capitalized) ReactiveVAR to leave that as "ReactivekVARh" - but have it correctly shown in the text descriptions as "(kvarh)" or kilovolt-ampere-hour-reactive...
On the vibration sensor, I want to open a new thread for the ones you suggested and some I came up with as well looking at the IoT sensor products... You listed vibration above - with G units? Some of these may be easy to define and get agreement on.
Jeff
|
|
|
|
Post by altitech on Oct 28, 2021 17:40:46 GMT
LOL... I'm fairly certain we can survive with the existing name ;-D. Its certainly more readable.
Thrust vibration sensors (accelerometers) are typically measured in g. "g-force" may be better as to not conflict with the SI unit for mass. You can also verify this online with other vibration sensor manufacturers. I found this blog if it helps: We also have a downloadable power catalog that includes brief specifications for each sensor we make: www.raritan.com/ap/products/power/accessories/environmental-sensorsHope this helps Bill |
|
|
|
Post by jautor on Oct 29, 2021 17:07:28 GMT
|
|
