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
Something seems off. Iâve been running HASS container for years and donât have privileged: true set. That ADRâs only mention of privileged âstuffâ is:
The only supported way to run the container is on the host network as root with full privileges.
âŚwhich I interpret as network_mode: host.
That requirement was accepted when the ADR for the container installation was laid out, there is no need to attack me for that!
Anything that deviates from the ADR is not supported.
@ludeeus But why do you feel like itâs an attack? I didnât attack you at all, Iâm asking a question and challenging the reason for requiring such a thing when itâs clear that it works without it.
2 Likes
I wonderâŚ
yeah⌠Iâm unsubscribing completely from this thread, have fun 