v0.2.12

Full Changelog: v0.2.11...v0.2.12

v0.2.11

Full Changelog: v0.2.10...v0.2.11

v0.2.10

Full Changelog: v0.2.9...v0.2.10

v0.2.9

Honour the transition (fade) parameter on light commands.

Same code already running on the Pinecrest and Miami appliances; this release
publishes the tag that was pushed but never released.

v0.2.8

Performance: remove debug dispatch logging and redundant state write

v0.2.7

Bug fix: monitoring not re-sent after LIP reconnect

After a keepalive timeout or network interruption, the Lutron bridge drops its monitoring subscriptions. The previous code only re-authenticated on reconnect but did not re-send the #-MONITORING enable commands. This caused button events, zone level changes, and LED state updates to silently stop working until the next full HA restart.

Changes

• Extract _async_setup_monitoring() from async_connect()
• Call it in both the initial connect and every reconnect path in _async_disconnected()
• Button presses, light state changes, and keypad LED events now resume correctly after any connection drop

v0.2.6 — Restore event.* entities; fix double lutron_event

What's changed

Fixed: double lutron_event per button press

Every button press was triggering automations twice. Root cause: LutronEventEntity and a separate subscriber were both firing lutron_event for each button action.

Restored: event.* entities for all keypad buttons

The upstream repo exposes each button as a HA event.* entity. These are back, matching the original behaviour.

Architecture (v0.2.6)

Each button now has two independent subscribers with no overlap:

• _setup_button_events() callback fires lutron_event bus (for existing automations)
• LutronEventEntity updates event.* entity state only (for modern HA EventEntity triggers)

Existing automations using lutron_event require no changes.

v0.2.4

Fix: Button/keypad events silently stop working after connect

Root cause

Two bugs combined to kill all LIP message processing shortly after startup:

1. _update_callback in the event entity used a bare dict lookup (action_number_to_event[value]), which raised KeyError for any action number not in the map (3/4/5/6/32). Lutron sends action 1 (ENABLE) for every device component immediately after monitoring is enabled on connect — this is what triggered the crash.

2. _process_message in the protocol layer only caught ValueError, so the KeyError propagated all the way up through _async_run_once into the async_run loop, terminating the task entirely. After that, no LIP messages were processed at all — button presses, LED state updates, occupancy, nothing.

Fix

• Use .get() instead of [] in _update_callback so unknown action numbers are silently ignored rather than raising.
• Broaden the exception catch in _process_message from ValueError to Exception so a misbehaving callback can never kill the read loop.

v0.2.3

Add optional area suggestion control

New Suggest Areas option in the integration config (Settings → Integrations → Lutron LIP → Configure).

• When enabled (default): Lutron area names are suggested to HA when a device is first registered — existing behavior, no change for current installs.
• When disabled: new devices are registered without an area suggestion, letting you assign them manually in HA.

Already-registered devices with manually assigned areas are never affected regardless of this setting.

v0.2.2

Fix: Revert incorrect Ketra color temperature implementation

v0.2.1 incorrectly identified LIP action 17 as a color temperature control for Ketra PHANTOM_SPECTRUM fixtures.

Live protocol testing on the HomeworksQS controller confirmed:

• Action 17 = raw brightness in 0–65279 scale (equivalent to action 1 in 0–100%)
• No color/CCT control exists via LIP — all tested action numbers (14, 15, 16, 18) and multi-parameter formats return ~ERROR,1

PHANTOM_SPECTRUM outputs (Ketra fixtures) continue to work correctly as standard dimmable lights. Real-time arbitrary color/CCT control for Ketra via the LIP protocol is not possible — it would require LEAP or the Ketra N4 API, neither of which is exposed by this controller.