[Feature Request] Support for Discrete Sensors Monitoring with IPMI and Redfish Integration

[jack206]

Is your feature request related to a problem? Please describe.
In current releases, monitoring and alerting for discrete (binary) sensors is limited. For example, sensors like PSU fail, intrusion switches (door open/close), fan status etc. are not well supported, especially in scenarios requiring both IPMI and Redfish protocol integration.

Describe the solution you'd like

• Support for discrete sensor monitoring and alerting.
• Unified sensor state across both IPMI and Redfish (data format mapping).
• Ability to trigger custom actions/events upon state change.
• Successful visualization and API access for discrete sensor data.

Describe alternatives you've considered

• Manual polling via IPMItool/Redfish API
• Separate exporter development

Additional context
Discrete sensor health monitoring is essential for automated alerts and system maintenance.
References: IPMI Sensors, Redfish Specification

[tausiffmujawar]

Hi @jack206,

I’d like to take this on. I’m a firmware engineer with a C++/Linux background and experience with IPMI and Redfish.OpenBMC itself is newer to me, but I’ve been getting familiar with the D-Bus-centric architecture.
Before diving in, I wanted to clarify a few points and align on approach:
D-Bus interfaces for discrete sensors:
From what I can tell, there isn’t a single generic “discrete sensor” interface in phosphor-dbus-interfaces. Existing implementations seem to rely either on xyz.openbmc_project.Sensor.Value with discrete semantics or on domain-specific interfaces (for example, chassis intrusion). Is the expectation to continue using existing interfaces where semantics already exist, rather than introducing a new generic one?
Scope:
Would you prefer starting with a small, representative set (such as chassis intrusion, PSU presence/fail) to establish a clear pattern and then expanding, or should broader coverage be targeted from the outset? My inclination is to start small and iterate based on feedback.
Implementation approach:
For event-driven discrete signals (e.g. GPIO-backed), existing solutions like phosphor-intrusion-monitor suggest using a small, purpose-built daemon rather than extending dbus-sensors, which is more polling-oriented. Does that align with how you’d like this to be approached?
Configuration:
Is there a preference between daemon-local JSON configuration (as used by intrusion) versus Entity Manager–driven configuration for discrete sensors?
Ongoing work:
Is there anything already in progress in this area that I should be aware of?
My initial plan is to study existing discrete sensor implementations, settle on the appropriate D-Bus contract, implement a minimal end-to-end path, and ensure the state is consumed consistently by both IPMI and Redfish via D-Bus. I’m thinking of starting with chassis intrusion as a proof of concept and expanding from there once the pattern is validated.
Please let me know if this direction makes sense or if you’d prefer a different approach. Happy to adjust based on maintainer guidance.
Thanks.

[mdmillerii]

#37 (comment) looks like a design proposal that should be discussed via a design document in Gerrit. Placing a reference here will alert interested parties.

https://github.com/openbmc/docs/blob/master/designs/design-template.md

I understand soliciting requirements feedback when developing for unrelated parties.

[edtanous]

Support for discrete sensor monitoring and alerting.

Please take a look at the PSUEvent class, as well as the intrusion sensor application. Some amount of these things are already supported by dbus sensors. Keep in mind that neither Redfish nor DBus support the concept of a "discrete" sensor. They model more specific actions, that if you choose, IPMI can convert into a discrete sensor SDR with your proposed change.

Is the expectation to continue using existing interfaces where semantics already exist, rather than introducing a new generic one?

Correct. Newer protocols very intentionally do not support the kind of generics that ipmi did, due to them being a difficult API to maintain and reuse between systems. Adding a generic "discrete" type has been requested and rejected many times over the years and explicitly rejected for this reason.

If you're interested in creating a design doc, you certainly can, but I would start by discussing the specifics of what you're trying to solve in terms of the existing functionality and typed interfaces. Assuming it is simply supporting new hardware, I very much suspect we can reach consensus on your new functionality without a design doc.

[tausiffmujawar]

Hello @edtanous

Thanks for the clarification, that’s very helpful.
Understood that “discrete” is an IPMI concern and that D-Bus/Redfish should continue to model typed state and actions, with IPMI deriving discrete SDRs as needed. I’ll focus on existing functionality and interfaces (e.g. "PSUEvent", the intrusion sensor application, and relevant parts of "dbus-sensors") rather than introducing any new generic abstractions.

I’ll take a concrete case, work through what is already supported today, identify the specific gaps for the hardware I’m targeting, and propose incremental changes that fit the current model. I’ll circle back with that approach so we can review the specifics and reach consensus.

Thanks.

[tausiffmujawar]

Hello @edtanous

I’ve reviewed the existing paths ('PSUEvent', 'PSUSensor', threshold handling, and how 'OperationalStatus::Functional' is consumed). The concrete gap I see today is that PSU temperature CRITICAL thresholds are evaluated but remain sensor-local and do not promote the PSU to non-functional. As a result, 'Functional' can remain 'true' even under a CRITICAL over-temperature condition.

My plan is to keep the existing threshold and power-delay behavior unchanged, reuse the existing 'PSUEvent' "Failure" path, and add a minimal bridge so an immediate CRITICAL PSU temperature assertion marks the PSU non-functional and clears it on recovery. No new generic interfaces or event types. Let me know if we can reach consensus on this proposed change.

I’ll proceed with this approach based on your alignment and preference.

[tausiffmujawar]

I’ve pushed a change that promotes PSU temperature 'CRITICAL' thresholds to existing functional-state semantics, so PSU health is reflected consistently via "OperationalStatus.Functional".
The change reuses existing Sensor/threshold infrastructure and avoids introducing new interfaces or generic discrete types.

Gerrit: https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/86940

Happy to adjust based on feedback.

[tausiffmujawar]

Hello @edtanous . Can you please review and provide feedback .

[williamspatrick]

Hello @edtanous . Can you please review and provide feedback .

Generally people are not reviewing code that isn't in a state to be reviewed.

https://openbmc.stwcx.xyz/bot/review-status/86940

Your commit doesn't have CI test results. That is because you're not covered by a CLA (contributor license agreement). Since it seems like you work for a company that does OpenBMC development, please check with your CLA manager to get yourself added to the CLA document (and then to Gerrit).

Contributors especially don't want to look at code that isn't licensed for use by the OpenBMC project (ie. written by someone covered with a CLA) because of potential software license contamination.

[tausiffmujawar]

Thank you @williamspatrick for pointing out. I wasnt aware. I will follow the advice regarding CLA manager. I had contributed here as an individual with general interest in linux programming.

[tausiffmujawar]

@williamspatrick I have been added to CLA document. Do i need to trigger CI or does it trigger automatically once i bypass CLA approval.

[williamspatrick]

@williamspatrick I have been added to CLA document. Do i need to trigger CI or does it trigger automatically once i bypass CLA approval.

Generally, once you are in the appropriate Gerrit group, you can retrigger your commit on Jenkins.

I sent an email to you and your CLA manager because there were some issues in this case.

[tausiffmujawar]

I have raised a patch that adds "IPMI discrete sensor" visibility for PSU OperationalStatus as a first step toward addressing this issue.The patch consumes the existing typed D-Bus interface published by 'PSUCombineEvent' and exposes it as a Type 3 SDR in 'phosphor-host-ipmid'.
Patch link: https://gerrit.openbmc.org/c/openbmc/phosphor-host-ipmid/+/88298
I plan to raise separate patches for Intrusion and other discrete sensor types. Will rework based on review comments.

Please note that i have withdrawn the previous patch https://openbmc.stwcx.xyz/bot/review-status/86940 as it did not fit the requirement