Add sensor component container #1369

mrevang · 2025-09-17T02:43:44Z

Change Scope

This change adds a generic sensor container to /components/component[name=]/state. This container defines an instantaneous value along with operating thresholds.

It's worth highlighting, the units of the sensor's instantaneous value are defined by a parallel leaf, allowing this generic sensor component to represent multiple sensor types (current, voltage, ect).

module: openconfig-platform
  +--rw components
     +--rw component* [name]
        +--ro state
        +--rw oc-sensor:sensor <<<<<<<<<<<<<<<<<
           +--ro oc-sensor:state
              +--ro oc-sensor:instant-precision2?   decimal64
              +--ro oc-sensor:units?                identityref
              +--ro oc-sensor:thresholds
                 +--ro oc-sensor:threshold* [severity]
                    +--ro oc-sensor:severity    -> ../state/severity
                    +--ro oc-sensor:state
                       +--ro oc-sensor:severity?   identityref
                       +--ro oc-sensor:upper?      decimal64
                       +--ro oc-sensor:lower?      decimal64

This change is backwards compatible.

Platform Implementations

Openconfig already defines specific sensor types among other component types. This change provides a more generic way to model a sensor that doesn't align with the fixed sensors already available.
Sonic temp voltage
We are working offline with a couple of vendors on implementing this model.

dplore · 2025-09-17T17:13:06Z

/gcbrun

OpenConfigBot · 2025-09-17T17:15:07Z

No major YANG version changes in commit ec04f7f

earies · 2025-09-17T22:58:54Z

As more and more structures are proposed under the /components subtree, it has been observed that we are in a state where there are N# of potential ways to represent like data all without true modeling restrictions. Can you elaborate when this structure should be represented under components of which type? Is this meant to be for type=SENSOR components only? If so, subtrees should ideally carry when restrictions indicating such to firm up consistent behavior.

There are also vendor anchor points and other thresholding that could also be leveraged for such uses so I think some guidance is necessary for implementors otherwise it is likely to see divergence across implementations.

release/models/platform/openconfig-platform-sensor.yang

earies · 2025-09-17T23:03:18Z

release/models/platform/openconfig-platform-sensor.yang

+        }
+
+        container state {
+          config false;


config false is inherited from parents. Is there ever intention for configurable thresholds (there are other variants of this in OC modeling as well in platform/system)

I can imagine a scenario where one might want to configure these thresholds. Consider if the management system wanted to tune when an alarm might fire due to the sensor being out of range. I don't have this usage in mind. The use case I'm modeling for is to have these thresholds be vendor supplied, so config false seems appropriate. Thoughts?

the state container should be config false always. But don't label the parent container config false. Allow for a config container to be added later which would allow user configurable thresholds.

Today all the operational use cases I am aware of do not require a user override of factory defined thresholds for hardware components.

Removing this

list threshold { key "severity"; config false; <<<<<<<<

... requires adding the key into a config container, just FYI, thanks.

Ignore that comment... transceiver provides an example where this isn't true.. sorting out this error:

The list's keys must have the same config value as the list itself.(invalid-config)

Maybe I'm not understanding the comment. The thresholds container in the transceiver container also has config false:

public/release/models/platform/openconfig-platform-transceiver.yang

Line 581 in e1a6ae0

config false;

The latest change applies a when on sensor/state at L177.

earies · 2025-09-17T23:03:40Z

release/models/platform/openconfig-platform-sensor.yang

+  augment "/oc-platform:components/oc-platform:component/" +
+    "oc-platform:sensor" {
+    description
+      "Adding fan data to component model";


Miscopy from another model?

I can swear I addressed this at some point... losing my mind. Good catch, thanks!

earies · 2025-09-17T23:04:01Z

release/models/platform/openconfig-platform-sensor.yang

+  augment "/oc-platform:components/oc-platform:component/" +
+    "oc-platform:sensor/oc-platform:state" {
+    description
+      "Adding fan state data to component model";


Good catch, thanks.

release/models/platform/openconfig-platform-sensor.yang

mrevang · 2025-09-17T23:09:25Z

As more and more structures are proposed under the /components subtree, it has been observed that we are in a state where there are N# of potential ways to represent like data all without true modeling restrictions. Can you elaborate when this structure should be represented under components of which type? Is this meant to be for type=SENSOR components only? If so, subtrees should ideally carry when restrictions indicating such to firm up consistent behavior.

There are also vendor anchor points and other thresholding that could also be leveraged for such uses so I think some guidance is necessary for implementors otherwise it is likely to see divergence across implementations.

Great comment. The intention is for this container to only be used when type=SENSOR. From a quick search, looks like this can be accomplished with a must , let me add this. Thanks for the suggestion!

earies · 2025-09-17T23:22:23Z

As more and more structures are proposed under the /components subtree, it has been observed that we are in a state where there are N# of potential ways to represent like data all without true modeling restrictions. Can you elaborate when this structure should be represented under components of which type? Is this meant to be for type=SENSOR components only? If so, subtrees should ideally carry when restrictions indicating such to firm up consistent behavior.
There are also vendor anchor points and other thresholding that could also be leveraged for such uses so I think some guidance is necessary for implementors otherwise it is likely to see divergence across implementations.

Great comment. The intention is for this container to only be used when type=SENSOR. From a quick search, looks like this can be accomplished with a must , let me add this. Thanks for the suggestion!

Similar example here: https://github.com/openconfig/public/blob/master/release/models/platform/openconfig-platform.yang#L1350-L1355

dplore · 2025-09-18T01:14:50Z

/gcbrun

mrevang · 2025-09-18T01:35:59Z

As more and more structures are proposed under the /components subtree, it has been observed that we are in a state where there are N# of potential ways to represent like data all without true modeling restrictions. Can you elaborate when this structure should be represented under components of which type? Is this meant to be for type=SENSOR components only? If so, subtrees should ideally carry when restrictions indicating such to firm up consistent behavior.
There are also vendor anchor points and other thresholding that could also be leveraged for such uses so I think some guidance is necessary for implementors otherwise it is likely to see divergence across implementations.

Great comment. The intention is for this container to only be used when type=SENSOR. From a quick search, looks like this can be accomplished with a must , let me add this. Thanks for the suggestion!

Similar example here: https://github.com/openconfig/public/blob/master/release/models/platform/openconfig-platform.yang#L1350-L1355

In order to access /components/component/state/type for use by when, it looks like the sensor will need to be relocated:

/components/component/sensor -> /components/component/state/sensor

The following snippet...

container sensor {
      when "../state/type = 'oc-platform-types:SENSOR'";

... resulted in this warning:

warning: node "openconfig-platform::state" is config false and is not part of the accessible tree

The relocation worked... so I'm going with it. Updating the description to capture this change.

earies · 2025-09-18T16:58:36Z

As more and more structures are proposed under the /components subtree, it has been observed that we are in a state where there are N# of potential ways to represent like data all without true modeling restrictions. Can you elaborate when this structure should be represented under components of which type? Is this meant to be for type=SENSOR components only? If so, subtrees should ideally carry when restrictions indicating such to firm up consistent behavior.
There are also vendor anchor points and other thresholding that could also be leveraged for such uses so I think some guidance is necessary for implementors otherwise it is likely to see divergence across implementations.

Great comment. The intention is for this container to only be used when type=SENSOR. From a quick search, looks like this can be accomplished with a must , let me add this. Thanks for the suggestion!

Similar example here: https://github.com/openconfig/public/blob/master/release/models/platform/openconfig-platform.yang#L1350-L1355

In order to access /components/component/state/type for use by when, it looks like the sensor will need to be relocated:
* /components/component/sensor -> /components/component/state/sensor
The following snippet...
container sensor {
      when "../state/type = 'oc-platform-types:SENSOR'";
... resulted in this warning:
warning: node "openconfig-platform::state" is config false and is not part of the accessible tree
The relocation worked... so I'm going with it. Updating the description to capture this change.

I think your prior anchor point was the more correct location as this follows the same pattern for other "type" hierarchies... just that many of these containers today have no schema rules of when they should or should not exist (left up to interpretation)

Your compiler issue stems from interleaving a config=true container to attempt to depend on config=false. One option is leave as-is w/o when restrictions (which I think is a topic of discussion that should be had as I'm finding we are revisiting this subject over and over) or align the when stmt to a config=false hierarchy. Some are pure state but if there is ever any chance of configuration in the future, we cannot be that strict.

Update release/models/platform/openconfig-platform-sensor.yang Co-authored-by: Ebben Aries <[email protected]> Update release/models/platform/openconfig-platform-sensor.yang Co-authored-by: Ebben Aries <[email protected]> Add when predicate to sensor, address comments remove whitespace

mrevang · 2025-09-19T17:54:03Z

As more and more structures are proposed under the /components subtree, it has been observed that we are in a state where there are N# of potential ways to represent like data all without true modeling restrictions. Can you elaborate when this structure should be represented under components of which type? Is this meant to be for type=SENSOR components only? If so, subtrees should ideally carry when restrictions indicating such to firm up consistent behavior.
There are also vendor anchor points and other thresholding that could also be leveraged for such uses so I think some guidance is necessary for implementors otherwise it is likely to see divergence across implementations.

Great comment. The intention is for this container to only be used when type=SENSOR. From a quick search, looks like this can be accomplished with a must , let me add this. Thanks for the suggestion!

Similar example here: https://github.com/openconfig/public/blob/master/release/models/platform/openconfig-platform.yang#L1350-L1355

In order to access /components/component/state/type for use by when, it looks like the sensor will need to be relocated:
* /components/component/sensor -> /components/component/state/sensor
The following snippet...
container sensor {
      when "../state/type = 'oc-platform-types:SENSOR'";
... resulted in this warning:
warning: node "openconfig-platform::state" is config false and is not part of the accessible tree
The relocation worked... so I'm going with it. Updating the description to capture this change.
As more and more structures are proposed under the /components subtree, it has been observed that we are in a state where there are N# of potential ways to represent like data all without true modeling restrictions. Can you elaborate when this structure should be represented under components of which type? Is this meant to be for type=SENSOR components only? If so, subtrees should ideally carry when restrictions indicating such to firm up consistent behavior.
There are also vendor anchor points and other thresholding that could also be leveraged for such uses so I think some guidance is necessary for implementors otherwise it is likely to see divergence across implementations.

Great comment. The intention is for this container to only be used when type=SENSOR. From a quick search, looks like this can be accomplished with a must , let me add this. Thanks for the suggestion!

Similar example here: https://github.com/openconfig/public/blob/master/release/models/platform/openconfig-platform.yang#L1350-L1355

In order to access /components/component/state/type for use by when, it looks like the sensor will need to be relocated:
* /components/component/sensor -> /components/component/state/sensor
The following snippet...
container sensor {
      when "../state/type = 'oc-platform-types:SENSOR'";
... resulted in this warning:
warning: node "openconfig-platform::state" is config false and is not part of the accessible tree
The relocation worked... so I'm going with it. Updating the description to capture this change.
I think your prior anchor point was the more correct location as this follows the same pattern for other "type" hierarchies... just that many of these containers today have no schema rules of when they should or should not exist (left up to interpretation)

Your compiler issue stems from interleaving a config=true container to attempt to depend on config=false. One option is leave as-is w/o when restrictions (which I think is a topic of discussion that should be had as I'm finding we are revisiting this subject over and over) or align the when stmt to a config=false hierarchy. Some are pure state but if there is ever any chance of configuration in the future, we cannot be that strict.

I've reverted to the original anchor point (component/sensor), and moved the when to sensor/state.

nkitchen-arista · 2025-09-29T22:24:51Z

This model could be very useful for power supplies that have multiple inputs and/or multiple outputs -- we could represent the separate readings as distinct sensor subcomponents instead of complicating the power-supply model.

In that kind of scenario, it would be helpful to represent the property of the sensor's "directionality". What do you think about adding a path that captures that -- for example, allowing us to distinguish between input current and output current?

nkitchen-arista · 2025-09-29T22:28:24Z

release/models/platform/openconfig-platform-sensor.yang

+    description
+      "Operational state data for sensor components";
+
+    leaf instant-precision2 {


What's the rationale for including the precision in the name of the leaf? Is the idea that a different name would be used if a different precision were needed? If so, wouldn't that be contrary to the aim of a generic sensor model?

Exactly. I wanted to accommodate different precision requirements should they arise in the future. From a survey of existing sensor values, "2 decimal places" covers the current use cases. Should another use case come by requiring another level of precision, I wanted to avoid the scenario where "instant" carried some implicit precision and exists among "instant-precisionX".

If other precisions are required, the expectation should be that only a single "instant" should be populated.

dplore · 2025-10-21T16:23:05Z

/gcbrun

jsterne · 2025-10-21T16:54:41Z

The component type SENSOR already exists. So prior to this PR, implementations would have been expected to report, for example, temperature in the path /components/component/state/temperature/instant if they were reporting it against a SENSOR component. Is it being proposed to report something like temperature inside the /components/component/sensor container now?

Add sensor component container

8a28557

mrevang requested a review from a team as a code owner September 17, 2025 02:43

github-project-automation bot added this to OC Operator Review Sep 17, 2025

fix whitespace

2ab7b87

OpenConfigBot added the non-breaking label Sep 17, 2025

earies reviewed Sep 17, 2025

View reviewed changes

mrevang closed this Sep 18, 2025

mrevang reopened this Sep 18, 2025

mrevang added 2 commits September 19, 2025 17:48

Apply _when_ to sensor state, remove sensor from top level model

ec04f7f

mrevang force-pushed the sensor branch from a43c4a2 to ec04f7f Compare September 19, 2025 17:49

dplore moved this to Ready to discuss in OC Operator Review Sep 26, 2025

nkitchen-arista reviewed Sep 29, 2025

View reviewed changes

Add sensor component container #1369

Are you sure you want to change the base?

Add sensor component container #1369

Uh oh!

Conversation

mrevang commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change Scope

Platform Implementations

Uh oh!

dplore commented Sep 17, 2025

Uh oh!

OpenConfigBot commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

earies commented Sep 17, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mrevang commented Sep 17, 2025

Uh oh!

earies commented Sep 17, 2025

Uh oh!

dplore commented Sep 18, 2025

Uh oh!

mrevang commented Sep 18, 2025

Uh oh!

earies commented Sep 18, 2025

Uh oh!

mrevang commented Sep 19, 2025

Uh oh!

nkitchen-arista commented Sep 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dplore commented Oct 21, 2025

Uh oh!

jsterne commented Oct 21, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

mrevang commented Sep 17, 2025 •

edited

Loading

OpenConfigBot commented Sep 17, 2025 •

edited

Loading