Just updated the above today and the log is filling with these errors
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.7/site-packages/aiohttp/web_protocol.py", line 447, in start
await resp.prepare(request)
File "/srv/homeassistant/lib/python3.7/site-packages/aiohttp/web_response.py", line 353, in prepare
return await self._start(request)
File "/srv/homeassistant/lib/python3.7/site-packages/aiohttp/web_response.py", line 667, in _start
return await super()._start(request)
File "/srv/homeassistant/lib/python3.7/site-packages/aiohttp/web_response.py", line 410, in _start
await writer.write_headers(status_line, headers)
File "/srv/homeassistant/lib/python3.7/site-packages/aiohttp/http_writer.py", line 112, in write_headers
self._write(buf)
File "/srv/homeassistant/lib/python3.7/site-packages/aiohttp/http_writer.py", line 67, in _write
raise ConnectionResetError('Cannot write to closing transport')
ConnectionResetError: Cannot write to closing transport
2019-06-29 16:15:19 ERROR (MainThread) [aiohttp.server] Unhandled exception```
I didn't change my config between updates so I can't see what's causing these errors.
Any pointers would be greatly appreciated
I wouldn’t consider it a bug till it’s tested further and others have reported similar problems.
There’s been so many changes to Hass recently it could be anything that causing these errors.
I’d need to strip the configuration.yaml right back to a bare minimum, add each component one at a time until I could identify the offending component.
Update: I have rolled back to 0.94.4 but it’s not a ha version issue.
The problem is still present, so it must be something that has changed in integrated devices.
Question: do you have alexa media player custom component installed?
My install is the Virtual Environment not Docker and not Hassio.
This quote from version 95.0 release notes
“For the last couple of releases, we’ve been printing warnings if your configuration contained invalid slugs or extra keys. Starting with this release, these warnings are now errors. No procrastination anymore, you’ll need to fix it now.”
I’m now assuming that any user using features that are no longer supported are experiencing a serious amount of logging errors which will eventually crash your system.
Might be worth checking your configuration.yaml to see if you are in fact using unsupported features and remove them before your system crashes.
I am getting these after upgrading to 0.96.3. I don’t understand how I could isolate what might be wrong in my configuration file. Any tips on how to correlate the errors to the configuration? The logs have three occurrences of this error all at 7:12:05.
The activity log shows two things happening at this time.
But I have other occurrences of both of these in the activity log that don’t correlate to any errors in the log. So I suspect the activity didn’t get logged which makes some sense since it failed.
Not sure what else I could look at to figure out what was firing at 7:12AM
Thanks. I have traced it to my room_assistant setup. The strange part is everything is working fine. I use it to detect my car arriving home. Then I open the garage, unlock a door, turn on some lights and send an email notification of my arrival.
This uses mqtt to report car as “away” or “garage”. And all automations are working fine. When I watch the mqtt logs it writes that the car is in garage and the distance it calculates just fine and sends message every second until the car is turned off. If I test over and over the error only occurs randomly. Not every time. I also think that since the mqtt distance changes and the message keep getting sent that a few failures are not an issue.
The only thing I can think of is perhaps the messages are coming too fast and the error is happening when two events fire at same time or close together. I plan to edit the code in room assistant to delay messages to 1 every few seconds at most or less. See if that helps.
