Generated from the committed OpenAPI document, bmcd 2.36.3. Do not edit this file: just refresh-api rewrites it.
Cooling devices with their setpoints
Legacy form: GET /api/bmc?opt=get&type=cooling with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.
| response |
body |
meaning |
200 |
application/json — array of CoolingDevice |
The result. |
204 |
empty |
Done, with nothing to report. |
default |
application/problem+json — Problem |
A refusal, RFC 9457. |
`200` body (`application/json`) (each element): `CoolingDevice`
| field |
type |
required |
description |
device |
string |
yes |
|
max_speed |
integer (uint64) |
yes |
|
overridden |
boolean |
yes |
Whether that zone's governor is paused, which is the only condition under which a step written here is a step that holds. With the governor running, step_wise returns the fan to the trip the board is above within a poll, so a written step is a request the kernel is about to overrule. Reported so a client can say which of those two things is happening, rather than leaving a person to watch a slider spring back and draw their own conclusion. |
speed |
integer (uint64) |
yes |
|
zone |
string or null |
no |
The thermal zone whose governor drives this device, when one binds it. A zone binds a cooling device once per trip it should react to, so this board's single fan is cdev0 through cdev3 of the one zone. Every one of those links is the same answer. |
`default` body (`application/problem+json`): `Problem`
| field |
type |
required |
description |
detail |
string |
no |
|
status |
integer |
yes |
|
title |
string |
yes |
|
type |
string |
no |
|
Set a cooling device's step
Legacy form: GET /api/bmc?opt=set&type=cooling with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.
Request body (`application/json`)
| field |
type |
required |
description |
device |
string |
no |
as reported by GET /cooling |
speed |
string |
no |
a step, 0 to max_speed |
Request body (`application/x-www-form-urlencoded`)
| field |
type |
required |
description |
device |
string |
no |
as reported by GET /cooling |
speed |
string |
no |
a step, 0 to max_speed |
| response |
body |
meaning |
200 |
application/json — — |
The result. Its shape is not described in this document. |
204 |
empty |
Done, with nothing to report. |
default |
application/problem+json — Problem |
A refusal, RFC 9457. |
`default` body (`application/problem+json`): `Problem`
| field |
type |
required |
description |
detail |
string |
no |
|
status |
integer |
yes |
|
title |
string |
yes |
|
type |
string |
no |
|
Temperature sensors with their trip points, and the fan's step
Legacy form: GET /api/bmc?opt=get&type=thermal with the same parameters in the query string. That form answers {"response":[{"result":…}]} and puts a refusal's message in result; this path answers the bare result and a refusal as application/problem+json.
| response |
body |
meaning |
200 |
application/json — Thermal |
The result. |
204 |
empty |
Done, with nothing to report. |
default |
application/problem+json — Problem |
A refusal, RFC 9457. |
`200` body (`application/json`): `Thermal`
| field |
type |
required |
description |
cooling |
array of Cooler |
yes |
|
sensors |
array of ThermalSensor |
yes |
|
`default` body (`application/problem+json`): `Problem`
| field |
type |
required |
description |
detail |
string |
no |
|
status |
integer |
yes |
|
title |
string |
yes |
|
type |
string |
no |
|