|
|
Post by lucashorigan on Apr 5, 2024 17:46:01 GMT
Referencing the Redfish Data Model Specification version 2023.3 here
Looking at the section 4.3 Condition.I am asking for a read-write property to be added to Conditions to a similar name of "State". There is often times a need to have the ability to turn alarms on or off for the end user. Giving a read-write point in the Conditions array as below would solve this: Would such an addition be possible? |
|
|
|
Post by mraineri on Apr 5, 2024 19:17:30 GMT
What's the usage for this from the user's perspective? Today, we use "Conditions" to show everything that is affecting the health of the resource, and so the condition is still true until the underlying fault has been addressed.
|
|
|
|
Post by lucashorigan on Apr 8, 2024 12:25:46 GMT
What's the usage for this from the user's perspective? Today, we use "Conditions" to show everything that is affecting the health of the resource, and so the condition is still true until the underlying fault has been addressed. In practice end-users do not want every single alarm offered to always be turned on. There are a large number of alarms on a CDU and something such as the room temperature being too high may not be of interest to a specific end-user. They would be able to go to where the specific alarm is and turn it off by writing to a "State" within the condition array to turn it off on the controller. This is something customers regularly use today. This should be a Nullable property. There are some critical alarms that should never be turned off and this will not included for those alarms. |
|
|
|
Post by jautor on Apr 15, 2024 23:34:24 GMT
In practice end-users do not want every single alarm offered to always be turned on. There are a large number of alarms on a CDU and something such as the room temperature being too high may not be of interest to a specific end-user. They would be able to go to where the specific alarm is and turn it off by writing to a "State" within the condition array to turn it off on the controller. This is something customers regularly use today. We have discussed the addition of "formal alarm handling" (and this topic was raised in one or more Work-in-Progress presentations for Power Distribution Units), but have yet to have enough expert opinions to weigh in on the topic for standardization. If there is more interest in this area, we'd welcome proposals or feedback on the previously release WIP concepts. Part of that support would certainly allow the enable/disable of individual alarms (alarm suppression being a concept in the formal handling) - but that would not be handled in the Conditions array, as the intent there is to show active conditions that require attention. Note also that individual users (clients) for a particular device can use the EventDestination subscription options to filter out particular event messages if the service provides that flexibility. I don't think that is what you were looking for, but that is something available in the standard today. Jeff |
|
|
|
Post by lucashorigan on Apr 26, 2024 15:11:42 GMT
We have discussed the addition of "formal alarm handling" (and this topic was raised in one or more Work-in-Progress presentations for Power Distribution Units), but have yet to have enough expert opinions to weigh in on the topic for standardization. If there is more interest in this area, we'd welcome proposals or feedback on the previously release WIP concepts. Part of that support would certainly allow the enable/disable of individual alarms (alarm suppression being a concept in the formal handling) - but that would not be handled in the Conditions array, as the intent there is to show active conditions that require attention. Note also that individual users (clients) for a particular device can use the EventDestination subscription options to filter out particular event messages if the service provides that flexibility. I don't think that is what you were looking for, but that is something available in the standard today. Jeff Alright, understood on the Conditions array being setup for only attention needing components. Also thank you for the information on subscriptions. The feature I am looking to be implemented is the ability for an end-user to be given a read-write point that enables/disables the actual alarm on an application level. As specific alarms if enabled can shut down the unit, when an end user will not ant that to occur. Referencing the following WIP for the CDU here: redfish.dmtf.org/redfish/mockups/wipcdu/1291An additional property such as, "Publishes" that allows for all Members for turning off alarms would be the easiest fit I see for the current framework. The expectation would be a menu of all conditions that can be optionally turned on and off on a unit, that will most likely be referenced back on a Chassis/Controls URI for that read-write point. The idea would be the end-user can have a quick reference of where to go to turn off which specific Condition at an application level on the CDU's controller. For example:
At EventService: Inserting: "Publishes": { "@odata.id": "redfish/v1/EventService/Publishes" },
"@odata.type": "#EventService.v1_7_1.EventService",
"Id": "EventService",
"Name": "Event Service",
"Status": {
"State": "Enabled",
"Health": "OK"
},
"ServiceEnabled": true,
"DeliveryRetryAttempts": 3,
"DeliveryRetryIntervalSeconds": 60,
"EventTypesForSubscription": [
"StatusChange",
"ResourceUpdated",
"ResourceAdded",
"ResourceRemoved",
"Alert"
],
"Subscriptions": {
"@odata.id": "/redfish/v1/EventService/Subscriptions"
},
"Publishes": {
"@odata.id": "redfish/v1/EventService/Publishes"
},
"Actions": {
"#EventService.SubmitTestEvent": {
"target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent",
"EventType@Redfish.AllowableValues": [
"StatusChange",
"ResourceUpdated"
"ResourceAdded",
"ResourceRemoved",
"Alert"
]
}
},
"Oem": {},
"@odata.id": "/redfish/v1/EventService"Going into "redfish/v1/EventService/Publishes" you are given a "Members" array of different Publishes for turning Conditions on and off. These can be broken into their own custom categories, such as "Heat Conditions", "Primary Conditions", etc. Clicking into Publishes/1 then: {
"@odata.type": "#EventDestination.v1_10_0.EventDestination",
"Id": "1",
"Name": "EventPublish Heat Alarms",
"ConditionControlLocations": {
"Chassis/MySerialNumber/Controls/HeatExchangeAlarm",
"Chassis/MySerialNumber/Controls/PrimaryHighAlarm"
"Chassis/MySerialNumber/Controls/DeltaSecondaryLowAlarm"
}
"Context": "WebUser3",
"Protocol": "Redfish",
"@odata.id": "/redfish/v1/EventService/Subscriptions/1"
}
Ideally the user can just enter in PATCH Chassis/MySerialNumber/Controls/AlarmYouDontWantEnabled
Body:
{
ControlMode: "Disabled"
}Or some solution like above that gives the end-user the ability to quickly walk in turn off an alarm/condition they're not interested that fits into the EventDestination section. |
|
