2022.5: Streamlining settings

Perhaps. I considered that too but I don’t think that’s material to my question. Why make this change? It can’t be in response to the deficiency of YAML approach that is identified in that document (i.e. multi-step setup) because the SQL sensor couldn’t be a more simple integration in YAML…

I understand (as a software engineer myself) that there will be situations where UI-only makes more sense. I can also understand why it might be prohibitively more complex to support both even if YAML worked. But this seems both strictly worse ergonomically (that query is structural text already and having a good UI flow would require code highlighting, indenting, etc., at minimum) and straight-forward collection of a set number of values.

But if I am missing something, then I am sorry and fair enough. This is free software made by volunteers and I know what it feels like to be on the other side of a decision like this. It just takes me by surprise because it seems like making the integration less usable where other examples of this shift has made them more ueable.

Hi

after upgrading to 2022.5.1 release from 2022.4.7 releasing I can not longer restart the system due to configuration error. The error I am getting is

“Invalid config for [sensor.integration]: The ‘unit’ option has been removed, please remove it from your configuration. Got OrderedDict([(‘platform’, ‘integration’), …”

I tried reverting to the backup of 2022.4.7 and everything works ok. Is this a bug or should I change something in my configuration files in order to upgrade to the latest version??

Drop deprecated support for unit_of_measurement from sensor (@emontnemery - #69061) (sensor docs) (breaking-change)

I see and thanks for the info pedolsky. Not sure exactly what I need to change though. Did they simply remove the unit of measurement from sensor and replace it with native_unit_of_measurement or do I need to change the way that I have created the sensors?

Great release. Thanks to all involved.

In the noteworthy changes I see that state conditions in scripts now have the option “match: any” (as opposed to every condition matching. I would LOVE to see this option in the conditional card!

2 Likes

I’ve just updated from 2022.4.x and the update went fine.
But WTF did the devs think when they moved the SQL sensor away from YAML??
I have some quite complex SQL queries, the most complex one spreads over 26(!) lines to make it readable. How should I handle such big queries in one single line in the UI? Totally crazy!

Does anyone know where the code of the SQL sensor integration is located, so that I can use the 2022.4.x version as a custom integration?

3 Likes

As far as I understand it, yes, unless I misinterpret the discussion.


Frenck commented on 19 Aug 2021 
We split the entity description in our core entity model, to solve an issue with sensors, I think we should either solve it at the sensor for that reason instead or consider changing the core base entity model (the latter would be quite an impact maybe?).

For example, by re-typing unit_of_measurement in SensorEntityDescription to be None.

@dataclass
class SensorEntityDescription(EntityDescription):
    """A class that describes sensor entities."""

    state_class: str | None = None
    last_reset: datetime | None = None  # Deprecated, to be removed in 2021.11
    native_unit_of_measurement: str | None = None
    unit_of_measurement: None = None. # Type override, use native_unit_of_measurement instead


ludeeus commented on 19 Aug 2021
That is the point, they should not set unit_of_measurement, but native_unit_of_measurement instead.

ok thanks a lot. I will give it another try!!

Where can I find the Supervisor page to import from USB?
Thank you

Hi All,

Can you use this:

- platform: calendar
  event: start
  entity_id: calendar.personal

with a offset?

I use this:

- platform: template
  value_template: >-
    {% if state_attr('calendar.werk', 'start_time') == none %}
      {{ false }}
    {% else %}
      {{ (states('sensor.time') == (as_timestamp(state_attr('calendar.werk', 'start_time')) - 3600 )|timestamp_custom('%H:%M')) }}
    {% endif %}

Want add the offset - 3600 seconds.

So when a event start 60minutes in advanced the trigger will hit.

Has something with the logger changed?
I set default to fatal but in the new UI under logs → supervisor I see a bunch of INFO messages like

22-05-06 09:57:10 INFO (MainThread) [supervisor.api.proxy] Home Assistant WebSocket API request running
22-05-06 09:57:20 INFO (MainThread) [supervisor.homeassistant.secrets] Request secret mariadb_homeassistant_user

Maybe I did not notice before because of the old UI.

P.S.: It is more clicks and takes some getting used to, but kind of like the new UI.

Error still persist under 2022.5.1

Here is the error Log:

Logger: homeassistant.components.websocket_api.http.connection
Source: util/yaml/dumper.py:40
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 10:14:08 AM (1 occurrences)
Last logged: 10:14:08 AM

[547704869648] Error handling message: Unknown error (unknown_error)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 27, in _handle_async_response
    await func(hass, connection, msg)
  File "/usr/src/homeassistant/homeassistant/components/blueprint/websocket_api.py", line 125, in ws_save_blueprint
    await domain_blueprints[domain].async_add_blueprint(blueprint, path)
  File "/usr/src/homeassistant/homeassistant/components/blueprint/models.py", line 327, in async_add_blueprint
    await self.hass.async_add_executor_job(
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/blueprint/models.py", line 318, in _create_file
    path.write_text(blueprint.yaml(), encoding="utf-8")
  File "/usr/src/homeassistant/homeassistant/components/blueprint/models.py", line 107, in yaml
    return yaml.dump(self.data)
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 13, in dump
    return yaml.safe_dump(
  File "/usr/local/lib/python3.9/site-packages/yaml/__init__.py", line 269, in safe_dump
    return dump_all([data], stream, Dumper=SafeDumper, **kwds)
  File "/usr/local/lib/python3.9/site-packages/yaml/__init__.py", line 241, in dump_all
    dumper.represent(data)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 27, in represent
    node = self.represent_data(data)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 48, in represent_data
    node = self.yaml_representers[data_types[0]](self, data)
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 56, in <lambda>
    lambda dumper, value: represent_odict(dumper, "tag:yaml.org,2002:map", value),
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 40, in represent_odict
    node_value = dumper.represent_data(item_value)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 48, in represent_data
    node = self.yaml_representers[data_types[0]](self, data)
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 56, in <lambda>
    lambda dumper, value: represent_odict(dumper, "tag:yaml.org,2002:map", value),
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 40, in represent_odict
    node_value = dumper.represent_data(item_value)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 48, in represent_data
    node = self.yaml_representers[data_types[0]](self, data)
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 56, in <lambda>
    lambda dumper, value: represent_odict(dumper, "tag:yaml.org,2002:map", value),
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 40, in represent_odict
    node_value = dumper.represent_data(item_value)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 48, in represent_data
    node = self.yaml_representers[data_types[0]](self, data)
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 56, in <lambda>
    lambda dumper, value: represent_odict(dumper, "tag:yaml.org,2002:map", value),
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 40, in represent_odict
    node_value = dumper.represent_data(item_value)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 48, in represent_data
    node = self.yaml_representers[data_types[0]](self, data)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 207, in represent_dict
    return self.represent_mapping('tag:yaml.org,2002:map', data)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 118, in represent_mapping
    node_value = self.represent_data(item_value)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 48, in represent_data
    node = self.yaml_representers[data_types[0]](self, data)
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 56, in <lambda>
    lambda dumper, value: represent_odict(dumper, "tag:yaml.org,2002:map", value),
  File "/usr/src/homeassistant/homeassistant/util/yaml/dumper.py", line 40, in represent_odict
    node_value = dumper.represent_data(item_value)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 58, in represent_data
    node = self.yaml_representers[None](self, data)
  File "/usr/local/lib/python3.9/site-packages/yaml/representer.py", line 231, in represent_undefined
    raise RepresenterError("cannot represent an object", data)
yaml.representer.RepresenterError: ('cannot represent an object', <NumberSelectorMode.SLIDER: 'slider'>)

Thanks I was able to fix the problem and I can now reboot the home assistant server. Not sure If the change brake anything else and I need to set something more with the native_unit_of_messaurement in order to work as expected. I will keep checking.

P.S. I like the new look

Found the old integration from 2022.4.7 and made it work.
This is what I did (quick and dirty, maybe there’s a better way):

  • Download the old version from here: Release 2022.4.7 · home-assistant/core · GitHub
  • Extract the folder core-2022.4.7\homeassistant\components\sql from the zip file and copy it into your custom_components folder.
  • Rename the folder (e.g. to sql_custom) and change the sensor definitions in your YAML files accordingly ("- platform: sql_custom"). Without renaming, it did not work for me for whatever reason.
  • Edit the file manifest.json inside the integration’s folder:
    • rename the domain from “sql” to “sql_custom”:
    • add a “version” line, e.g. "version": "2022.4.7"
    • empty the “requirements” array, otherwise I had an unresolvable depencency problem: "requirements": [],
  • Delete all automatically migrated SQL sensors by using the UI - or by editing the JSON files in the .storage folder if you are brave…
  • Restart HA
2 Likes

So if i understand it correctly, “unit_of_measurement” has been removed? I use some template sensors for energy measurements, but to get it into energy i have to specify them in “customize.yaml”

Like this:

sensor.test_kwh:
    unit_of_measurement: kWh
    friendly_name: test_kwh
    device_class: energy
    state_class: measurement
    last_reset: 1970-01-01T00:00:00+00:00

If i understand this correctly i how to change this to “native_unit_of_measurement”? Or can i just remove it completely?

hi Tom, where can we see the db size on MariaDB? is that a sensor in HA ?

edit

Nvm me, found it at last… SQL - Home Assistant

sensor:

  - platform: sql
    db_url: !secret db_url
    queries:
      - name: MariaDB size
        query: "SELECT table_schema AS 'db_name', ROUND(SUM( data_length + index_length )
                / 1024 / 1024, 2) AS 'size_mb' FROM information_schema.TABLES WHERE
                table_schema='homeassistant'"
        column: 'size_mb'
        unit_of_measurement: MB

and yes its not that huge:

ofc, I have no clue what it was before… still, good to know now, and be able to track.

5-6 seconds load time here… and I do think that the States-page is the problem, navigating directly to some other page is OK.
And, during the load of the states-page you can’t navigate to YAML or any other page.

I have the same problem and I don’t get what we have to do.
I tried to replace unit_of_measurement by native_unit_of_measurement but that doesn’t pass the test…
I absolutely need to define the unit because my Owl energy sensor is giving the total consumption in Wh and not in kWh.
And I have plenty of template sensors and customized sensors where the unit has to be defined.
Besides, unit_of_measurement is still referenced in the doc as the mean to do this.

So before I attempt to upgrade to 2022.5, can someone explain clearly what we have to do to define the unit of measurement now ?

2 Likes

Now I get what you mean…
I’m still on 2022.4.7 where it works like I said.
I loaded 2022.5 on my dev setup and, indeed, the new update broke TTS to HomePods…
Apparently, it is a known issue that should have been fixed in 5.1
But unfortunately it is not. I just updated my dev system this morning and TTS on HomePods is still broken, giving the error you mention.
So I’m stuck on 2022.4.7 on my prod system for now.

Yes, its a nasty bug, HomePods are not functional in 2202.5…

what’s more, no one has responded to my issue ATV throws errors on startup/disconnect when devices are off · Issue #69387 · home-assistant/core · GitHub. Not the author of the Pyatv library, nor the various dev’s in the other mentioned fixes for this, and where I left a mention of this.

Maybe add to the issue?