Redfish
Reference for the Redfish driver: HTTPS connection to a BMC, resource-path plus JSON-pointer addressing, reads, PATCH writes and types.
The Redfish driver reads and writes DMTF Redfish management services: the REST API exposed by server BMCs (baseboard management controllers), chassis and other datacenter hardware for out-of-band management. This is an ordinary client-mode driver — Ganter Lab connects to the equipment — and the transport is always HTTPS: hardened BMCs expose nothing else, and the driver never downgrades to plain HTTP on its own.
Typical points read this way: power state, secure-boot state, chassis and manager health, firmware version, temperatures and fan readings from the thermal resources.
Connection fields
| Field | What it is | Format | Default |
|---|---|---|---|
| Host | The Redfish service's host name or IP address. | Host name or IP | empty |
| Port | The port the service answers on. Management controllers commonly answer on 443, and a service published elsewhere says so here. | 1 to 65535 | 443 |
| Username | The BMC account used for HTTP Basic authentication. Empty leaves the requests anonymous, which a protected service will answer with an authorization error. | Free text | empty |
| Password | The password paired with the username. Protected at rest per Windows user, so the configuration database never holds the clear value; a password entered under another Windows account shows as unreadable and must be re-entered. | Free text | empty |
On connect the driver verifies the service by reading the service root
(/redfish/v1/). The BMC's TLS certificate must pass normal Windows certificate
validation — a self-signed BMC certificate has to be trusted by this machine before
the device will connect. A connection that fails says why on the Events page and in
the day's log file, with the underlying error behind it, so a refused password and
an untrusted certificate are told apart.
The poll interval is configurable: the device default (1000 ms) applies to every tag that does not state its own.
Tag addressing
A Redfish tag is addressed by a resource path plus an optional JSON pointer into the document that resource returns:
| Field | What it does | Values | Default |
|---|---|---|---|
| Resource path | The service-root-relative path of the Redfish resource to GET, e.g. redfish/v1/Chassis/1/Thermal. |
Free text (required) | empty |
| JSON pointer (blank = whole document) | An RFC 6901 pointer selecting one field of the returned JSON, e.g. /Temperatures/0/ReadingCelsius. Array elements are addressed by index; ~1 escapes a / inside a field name and ~0 a ~. A missing leading / is added for you. Blank returns the whole document as text. |
JSON pointer or blank | blank |
Examples of the assembled address (shown read-only as the wire source preview):
redfish/v1/Systems/1#/PowerState— the system's power state as a string.redfish/v1/Chassis/1/Thermal#/Temperatures/0/ReadingCelsius— the first thermal sensor, as a number.redfish/v1/Systems/1/SecureBoot#/SecureBootEnable— secure boot, as a boolean.
On a read the driver GETs the resource, parses the JSON, follows the pointer and
converts the result to the tag's declared data type. A pointer that names nothing
in the document, and a field the document carries as JSON null, both read as no
value: the tag goes to bad quality and its read-failure policy decides what is
presented, rather than the word null arriving as a good reading. A response that
is not JSON is parsed directly as the declared type.
Writes
Tags with a writable access mode PATCH the addressed field: the driver builds the
smallest JSON document covering only the pointer's path (for
/Parent/Child, the body {"Parent":{"Child":<value>}}) and sends it to the
resource. Two constraints follow from that:
- A write requires a JSON pointer. A whole-document tag (blank pointer) cannot be written: the tag panel refuses the combination while you are editing, saying the field is missing, and an attempt that reaches the service anyway fails with the reason in the journal.
- The BMC decides what is writable; a PATCH the service rejects reads as a failed write.
As everywhere else, the value you type in the tag's write box is the engineering value, and the tag's conversion stages are reversed before the raw value goes on the wire, as described on the Connector page.
Supported data types
Boolean, Int32, Int64, Float, Double and String. Pick the type matching the JSON
field: booleans for flags such as SecureBootEnable, numbers for readings, strings
for states such as PowerState or Health.
Commands
A Redfish service publishes an action per thing it can be asked to do, each at its own
path under the resource it acts on. The station does not guess those, because only the
hardware's own documentation says which exist: you declare them on the device, in the
Commands card of its page. Each command carries a name, the action path
(redfish/v1/Systems/1/Actions/ComputerSystem.Reset), and optionally the name of the one
value it takes (ResetType); the row's Run verb sends it, and what the service answered
is reported back. A command also becomes a method on the device in this station's own OPC
UA address space, so anything that can call a method can issue it.
The value travels as the request body. A value that is already JSON is sent as written;
anything else is sent as {"<the name you declared>": "<the value>"}, which is the shape
Redfish's own reset action expects.
Discovery
The Discover button reads one service: put its address in the driver page's Scan scope
card (https://bmc-host, or the address the vendor documents) and the scan walks that
service's first system, manager and chassis, offering the device with those points ready to
add. The scan reads the service over HTTPS and without credentials, because it runs before
the device that would hold them exists, so a service that authenticates every request
answers nothing and is added by hand instead. Redfish's own SSDP discovery needs UDP
multicast, which the in-process driver does not do, so nothing is found by broadcasting: the
scan reads the address you give it.