2021.4: For our advanced users ❤️

I have the same issue. Any thoughts?

EDIT: I use packages (i.e. in the configuration.yaml I have the following. As in the release notes is stated that ‘everything included’ is able to use secrets, I doubt whether this might have anything to do with it.
packages: !include_dir_named integrations/

EDIT2: This issue might be useful https://github.com/home-assistant/core/issues/48735. I use lovelace_gen but updated it already to the latest version (master). Reinstalling lovelace_gen to the ‘master’ version and a hard reboot fixed the issue.

1 Like

I tried a modified version 1 because the fan is expecting 0 - 3 and a version 2 because the template didn’t return the expected results in the template editor.

modified version 1:

{{ (value | int / (100 / 3)) | int }}
{{ (value_json.FanSpeed | int ) * 100/3 }}

modified version 2:

percentage_command_template: "{{ (value | int / (100 / 3)) | round }}"
percentage_value_template: "{{ ((value_json.FanSpeed | int ) * 100/3 ) | round }}"

neither template actually turned on the fan (with no errors in the log). Nothing at all happened. and if I turn the fan on with the toggle the fan should start in “low” (speed 1) but the speed slider jumped to 0 instead of the expected 33.

And it still didn’t solve the lack of hard stops at 33 & 67. it was still a continuous 1 step value from 0 to 100.

I am going to reply to my own post here in case someone else has the same issue I did. The logging in process is a little confusing. On the Hayward Omnilogic app and website you are presented with filling in a User Name: and Password:. However, after you login on the Hayward Omnilogic website you will see some links on the top right; select profile and you will see your Login Name:. The Login Name is the username you use for the integration in Home Assistant (see my previous post and above screenshots). Thanks again for correcting the previous issue with the Hayward Omnilogic integration.

Yeah, it’s not adding the id to the automation that does you in.

it’s storing the automations in the automations.yaml file that does it. Along with the id? I’m not sure. But I’m sure @123 knows since he got run over by that bus a while back when he dabbled in the UI with his automations.

you are right! for some reason I did not consider python would be different than… every other programming language, looks like the dev of that file did as well

perhaps nobody noticed because notify.notify is the generally used service call

edit
it looks like that code is new to this release and is indeed a bug

I’d just like to thank all the contributors for yet another fantastic release. :grinning:

I understand your frustration and share it but try to count to 10 before I post. That help with the mood in the words.

Some of the issues with the scrolling was fixed quickly in .1 or .2 release.

With this release though the problems are back in new shapes. I cannot edit any lovelace cards at all any longer on my beloved iPad. I do 80 of the little tweaks and updates on my iPad so I hope the github issue I have raised gets addressed soon in next patch release.

The scrolling issue is huge, I believe they already found the reason (frontend) but did not track if if made it into this release

For Alexa Media Player, there is a commonly used template sensor to determine which Alexa device was last called.

        value_template: >
          {{ expand(states.group.echos) | selectattr('attributes.last_called','eq',True) | map(attribute='entity_id') | first }}

After upgrading…
At startup, I now get oh something like 4 warnings within a few seconds stating:

2021-04-08 15:48:25 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: No first item, sequence was empty. when rendering '{{ expand(states.group.echos) | selectattr('attributes.last_called','eq',True) | map(attribute='entity_id') | first }}'

The template goes on to work.
Just wondering if there are any suggestions to overcome the warnings?

EDIT: After running for a while this same warning shows up…thus far a couple of times in the last half-hour.

I have 2 homes, 1 HA for each home.
One HA has been upgraded to 2021.4.0 but the second keeps saying that the newest version is 2021.3.4.
Does someone know why ?
and how could I force it to upgrade to 2021.4.0 ?
Thanks.

Kudos to all the developers!! This is perhaps a small step for mankind, but a huge step for HA-fans :slight_smile:
This version is way more snappy than the previous. Response time is fantastic now. I was becoming increasingly worried about this is I notice more and more lag during the previous 3-4 upgrades. But now! WOW!!
Somehow I always wondered why a new update often takes a loooong time to start first time? Thereafter, it’s quite fast. I also often had to restart HA a few times before it actually picked up everything and stopped throwing errors during startup. This version however, had none of these problems, but it used more time on first startup than ever before. It’s not very important as it only happens on the first start, but I was wondering what it is doing?
(I run HA Docker on a NAS)

Housework it seems

Impressive new challenges, wow!

One question in regards to the Xiaomi integration. My Air purifier was was so far never showing “Unknown” as aqi-state. However, I am getting this now frequently since yesterdays update.

    sensors:
      xiaomi_airpurifier_air_quality_pm25:
        friendly_name: "Xiaomi Air Purifier 3H Air quality"
        value_template: "{{ state_attr('fan.xiaomi_air_purifier_3h', 'aqi') }}"
        unit_of_measurement: "μg/m³"

Same - I’m on 6hrs at the moment, and the family is complaining (everything works “normally”, just no automations…)

any idea how long would it take for a database of 4.5GB (MariaDB) on an RPi4 with SSD?

In the past when my system has run really slow like you mention it has been due to a corrupt database. See if you have an error to this effect in your log

2021.4.1 released with some fixes including for Speedtest. I am sticking with my bash script using the cli for this now but some people might appreciate the fix.

For all of those storing more than 1GB of history, you should look in to moving that off to something else for long term storage such as Influxdb or some other solution. You can then use that for analytics of your own instead of lugging around a ball and chain on your installation, your SD cards, and your peace of mind.

And if you don’t need to know if a light was on 4 months ago, you don’t need that +4GB database at all! I’m seeing a lot of “oh I deleted it and now it’s not a problem”. Well if it wasn’t important, you can do yourself a favor by not allowing the db to get to that size in the first place. You can let HA be a sports car and not a dump truck. Snapshots are made faster, restore faster, and take up less space. Benefits all around.

12 Likes

possibly a good time to reread https://www.home-assistant.io/integrations/recorder for some of us…

4 Likes

Thanks i have confirmed that when I have a !secret name_of_code in my zwave_js.set_lock_usercode lock code when I try and access via the GUI it give me Error loading automation (500). If i remove that and place a ‘###’ in that field it works. Interestingly enough it give me an error on all automations on the page if I have the sceret in there. Did something change on a previous syntax and I just missed it.

Update: I found this in my log… not sure File “/usr/src/homeassistant/homeassistant/util/yaml/loader.py”, line 305, in secret_yaml
raise HomeAssistantError(“Secrets not supported in this YAML file”)
homeassistant.exceptions.HomeAssistantError: Secrets not supported in this YAML file