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):
core-2022.4.7\homeassistant\components\sql from the zip file and copy it into your custom_components folder.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.manifest.json inside the integration’s folder:
"version": "2022.4.7"
"requirements": [],
.storage folder if you are brave…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 ?
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?
Have this issue after update to 2022.5.1, over 3000 error lines in log just because of sensors refresh taking too long. However simple restart of HA resolved issue. It seems stable now for couple of hours.
Hi,
After the upgrade i’m not able to read my “on tv time” anymore “nice” in HA.
My code that I was using is: {{ states(‘sensor.tv_kijken.attributes.values’) }} gekeken
before the upgrade it was showing “1h30m gekeken”
now it’s saying unknown gekeken.
If i’m only taking {{ states(‘sensor.tv_kijken’) }} it’s given me 1.40 for example.
Thanks
Tim
Well, wait ! Meanwhile, I discovered that the HomePod remote was turned off on my dev system, which produces the same error…
So the status seems local to the integration because the HomePod is still “idle” on my prod system addressing the exact same HomePod and working perfectly (still on 4.7 though)
After turning the HomePod (remote) “on” on my dev system on 2022.5.1, it now works !
So, I stand corrected, 5.1 seems to have fixed it.
Even better, this fix seems to have solved the other problem of not showing any sources for the HomePod.
I now have access to all media for the first time, same for the ATV.
Mine is working (Supervised install).
Just to add my experience, positive one.
My cpu usage dropped on average from 5-6% to 1-2% running HA in a VM on proxmox.
So you guys did something right 
might be the DB stuff, but kudos for that!
Thank you very much for the had work and dedication. !!!
I missed this in the release notes, thanks for bringing it up. I, too, use unit_of_measurement in a few sensors and would like to know what the options are if that’s no longer allowed.
The backup integration has kind of a niche use case, from the doc:
The Backup integration allow you to create and download backups for your Home Assistant Core and Home Assistant Container installations. This backup file can be used if you migrate to Home Assistant Operating System.
Users with an HAOS or Supervised installation don’t use it. And even for container/core users it’s really a migration tool not a backup one since only supervisor can restore from those backup files.
If you want to change this you’re looking in the wrong place. You’ll need to modify supervisor to add this new option to it’s API. And then frontend to expose the new option in the backup UI.
Uhh, yeah… Search definitely got broken in 2022.5. My use case, simply search for the word “Group” in the Entities list… I get all sorts of results that don’t have the word “group” in them, and are not related to groups in any way.
Quite a few creators have commented that the extensive changes have invalidated many of their tutorials. Perhaps there’s a case for keeping the old menu structure and have the new format as a user-selectable option.
Though I feel the new format is welcome, the impact of the changes seems to have been ignored.
Peter
I think I solved my own problem:
- id: "d1d8af3f-edc5-450f-b4fc-c006cbe31fed"
alias: "Notification - Goto work"
trigger:
- platform: calendar
event: start
entity_id: calendar.werk
condition: "{{ (states('sensor.time') == (as_timestamp(state_attr('calendar.werk', 'start_time')) - 3600 )|timestamp_custom('%H:%M')) }}"
action:
- service: script.mobile_notify_no_actionable
data:
title: "Goto work"
message: "Within a hour you have to work"
thread_id: "system_notification"