Skip to content

Avoid polling after segmented light commands#676

Open
aserper wants to merge 1 commit into
wez:mainfrom
aserper:fix/segment-command-polling
Open

Avoid polling after segmented light commands#676
aserper wants to merge 1 commit into
wez:mainfrom
aserper:fix/segment-command-polling

Conversation

@aserper
Copy link
Copy Markdown

@aserper aserper commented May 16, 2026

Summary

Avoid scheduling the follow-up Platform API state poll after segmented light commands.

Segmented light entities are already configured as optimistic in Home Assistant. After a segment color/brightness command, the bridge currently schedules the same post-control poll used for whole-device commands. For segmented devices, that Platform API poll reports only a device-level light state, not per-segment state. Reconciling immediately against that simplified state can make Home Assistant and subsequent controls treat a single whole-device color as authoritative after segment updates.

This change keeps the existing per-device serialization for segment commands, but skips the post-control poll for those segment commands.

Why

Observed with a segmented Govee light device:

  1. Home Assistant sends a command to a segment entity.
  2. govee2mqtt sends segmentedBrightness / segmentedColorRgb through the Platform API.
  3. The Platform API returns success.
  4. govee2mqtt schedules a post-control poll.
  5. The poll returns a single device-level DeviceState.color, not the per-segment layout.
  6. That state is reconciled as the device's current light state even though the command was segment-specific.

Sanitized log excerpt:

INFO service::hass  Command for <segmented-device> segment <n>: {"state":"ON","color":{"r":...,"g":...,"b":...},"brightness":...}
INFO service::hass  Using Platform API to control <segmented-device> segment
INFO platform_api   control_device result: code=200, message="success", capability=SegmentColorSetting(instance="segmentedBrightness")
INFO platform_api   control_device result: code=200, message="success", capability=SegmentColorSetting(instance="segmentedColorRgb")
INFO service::state Polling <segmented-device> to get latest state after control
INFO service::state requesting update via Platform API <segmented-device> Some(DeviceState { color: DeviceColor { r: ..., g: ..., b: ... }, brightness: ..., source: "PLATFORM API", ... })

The important detail is that the segment commands succeed, but the immediate poll only reports a whole-device color state.

Change

  • Add a Coordinator::new_without_poll constructor.
  • Add State::resolve_device_for_control_without_poll to keep the serialization lock without scheduling the delayed state poll.
  • Use the no-poll control path for mqtt_light_segment_command.

Whole-device commands still use the existing post-control polling behavior.

Validation

Locally passed:

cargo fmt --all -- --check
cargo test --all -- --show-output
cargo build --all

Segment light entities are optimistic, but the control path still scheduled the generic post-control Platform API poll. For segmented devices that poll returns a device-level color rather than per-segment state, so skip the follow-up poll for segment commands while preserving serialized device control.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant