v0.2.16 - Battery sensor duplicate fixes

Battery sensor fixes contributed by @ermitovski (PRs #27, #28, #29).

Fixes

#27 — Avoid duplicate Battery Percentage entity on MYGGSPRAY

The hub exposes MYGGSPRAY as occupancySensor + lightSensor sharing a relation_id, with both halves reporting battery_percentage. The duplicate *_battery_percentage_2 entity is now suppressed by binding the battery diagnostic to the motion side only.

Pre-existing _2 entities become orphaned (state unavailable) and can be deleted from the device page in HA.

#28 — De-duplicate controller battery diagnostic

Multi-button controllers (BILRESA, SOMRIG, RODRET, STYRBAR, ...) are reported by the hub as N separate controller devices that share a relation_id. The previous filter assumed only the primary half had battery_percentage, but BILRESA reports it on both halves, producing duplicate *_2 entities under the same HA device.

Controllers are now grouped by relation_id and a single primary is elected per group. Secondary halves rebind to the primary in the device registry so remotePressEvents still resolve to a registered entity. Multi-button device-trigger generation is preserved.

#29 — Emit battery diagnostic on dynamically discovered sensors

When a battery-powered sensor (waterSensor, motionSensor, occupancySensor, openCloseSensor) was paired with HA already running, the WebSocket-driven discovery path created only the primary entity — the companion Battery Percentage diagnostic appeared only after the next HA restart.

The dynamic discovery path now mirrors the static startup path, so freshly paired BADRING / motion / open-close sensors show the battery diagnostic without a restart.

Upgrade notes

If you have pre-existing *_battery_percentage_2 entities on MYGGSPRAY or multi-button controllers, they will become unavailable after this update. Delete them from the device page in HA Settings → Devices.

Tested on HA with 3x MYGGSPRAY motion sensors before merge.

v0.2.15 - Guard color_mode writes against unsupported modes

What's fixed

Brightness-only lights (e.g. TRÅDFRI Driver, MYGGSPRAY controllers) no longer raise HomeAssistantError: "... set to unsupported color mode hs, expected one of [ColorMode.BRIGHTNESS]" after scene activation.

Root cause

Dirigera hub scene payloads include `colorHue` / `colorSaturation` / `colorTemperature` keys for every device in a group, even for devices that don't support those color modes. Four code paths wrote `_color_mode = ColorMode.HS` (or `COLOR_TEMP`) without validating against `_supported_color_modes`. Once the mode was poisoned, HA core rejected every subsequent `light.turn_on` until the integration was reloaded.

Fix

All four paths now guard writes (and outbound commands) with `ColorMode.X in supported_color_modes`:

• `light.ikea_bulb.async_turn_on`
• `light.ikea_bulb_device_set.async_turn_on`
• `hub_event_listener` `deviceStateChanged` handler (introduced in v0.2.13/14)
• `hub_event_listener._apply_scene_actions` (introduced in v0.2.13/14)

Brightness-only entities now stay on `ColorMode.BRIGHTNESS` regardless of what the hub emits.

Credit

Thanks to @charleslemaux for reporting and fixing — see #26.

Files changed

• custom_components/dirigera_platform/hub_event_listener.py
• custom_components/dirigera_platform/light.py

Upgrade notes

• HACS users: update via HACS → Dirigera Platform → Update.
• Manual install: restart Home Assistant after copying the new `custom_components/dirigera_platform/`.
• No config migration needed.

v0.2.14

Fix: Proper split-device entity naming (PR #25 by @crowbarz)

This is the correct fix for issue #23 (MYGGSPRAY illuminance entity not inheriting user-configured name). The previous attempt in v0.2.13 changed the wrong layer.

What changed: Sets has_entity_name = True on ikea_base_device_sensor and returns only the entity-specific suffix (e.g. "Illuminance") from the name property. HA then automatically prepends the device name from device_info, which correctly uses the merged device name for split-devices.

This is the HA-recommended naming pattern and ensures all entities of a merged split-device use the user-configured name from the IKEA Home Smart app.

Note: After updating, you may need to restart Home Assistant. Existing entity IDs should remain unchanged.

Thank you @crowbarz for the fix and the thorough analysis!

Fixes #23

v0.2.13

Fix: Split-device entity naming (issue #23)

For split-devices like MYGGSPRAY (occupancySensor + lightSensor), the IKEA app only lets you rename the "primary" device. The secondary device keeps its factory default name.

Previously, the illuminance entity would show as "MYGGSPRAY wrlss mtn sensor Illuminance" even if you renamed the sensor to "Front Bedroom Sensor" in the IKEA app. Now all entities from merged split-devices inherit the user-configured name from the primary entity.

Before: sensor.front_bedroom_sensor_myggspray_wrlss_mtn_sensor_illuminance
After: sensor.front_bedroom_sensor_illuminance

Note: After updating, you may need to restart Home Assistant for existing entity names to update. New entities will get the correct name immediately.

Update: Via HACS → Updates, or reinstall from the repo.

Fixes #23

v0.2.12

Fix: Non-empty keepalive message + shorter interval

v0.2.11's empty string keepalive (send("")) didn't prevent disconnects — the hub likely ignored the zero-length frame. @mickl089 still saw disconnects after 37 minutes.

Changes:

• Send {"type":"ping"} instead of empty string — a proper non-empty text frame
• Reduced interval from 25 to 15 minutes (well below the hub's ~60 min timeout)
• Keepalive events now logged at INFO level (was DEBUG) — you can verify they're firing without full debug logging

What to look for in logs after updating:

INFO  WebSocket keepalive timer started (900s interval)
INFO  WebSocket keepalive sent     ← should appear every 15 min

If disconnects continue, the session_duration in the close message will tell us whether keepalives are being sent but ignored, or not sent at all.

Update: Via HACS → Updates, or reinstall from the repo.

v0.2.11

Fix: Application-level WebSocket keepalive prevents hub disconnect

Root cause found for issue #12. Thanks to @mickl089's excellent debug logs (v0.2.10), we identified the exact mechanism:

1. The Dirigera hub disconnects WebSocket clients after ~60 minutes of inactivity
2. The hub does NOT count WebSocket protocol-level ping frames (opcode 0x9) as activity
3. Only application-level data frames (text/binary) reset the inactivity timer
4. Setups with environment sensors (VINDSTYRKA, ALPSTUGA, TIMMERFLOTTE) never see this because those sensors generate continuous WebSocket events every few minutes
5. Setups with only door/window sensors or smart plugs go silent between state changes → hub considers the connection idle → disconnect after 60 min

The fix: A daemon timer sends an empty application-level text frame to the hub every 25 minutes. This resets the hub's inactivity timer without requiring any device events.

Evidence: @mickl089's session_duration was exactly 3612s (~60 min). Our own setup with VINDSTYRKA sensors showed zero disconnects over 3+ days — the environment sensor events were acting as accidental keepalives.

Update: Via HACS → Updates, or reinstall from the repo.

Fixes #12

v0.2.10

Diagnostics improvement for "disconnected due to inactivity"

This release addresses issue #12 — WebSocket disconnects from the Dirigera hub. Two changes:

1. Actually sleep 10s between reconnect attempts

The retry loop previously logged "will sleep 10 seconds before retrying" but didn't actually sleep. This caused a tight retry loop if disconnects happened frequently. Fixed to honor the log message.

2. New on_open / on_close diagnostics

Added callbacks that log at INFO level when the WebSocket connection is established or closed, including the session duration. This makes it much easier to see:

• Whether the hub is disconnecting us (clean close from hub) or we're crashing
• How long sessions typically last before being dropped
• Whether reconnect attempts are happening successfully after a disconnect

If you've been experiencing "disconnected due to inactivity" issues, please update to v0.2.10 and share the new log output from around a disconnect event — specifically the new Dirigera WebSocket closed (code=..., session_duration=...s) line followed by what happens in the next 60 seconds.

Update: Via HACS → Updates, or reinstall from the repo.

v0.2.9

Feature: Light device triggers (upstream PR sanjoyg#197)

Merged from sanjoyg/dirigera_platform#197 by @acdu1.

You can now use Dirigera lights as automation triggers:

• turned_on — fires when a light turns on
• turned_off — fires when a light turns off

This works in the HA automation editor under Device triggers. Existing controller button triggers (single_click, long_press, double_click) continue to work as before.

Update: Via HACS → Updates, or reinstall from the repo.

v0.2.8

Fix: ikea_bulb_device_set registration (upstream PR sanjoyg#196)

Merged from sanjoyg/dirigera_platform#196 by @pablotoledo.

Bug 1: ikea_bulb_device_set registered itself directly into the hub event listener instead of using the registry_entry wrapper. This caused sync_all_device_areas() to crash with:

AttributeError: 'ikea_bulb_device_set' object has no attribute 'entity'

Bug 2: Used requests.exceptions.ConnectionError instead of Python's built-in ConnectionError for ConfigEntryNotReady handling. The requests import is no longer needed.

Update: Via HACS → Updates, or reinstall from the repo.

v0.2.7

Fix: replace deprecated hass.loop with asyncio event loop

HomeAssistant 2026.1+ removed the hass.loop property. The hub event listener used it in 5 places to schedule async tasks from the WebSocket thread. This caused event processing to silently fail:

'NoneType' object has no attribute 'loop'

Impact: ~95,000 errors/day at DEBUG level. Event processing (state changes, area sync, discovery) was broken.

Fix: Save the event loop at init time via asyncio.get_event_loop() and use that reference instead of the removed hass.loop.

Update: Via HACS → Updates, or reinstall from the repo.