v2.10.0

UHZ68LV profile additions

• Power Mode (Standby) select: switch standby power behavior between Eco. (<0.5W) and Communication (<8W).
• LAN Firmware Version sensor (diagnostic, disabled by default).
• Current Lamp Watt sensor: live lamp power draw in watts.

🤖 Generated with Claude Code

2.9.6 — Fix Power never registering as on (UHD60)

Fixed

• Power switch permanently stuck reading `off` even while the UHD60 stayed on, confirmed via debug logs showing `RX <- Optoma_PJ> OK1` on every single poll — unstripped, despite v2.9.5's fix. Root cause: that fix anchored its strip to the very start of the line, but the power read's raw reply had stray control/escape bytes or an embedded line break in front of the prompt that plain `.strip()` doesn't remove, so the anchored match never fired.
• Replaced prefix-stripping with marker search: instead of assuming the console noise is a clean, strippable prefix, search the line for a real protocol marker (`Ok`, `INFOn`, or a bare `P`/`F` at the end) and keep only from there on — regardless of what precedes it or how it's shaped. This also subsumes the single-echo and doubled-echo cases from v2.9.1/v2.9.5 in one pass.

This should be the last variant of the console-noise problem — the new approach doesn't rely on the noise having any particular shape, just that a real reply marker exists somewhere in the line.

2.9.5 — Fix intermittent Power showing off while projector is on

Fixed

• Power switch intermittently flipping to `off` while the UHD60 is actually on. v2.9.1 stripped the UHD60's console-echoed prompt (`Optoma_PJ> `) once per reply, but debug logs showed it sometimes doubles up (`Optoma_PJ> Optoma_PJ> OK1`). A single strip left `Optoma_PJ> OK1` behind, which still failed to parse — and for the power switch specifically, an unparseable reply silently evaluated as `off` with no way to distinguish it from a genuine off state.
• The strip now loops until a real protocol marker (`Ok`/`P`/`F`/`INFO`) surfaces, instead of stopping after one pass. Also guards against genuinely unparseable input looping forever.

This should fix any entity that occasionally showed a stale/wrong value on the UHD60, not just Power — it was the same underlying parse failure wherever it landed.

2.9.4 — UHD60 profile now verified on real hardware

Changed

• The UHD60 profile is now marked `verified: true` — live-tested over LAN against real hardware (firmware C015) across this investigation (v2.9.0–v2.9.3). Power, Input Source, Picture Mode, Aspect Ratio, Brightness, Contrast, Audio/AV Mute, Firmware Version, Serial Number, and Lamp Hours all confirmed reading and writing correctly.
• 3D and 3D Format read `Unknown` until set from Home Assistant — that's expected on every profile in this integration, not a UHD60-specific gap: Optoma's protocol has no read-back command for either.

2.9.3 — Fix remaining UHD60 Unknowns (zero-padded reply values)

Fixed

• Picture Mode and Aspect Ratio still Unknown on the UHD60 after v2.9.2's widened code mapping. Root cause found via debug logs from a live unit: the projector zero-pads some replies (`OK03` for documented code `3`, `OK07` for `7`) while others come back unpadded (`OK8`). `read_options` lookups were exact string matches against bare-integer keys, so the padded replies matched nothing.
• Fixed generically in the coordinator's shared value parser: numeric reads/lookups now fall back to an `int()`-normalized match (which already shrugs off zero-padding and sign characters) after the exact-match attempt, for `select`, `sensor`, `switch`, and `binary_sensor` entities alike — not just the two UHD60 fields that surfaced it.

This should be the last of the UHD60 read-parsing issues from this investigation: Firmware, Serial, Input Source, Brightness, Contrast, Power, Picture Mode, and Aspect Ratio have all now been confirmed reading correctly.

2.9.2 — UHD60: fix remaining Picture Mode / Aspect Ratio Unknowns

Fixed

• UHD60 Picture Mode and Aspect Ratio still showing Unknown after v2.9.1's console-prompt fix. The underlying read was parsing fine (confirmed via Input Source, Brightness, Contrast, Firmware, and Serial Number all reading correctly on a live unit) — the two selects' `read_options` just only covered a guessed subset of codes, so the projector's actual current mode/ratio didn't match anything. Widened both to the full documented code set from Optoma's RS232 Protocol Function List.

2.9.1 — Fix UHD60 reads (console-prompt-prefixed replies)

Fixed

• Reads showing Unknown / garbled values on the UHD60 (and potentially other models with a similar LAN bridge): the projector's "RS232 by Telnet" port echoes a shell-style prompt (e.g. Optoma_PJ> ) immediately before every reply. This defeated the protocol's P/F/Ok markers — sensors displayed the raw noisy string (Optoma_PJ> OKC015) and read-backed selects (Input Source, Picture Mode, Aspect Ratio) fell back to Unknown since the leftover text didn't match any option code. Writes were unaffected, which is why commands like changing input source already worked.
• Fixed at the shared transport layer, so it benefits any model with this quirk, not just the UHD60.

Confirmed against literal garbled values captured from a live UHD60.

2.9.0 — Optoma UHD60 profile, one-click HACS install

Added

• Optoma UHD60 projector profile — Power, AV/Audio Mute, Image Freeze, 3D, Input Source (HDMI1/HDMI2/VGA), Picture Mode, Aspect Ratio, 3D Format, Brightness/Contrast/Sharpness, Lamp Hours, Firmware Version, Serial Number, Resync, and test pattern support. Transcribed from Optoma's official RS232 Protocol Function List; not yet verified against real hardware — please open an issue/PR with corrections if you own this model.
• One-click install: README now leads with "Add to HACS" and "Start setup" badges (my.home-assistant.io redirects), instead of requiring you to manually open HACS's Custom repositories dialog.

Notes

• After updating, existing UHD60 users on the uhz68lv profile (the previous auto-detect fallback) should reconfigure the integration and explicitly pick Optoma UHD60 from the model dropdown — auto-detect doesn't reliably distinguish this model, so it needs a manual select.