Much log entries 'pipe closed by peer'

[Kanecaine]

Description

From time to time, I see a huge number of the following entries in the log:

2026-08-21 22:08:22.356 WARNING (MainThread) [asyncio] pipe closed by peer or os.write(pipe, data) raised exception.
2026-08-21 22:08:41.223 WARNING (MainThread) [asyncio] pipe closed by peer or os.write(pipe, data) raised exception.
2026-08-21 22:08:41.223 WARNING (MainThread) [asyncio] pipe closed by peer or os.write(pipe, data) raised exception.
2026-08-21 22:08:41.223 WARNING (MainThread) [asyncio] pipe closed by peer or os.write(pipe, data) raised exception.
...
(I've truncated a few hundred entries)
...
2026-08-21 22:08:42.671 WARNING (MainThread) [asyncio] pipe closed by peer or os.write(pipe, data) raised exception.
2026-08-21 22:08:42.671 WARNING (MainThread) [asyncio] pipe closed by peer or os.write(pipe, data) raised exception.
2026-08-21 22:08:42.671 WARNING (MainThread) [asyncio] pipe closed by peer or os.write(pipe, data) raised exception.
2026-08-21 22:08:42.676 WARNING (Thread-1 (_monitor)) [homeassistant.util.logging] Module asyncio is logging too frequently. 200 messages since last count

There were also the following entries afterward, but I'm not sure if they're directly related:

Traceback (most recent call last): File "/usr/local/lib/python3.14/asyncio/tasks.py", line 488, in wait_for return await fut ^^^^^^^^^ File "/usr/local/lib/python3.14/asyncio/streams.py", line 48, in open_connection transport, _ = await loop.create_connection( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lambda: protocol, host, port, **kwds) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.14/asyncio/base_events.py", line 1143, in create_connection sock = await self._connect_sock( ^^^^^^^^^^^^^^^^^^^^^^^^^ exceptions, addrinfo, laddr_infos) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.14/asyncio/base_events.py", line 1042, in _connect_sock await self.sock_connect(sock, address) File "/usr/local/lib/python3.14/asyncio/selector_events.py", line 647, in sock_connect return await fut ^^^^^^^^^ asyncio.exceptions.CancelledError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/local/lib/python3.14/site-packages/pytapo/media_stream/streamer.py", line 278, in _stream_to_ffmpeg async with mediaSession: ^^^^^^^^^^^^ File "/usr/local/lib/python3.14/site-packages/pytapo/media_stream/session.py", line 85, in __aenter__ await self.start() File "/usr/local/lib/python3.14/site-packages/pytapo/media_stream/session.py", line 100, in start self._reader, self._writer = await asyncio.wait_for( ^^^^^^^^^^^^^^^^^^^^^^^ asyncio.open_connection(self.ip, self.port), timeout=CONNECTION_TIMEOUT ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ) ^ File "/usr/local/lib/python3.14/asyncio/tasks.py", line 487, in wait_for async with timeouts.timeout(timeout): ~~~~~~~~~~~~~~~~^^^^^^^^^ File "/usr/local/lib/python3.14/asyncio/timeouts.py", line 115, in __aexit__ raise TimeoutError from exc_val TimeoutError

2026-08-21 22:23:00.391 ERROR (MainThread) [homeassistant] Error doing job: Task was destroyed but it is pending! (task: <Task pending name='Task-90092' coro=<Streamer._stream_to_ffmpeg() running at /usr/local/lib/python3.14/site-packages/pytapo/media_stream/streamer.py:278> wait_for=<Future pending cb=[Task.task_wakeup()]>>)

Reproduction Steps

I can't reproduce it reliably, but I was able to trigger it several times after starting the camera stream via a picture entity:

type: picture-entity
entity: camera.tapo_c425_hd_stream_direct
camera_image: camera.tapo_c460_hd_stream_direct
name: C425
show_state: true
show_name: true
camera_view: auto
fit_mode: cover

Apart from the log entries, however, no major problems have been identified. The streams still start, though there may be a delay or you may need to trigger the stream again.

Expected behavior

Of course, timeouts can happen from time to time with a Wi-Fi camera. But that shouldn't result in such a flood of log entries.

If applicable, add error logs.

No response

Device Firmware

1.2.4 Build 260521 Rel.80578n

Integration Version

7.1.25

Last known working integration version

no

Using stream component

No

Does camera work via official integrations?

N/A

HASS Environment

Home Assistant OS on Proxmox

Search for similar issues

Yes

LLM Usage

I confirm

Additional information

Thanks in advance.

Debug Logs (Required)

home-assistant_tapo_control_2026-08-21T20-56-09.529Z.log

[stormcrow2000]

I traced this on my own install and believe the trigger is a periodic camera.snapshot against a *_hd_stream_direct entity, with the warning burst coming from the finally block added in #1353.

Environment: HA core-2026.8.3, HAOS 18.2 (RPi4), Python 3.14.6, tapo_control 7.1.25, Tapo C425.

Mechanism

TapoDirectCamEntity.async_camera_image (custom_components/tapo_control/camera.py) tears down in this order:

finally:
    if proc.returncode is None:
        proc.kill()
        await proc.wait()
    await streamer.stop()
    info["streamProcess"].cancel()

ffmpeg is killed first; the pytapo feeder task (streamer.py::_stream_to_ffmpeg, the one in the traceback above) is cancelled last. In the window between those two statements the feeder keeps writing camera data into ffmpeg's now-closed stdin.

CPython then does the rest — _UnixWritePipeTransport.write() in asyncio/unix_events.py:

if self._conn_lost or self._closing:
    if self._conn_lost >= constants.LOG_THRESHOLD_FOR_CONNLOST_WRITES:
        logger.warning('pipe closed by peer or '
                       'os.write(pipe, data) raised exception.')
    self._conn_lost += 1
    return

LOG_THRESHOLD_FOR_CONNLOST_WRITES is 5, so every write past the fifth logs one line. Nothing throttles it, hence the "few hundred entries" you truncated.

Signature (matches the timestamps in the report)

On my install the warnings are not continuous. They come as one burst per failed snapshot: 90–330 lines inside ~15 ms, then nothing for hours. Every burst timestamp fell exactly on my snapshot automation's trigger grid, at the same sub-second offset. Highest hour had ~3100 lines, quietest had 1.

Two observations that may help narrow it down:

• A successful snapshot produces zero warnings. I verified a good run live — file written, no asyncio output. Only the failing path floods.
• My bursts were night-heavy purely because my snapshot job is gated behind a privacy-mode condition that is only off at night. So the "from time to time" in the report is probably just "whenever the snapshot path runs and the grab fails", not something time-of-day specific.

Volume, for scale: 13,843 lines over roughly a day, which was 69 % of my entire retrievable journald window — real errors older than that were pushed out entirely. That is the part that actually hurts.

Suggested fix

Cancel (and await) the feeder before killing ffmpeg, so nothing is still writing when the pipe goes away:

finally:
    task = info["streamProcess"]
    task.cancel()
    with contextlib.suppress(asyncio.CancelledError):
        await task
    if proc.returncode is None:
        proc.kill()
        await proc.wait()
    await streamer.stop()

Closing ffmpeg's stdin explicitly before the kill would also work. Either way the feeder should never outlive the pipe it writes to.

Happy to test a patch — I can reproduce on demand by pointing a periodic camera.snapshot at the direct-stream entity.