Skip to content

Command queue: prioritize user commands over status polls #680

Closed

Description

@GreenGrassBlueOcean

Problem

User commands and status polls share a single FIFO queue (asyncio.Queue in gateway_sessions.py). On busy systems or when the gateway is slow to NACK, a user action (e.g. turning on a light) can be delayed for several seconds while earlier status polls finish.

The is_status_request flag is already present on queued tasks, but it is not used for prioritization.

Current mitigations

Several related issues have already been improved:

These reduce how often the queue fills up, but the underlying FIFO behavior remains.

Proposal

Replace the plain FIFO with a priority queue:

  • User commands (and any frame with is_status_request=False) are dequeued first
  • Status requests are dequeued only when no user commands are waiting
  • FIFO ordering is preserved within each class
  • The existing “read-back after write” pattern must be preserved: a status request that is queued after a command for the same device must not overtake that command

Acceptance criteria

  • A user command queued while status polls are pending is sent before those polls
  • A status request queued after a command for the same entity still runs after that command
  • Existing tests for queue pacing and silent-zone skipping continue to pass
  • No regression on single-session gateways (MH200/MH201)

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions