# 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 {#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 {#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 {#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":}}`) 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](connector) page. ## Supported data types {#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 {#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 `{"": ""}`, which is the shape Redfish's own reset action expects. ## Discovery {#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.