Implement list of local files and add a button to start a print.

AGENTS.md

@@ -6,7 +6,8 @@ Working agreement for AI assistants contributing to `ff-5mp-hass`.
 - **Integration:** FlashForge printers for Home Assistant (HTTP API only).
 - **Current release:** `v1.4.0` (in-flight; not yet tagged). Last published: `v1.3.3`.
 - **Supported printers:** `AD5X`, `Adventurer 5M`, `Adventurer 5M Pro`, `Creator 5`, and `Creator 5 Pro` only.
-- **Entities shipped:** 56 total (38 sensors, 5 binary sensors, 2 switches (the camera switch is not created on the Creator 5 series), 1 select, 4 buttons, 1 camera, 5 images — the g-code thumbnail plus 4 Material Station slot color swatches).
+- **Entities shipped:** 58 total (38 sensors, 5 binary sensors, 2 switches (the camera switch is not created on the Creator 5 series), 2 selects, 5 buttons, 1 camera, 5 images — the g-code thumbnail plus 4 Material Station slot color swatches).
+- **Services:** `flashforge.print_file` — starts a file already stored on the printer (entity service on the Local File Selection entity).
 - **Key dependency:** `flashforge-python-api>=1.3.4` (see sibling repo `ff-5mp-api-py`).
 - **Also shipped:** a Lovelace card (`frontend/ff-job-card.js`) for browsing the printer's files, matching materials, and starting prints, served and registered by the integration itself and backed by four websocket commands (`websocket.py`, `job.py`).
 - **Languages:** English and German, for both the integration (`translations/`) and the card (`frontend/translations/`). German contributed by @RedAces.
@@ -78,8 +79,9 @@ Working agreement for AI assistants contributing to `ff-5mp-hass`.
    - Sensors: machine status, nozzle temps/targets, bed temps/targets, progress, file, current/total layers, elapsed/remaining time, filament length/weight, print speed, z offset, move mode, nozzle size, filament type.
    - Binary sensors: printing, online, error, paused.
    - Switches: LED and camera power (may show unavailable if unsupported).
-   - Select: filtration mode (may show unavailable if unsupported).
-   - Buttons: pause, resume, cancel, clear status.
+   - Select: filtration mode (may show unavailable if unsupported); Local File Selection (lists the printer's files, selecting starts nothing).
+   - Buttons: pause, resume, cancel, clear status, print selected file.
+   - Service: `flashforge.print_file` (defaults to the selected file, accepts any file name on the printer).
    - Camera: entity exists and becomes available when the printer reports an OEM stream URL.
 4. **Controls** – Exercise switches and buttons; confirm state refreshes and coordinator remains healthy.
 5. **Resilience** – Temporarily disrupt connectivity (e.g., disable LAN mode) and confirm graceful error handling and recovery in Home Assistant logs.

CHANGELOG.md

@@ -66,6 +66,25 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - **The LED switch is no longer greyed out on every printer.** The "Always show LED switch" option was passed to the library as `led_control_override` using its unset value `False`. That parameter is tri-state — `None` means "no override", `True` forces the capability on, and `False` forces it **off** — so with the option switched off, which is the default, the integration overrode the printer's own correct capability report and pinned `client.led_control` to `False` on every model. The switch stayed unavailable, and the library additionally refused `set_led_on()` / `set_led_off()` internally, which made enabling the override look like the only way to get a working switch: `True` was the only value that got past the veto. The option now sends `None` when off and `True` only when the user asks for it, which is what it was always meant to do. Reported and diagnosed on a Creator 5 Pro, where `/product` correctly reports `lightCtrlState: 1` all along. Refs [#17](https://github.com/GhostTypes/ff-5mp-hass/issues/17).
 
+### Added
+- **Local file list and print start.** The files stored on the printer are now visible in Home Assistant and a print can be started from them:
+  - `select.<printer>_local_file_selection` ("Local File Selection") lists the printer's files (from the HTTP `/gcodeList` endpoint) and records which one to print. Whatever per-file metadata the printer reports — print time, filament weight, tool count, Material Station flag — is exposed via `extra_state_attributes["files"]` for cards and templates. Values the printer does not report are omitted rather than reported as `0`/`false`.
+  - `button.<printer>_print_selected_file` starts the selected file. Pressing it without a selection raises an error rather than starting anything; its availability follows the printer's reachability only, because a button is stateless and every write of its state is reported as a press.
+  - `flashforge.print_file` service (targets the Local File Selection entity) with optional `file_name` and `leveling_before_print` fields, so automations can start any file on the printer — including ones outside the reported list.
+  - New option **"Level the bed before starting a print"** (default off) supplies the default for the button and the service.
+  - Material Station files are started with the per-tool mappings derived from the file's own tool data plus the colors the printer reports for the loaded slots. When that data is present but incomplete the print is refused with an error telling the user to start it from the slicer instead of guessing a mapping.
+- The file list is polled by its own coordinator every 60 s (independent of the machine-state interval) and is included in diagnostics.
+
+### Fixed
+- **The LED switch is no longer permanently unavailable.** The "Always show LED switch" option was passed to the library as `led_control_override` using its unset value `False`. The library treats `False` as "force LED control off" and only `None` as "no override", so with the option switched off — the default — the integration overrode the printer's own capability report and pinned `client.led_control` to `False` on **every** model. The switch stayed greyed out, and the library additionally refused `set_led_on()` / `set_led_off()` internally, which made enabling the override look like the only way to get a working switch. The option now sends `None` when it is off and `True` only when the user asks for it. Verified on a Creator 5 Pro: `/product` correctly reports `lightCtrlState: 1`, and the lamp switches on and off — so `/product` was never the problem here.
+- **Material Station entities now appear on the Creator 5 series.** The four slot swatches (`image.<printer>_ifs_slot_1..4`) and the **Active Material Station Slot** sensor were gated on `FFMachineInfo.has_matl_station`, which is a straight copy of the raw `hasMatlStation` field from `/detail`. A Creator 5 Pro does not report that field at all — verified against real hardware (pid 41, firmware 1.9.4): the `hasMatlStation` key is absent from `/detail` entirely, under any name, while `matlStationInfo` reports `slotCnt: 4` and four loaded slots. The flag therefore parsed as `None`, the entities were never created, and the v1.3.0 change that moved the gate off `is_ad5x` had no effect. Capability detection now lives in `util.has_material_station()`, which accepts populated slot data (`slotCnt` / `slotInfos`) as proof of the station, the same way the library's own AD5X heuristic does.
+- **Capability-gated entities are no longer decided once at setup.** The Material Station slot images and every `availability_fn`-gated sensor are now also added when the capability first shows up on a later refresh, so a station that reports in after the first poll — or a first refresh that failed outright — no longer leaves the printer permanently without those entities.
+
+### Notes
+- The printer's HTTP API only reports its most recent files (10 on current firmware); older files can still be printed by passing `file_name` to `flashforge.print_file`. The TCP full-directory listing is deliberately not used — this integration stays HTTP-only.
+- Per-file metadata depends on the model: the AD5X returns `gcodeListDetail` with print time, filament weight, and per-tool material data, while the Creator 5 series (verified on a Creator 5 Pro, firmware PID 41) returns plain file names. On those printers multi-material files are therefore sent without mappings and the printer uses the tool/slot assignment stored in the file. `scripts/file_print_probe.py` dumps what a given printer actually reports.
+- Hardware-verified on a Creator 5 Pro: starting a single- and a three-material file from Home Assistant works, the printer accepts the job and begins printing. The run was cancelled shortly after the start, so the resulting tool-to-slot **color assignment itself has not been confirmed end to end** — only that the firmware accepts the job without mappings.
+
 ## [1.3.1] - 2026-07-23
 
 ### Fixed