I’m now seeing: “Retrying setup: ‘list’ object has no attribute ‘items’”
Seeing this error every hour.
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:87
First occurred: 20:00:00 (1 occurrences)
Last logged: 20:00:00
Error doing job: protocol.resume_writing() failed
Traceback (most recent call last):
File "/usr/local/lib/python3.9/asyncio/transports.py", line 294, in _maybe_resume_protocol
self._protocol.resume_writing()
File "/usr/local/lib/python3.9/asyncio/sslproto.py", line 516, in resume_writing
self._app_protocol.resume_writing()
File "/usr/local/lib/python3.9/site-packages/aiohttp/base_protocol.py", line 31, in resume_writing
assert self._paused
AssertionError
Possibly due to trying to play a chime on my Chromecast Audio (the chime is working).
1 Like
Yep, also seeing this. It works initially after a restart and then all entities show as unavailable. If i reload the integration then entities come back but only for a short period and go back to unavailable approx 5 minutes later or whenever the entity state is updated
The same problem, if you physically remove the camera module from the board, the connection remains stable and the other functions of the esp32cam module work stably. I tried to upgrade the cameras from 1.19-dev to 1.20-dev - no changes, apparently a problem when receiving an image from the camera.
This solved the issue at my end. Thanks for this very useful input!
1 Like
Hmm This Python change is crapping out many of the integrations.
HACS not working anymore (API Token failure), InfluxDB craps out.
Restoring my old version because this version has way too many issues
Both working here.
Got following during check configuration:
[s6-init] making user provided files available at /var/run/s6/etc…exited 0.
[s6-init] ensuring user provided files have correct perms…exited 0.
[fix-attrs.d] applying ownership & permissions fixes…
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts…
[cont-init.d] udev.sh: executing…
[cont-init.d] udev.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[16:01:05] INFO: Don’t worry, this temporary installation is not overwriting your current one.
[16:01:05] INFO: Installing Home Assistant: latest…
[16:01:05] INFO: Please be patient, this might take a few minutes…
[16:02:44] INFO: Installed Home Assistant 2021.7.0
[16:02:44] INFO: Making a copy of your configuration for checking…
[16:02:52] INFO: Checking your configuration against this version…
[16:10:42] ERROR: The configuration check did not pass!
[16:10:42] ERROR: See the output below for more details.
Testing configuration at /tmp/config
Failed config
General Errors:
- Component error: yandex_smart_home - No module named ‘av’
- Component error: camera - No module named ‘av’
RUNNING:
core-2021.6.6
supervisor-2021.06.8
Raspbian GNU/Linux 10 (buster)
Docker 20.10.6
Any solution how to fix av module?
Wait for 2021.7.1
2 Likes
will do
Do you already have the new GitHub API Token for HACS?
DSMR Query and Load errors in InfluxDB.
Main reason for my ProxMox LXC restore is simply that my Thermostat is not working anymore.
Would it be possible to refer to more than one trigger ID in the action part?
I have a couple of automations with a range of triggers and only two actions.
Something like the following:
action:
- choose:
- conditions:
- condition: trigger
id:
- Time Out
- Alarm On
sequence:
- service: light.turn_off
target:
entity_id: light.hallway
- conditions:
- condition: trigger
id:
- Alarm Off
- Motion detected
- Door opens
sequence:
- service: light.turn_on
target:
entity_id: light.hallway
default: []
should be fixed in 2021.7.1.(last entry in list)
2021.7.1 by frenck · Pull Request #52745 · home-assistant/core (github.com)
@ludeeus horrible advice. It’s Linux 101 that you don’t run anything with root privileges unless it’s temporary and for a specific defined purpose. Running home automation with a gazillion links to things in the network and giving it root access is irresponsible.
4 Likes
The example open/close window notification based on inside vs outside temp (using the new comparison with ‘other’ entity automation trigger) is a great use case - thanks for the new feature! I also upgraded my MQTT sensor to the new MQTT “select” entity, which works great except for one minor nit-pick - the badge for the old sensor used to display “off” as “Off”, whereas the new select entity badge displays “off” as “off”. It’s an inconsistency that sticks out like a sore thumb in a row of badges. I know you can argue that a select entity should not display an “off” value as if it was a boolean state on a badge - but sensors aren’t booleans either, so the inconsistent treatment doesn’t look as good as it used to 
Awesome release as usual (especially since I am running core venv directly on Windows 7 + Python 3.8 with no docker - I am always surprised how smooth the upgrades are going even though it is not a supported environment).
It is not advice, it’s required
1 Like
@wburgers Thanks for providing a workaround. I think it’s complete madness to only support the container as privileged, I’ve been running HA for over a year in non-privileged mode and mounting things as needed without issues. It’s the first time I see anyone in the Linux community telling others to run with full root privileges without explaining exactly why that’s necessary when there are examples in the wild (like myself and you) running non-privileged that works. I followed the instructions on the “Fix/Workaround” and my 2021.7.0 image is now running without issues. Sometimes I think the decisions the developers of this project make are a little crazy.
2 Likes
Doesn’t explain why it’s required… and why have at least two of us been running non-privileged (myself for over a year) without issues? I can even mount my zwave and my zigbee dongles as volumes and it works as normal. Never seem a Linux developer tell someone to run their code with full root privileges without detailing why that’s needed, that is until you just did that. Doesn’t make it okay. Open Source is about transparency, so if the container has been on non-privileged mode and working for several versions why exactly do you guys want us to give you root privileges 100% of the time? 
2 Likes