Home Assistant rest_command 10-second timeout and Sume async jobs

rest_command times out at 10 seconds by default. Sume sync waits cap at 30. Submit with mode async, take the job id, and poll in a second command.

5 min readSume
All posts

Why the timeout matters

Home Assistant's RESTful Command integration gives each request a timeout of 10 seconds unless you change it. Sume's server-side sync and subscribe modes can block for up to 30 seconds, and image, video and avatar jobs often take longer than either number. So the safe pattern is mode: async: the submit returns a job id immediately and the job keeps running whether or not Home Assistant is still listening.

Sume's job docs are explicit that a client timeout does not cancel the job. It keeps running and still bills, which is why you store the id rather than resubmit.

The two numbers side by side

The Home Assistant default and the Sume sync cap are independent, but both are short compared with real generation time.

Timeouts in the two products (read 2026-10-03)
SettingValueWhere it comes from
rest_command timeout default10 secondsHome Assistant RESTful Command page
Largest Sume sync wait30 seconds (wait_timeout_seconds 0 to 30)Sume jobs and results docs
Sume async submitReturns a job id with status_url and result_urlSume jobs and results docs

Submit, then poll in a second command

Define one command that submits and one that reads status. The status route returns a terminal flag, a result_ready flag and a next_poll_after_seconds hint, so an automation can wait that long before the next read.

Home Assistant's page says a rest_command response is available through response_variable as status, content and headers, which is how the job id gets from the first command into the second.

rest_command:
  sume_status:
    url: "https://api.sume.com/v1/jobs/{{ job_id }}/status"
    method: get
    headers:
      authorization: !secret sume_bearer
    timeout: 10

Do not retry the paid submit blindly

If the submit command fails on a network error, the job may already exist. Sume's errors docs say not to retry unsafe submit requests without an Idempotency-Key. Home Assistant's page documents headers as a plain map with a secret in it, so a header that changes per run is not promised there. Keep submits that you may retry in a tool that sets headers per request, or read GET /v1/jobs to look for the job before sending again.

Failed and canceled jobs answer the result route with 409 job_not_completed, so read the status route first and fetch the result only when result_ready is true.

Choosing a poll cadence in Home Assistant

A time-pattern trigger is the simplest poller: it fires on a schedule, reads the stored id, and calls the status command. Because the status payload includes next_poll_after_seconds, a pattern that fires every few seconds wastes calls when Sume has asked for a longer gap, and one that fires too rarely leaves a finished image sitting unseen.

A practical compromise is to poll on a fixed short pattern while the helper holds an id, skip the call when the previous hint has not elapsed, and clear the helper once terminal is true. Video and avatar-video jobs routinely run for minutes, so give those a longer overall deadline in your automation; Sume's docs suggest 20 minutes as a reasonable client-side deadline for video, and stress that it is a client choice rather than a server limit.

If you would rather not poll at all, Sume can call you: submit with mode: webhook and a public HTTPS webhook_url. Home Assistant has its own webhook trigger, but that is outside what the pages cited here document, so check Home Assistant's webhook trigger docs before relying on it. Job webhooks are terminal-only, and Sume says to keep status polling available for deliveries that never arrive.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume