Generic Camera alternates between "Unavailable" and "Idle" when camera is powered off

[MikOsle]

The problem

I am experiencing an issue with the Generic Camera integration. When one of my cameras is powered off, the camera entity alternates between the states "unavailable" and "idle". This behavior is unexpected, as the camera is completely powered off and cannot respond to any network requests.
The camera is one I only use occasionally, but during power-off periods, this alternating state causes problems in my automations and dashboard, where I need a clear and consistent indication of the camera is actual availability.

When the camera is powered on, it consistently remains in the "idle" state, as expected, and the camera stream works fine.

What version of Home Assistant Core has the issue?

2024.12.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Generic Camera

Link to integration documentation on our website

https://www.home-assistant.io/integrations/generic

Diagnostics information

config_entry-generic-01JF4TW7G69Q0RCW4PA16E34PN.json

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant]

Hey there @davet2001, mind taking a look at this issue as it has been labeled with an integration (generic) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of generic can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign generic Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

generic documentation
generic source
_{^{(message by IssueLinks)}}

[davet2001]

Hi @MikOsle. Confirmed. I can reproduce this, and it is not the intended behaviour.

The timing between the changes is not consistent though
idle->unavailable seems to be 3sec in all cases (yours and mine).
unavailable ->idle seems to be consistently around~46minutes in my case, 16mins in yours.

Hmmm.

[davet2001]

Ok, I can see what is happening.
The problem occurs here:

core/homeassistant/components/stream/__init__.py

Lines 429 to 468 in 3560148

	self._set_state(True)
	self._diagnostics.set_value(
	"keepalive", self.dynamic_stream_settings.preload_stream
	)
	self._diagnostics.set_value(
	"orientation", self.dynamic_stream_settings.orientation
	)
	self._diagnostics.increment("start_worker")
	try:
	stream_worker(
	self.source,
	self.pyav_options,
	self._stream_settings,
	stream_state,
	self._keyframe_converter,
	self._thread_quit,
	)
	except StreamWorkerError as err:
	self._diagnostics.increment("worker_error")
	self._logger.error("Error from stream worker: %s", str(err))
	stream_state.discontinuity()
	if not _should_retry() or self._thread_quit.is_set():
	if self._fast_restart_once:
	# The stream source is updated, restart without any delay and reset the retry
	# backoff for the new url.
	wait_timeout = 0
	self._fast_restart_once = False
	self._thread_quit.clear()
	continue
	break
	self._set_state(False)
	# To avoid excessive restarts, wait before restarting
	# As the required recovery time may be different for different setups, start
	# with trying a short wait_timeout and increase it on each reconnection attempt.
	# Reset the wait_timeout after the worker has been up for several minutes
	if time.time() - start_time > STREAM_RESTART_RESET_TIME:
	wait_timeout = 0
	wait_timeout += STREAM_RESTART_INCREMENT

There is a retry loop which gradually increases its retry interval. When the connection attempt is started, it sets the status to 'True' (=available/idle), then when it fails it is set to False(=unavailable).

So really, the 'idle' state means 'I have started a retry attempt and it has not returned an error yet'.

A few seconds later, it returns an error and the state gets set back to 'unavailable'.

Then the process loops, with a gradually increasing wait interval.

[home-assistant]

Hey there @hunterjm, @uvjustin, @allenporter, mind taking a look at this issue as it has been labeled with an integration (stream) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of stream can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign stream Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

stream documentation
stream source
_{^{(message by IssueLinks)}}

[davet2001]

Ok, I have a solution that works, but it seems quite an overkill:
https://github.com/home-assistant/core/compare/dev...davet2001:home-assistant:issue13336_defer_set_stream_available_until_connected?expand=1

@hunterjm I would value your thoughts on this before I go ahead with a pull request.

I could have got the wrong end of the stick here.

[davet2001]

@uvjustin or @allenporter Do you have any thoughts on this?
I think we need to do something about it as the issue is genuine.

[allenporter]

Part of the problem is we don't have a way to tell when the worker is connected or not successful in this code, but we can add some new interfaces in worker to handle this. This seems like the same change we need to make to support generic previews anyway. I can take a look at fixing this as a follow up to #134020