Same for me. After selecting one area , the page never respond. HA restarted , it’s the same.
The solution that I found is to remove one file contain home assistant information from \AppData\Local\Google\Chrome\User Data\Default\Local Storage\leveldb
Tried the upgrade again today - after first fixing and then upgrading SonoffLAN to 3.1.0 - and the cards all seem to work fine now, maybe it was related after all.
But it looks like the slider-button-card has been abandoned - anybody got a good replacement suggestion yet?
Did I understand correctly that this breaks the Bluetooth Device Tracker ? I’m sure many were relying on this to provide a means for reliable precence detection.
Note, the ssl.CERT_NONE is because the device (LENNOX S30) has a self signed cert. I was already setting that before. The key is the setting of the ciphers.
ROOT CAUSE: Python 3.10 has different default for the SSL context that may cause compatibility issues with older devices.
I am using the switchbot integration. It is my understanding it has been updated to use bleak, but I am having issues, which I believe are bluetooth realted. I am running on a NUC, and the depreciated bluetooth was working previously for me. I am running a docker/container for HA as well
The error I am getting is
Unexpected exception
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/switchbot/config_flow.py", line 89, in async_step_user
self._discovered_devices = await self._get_switchbots()
File "/usr/src/homeassistant/homeassistant/components/switchbot/config_flow.py", line 55, in _get_switchbots
_btle_adv_data = await _btle_connect()
File "/usr/src/homeassistant/homeassistant/components/switchbot/config_flow.py", line 34, in _btle_connect
switchbot_devices = await GetSwitchbotDevices().discover()
File "/usr/local/lib/python3.10/site-packages/switchbot/__init__.py", line 162, in discover
await devices.start()
File "/usr/local/lib/python3.10/site-packages/bleak/backends/bluezdbus/scanner.py", line 88, in start
self._bus = await MessageBus(bus_type=BusType.SYSTEM).connect()
File "/usr/local/lib/python3.10/site-packages/dbus_next/aio/message_bus.py", line 122, in __init__
super().__init__(bus_address, bus_type, ProxyObject)
File "/usr/local/lib/python3.10/site-packages/dbus_next/message_bus.py", line 85, in __init__
self._setup_socket()
File "/usr/local/lib/python3.10/site-packages/dbus_next/message_bus.py", line 575, in _setup_socket
raise err
File "/usr/local/lib/python3.10/site-packages/dbus_next/message_bus.py", line 548, in _setup_socket
self._sock.connect(filename)
FileNotFoundError: [Errno 2] No such file or directory
Other people reported success with the switchbot intergration, so I am not sure if this is an HA thing, a NUC thing, or what I did poke around and not sure what “file” is missing, they seem to be there at least they are there in the docker, not on the host though?
So this may be a silly thing to bring up, but I’m going to anyway as a rookie assuming other rookies will experience similar problems.
I attempted to replicate this filtering example from the latest update for some time before realising the grey vertial lines are | pipes | and not indentation guides.
This confusion is almost certainly a result of my minimal experience, and I did eventually figure it out, but I doubt I’m the least knowledgable person to tinker with Home Assistant, so I’m putting it out there.
Perhaps a different theme where character elements are not grey could help in the future.
That’s fair. I tried to be clear I was suggesting a temporary workaround not a long-term solution, I don’t think users should have to rebuild what they had with a custom card either.
That being said I could get behind this being a bug rather then an FR. Particularly if you added include and exclude filters to history. In that case create an issue here.
Bear in mind here that changes (particularly to the frontend) rarely (if ever) make everyone happy. The general feedback in the forum, discord and really all channels I had seen is that the history panel was not useful for people. It was slow and unwieldy and required a massive amount of effort to make it not that so more people ignored it then used it. I know I was one of those people. I tolerated it since it was the only easy way to view a particular entities history in a dynamic date range until I found history explorer then I tossed it immediately.
This isn’t to dismiss your feedback at all. Like I said above, if you did spend the effort to configure includes and excludes those should be acknowledged and be the default filters IMO. Just that the goal was to make history useful OOTB for the most people with minimal configuration and I personally think this change accomplishes that well.
If your history page is not working, here the procedure to remove the selection which is stored on your local storage of your browser.
On smartphone, I don’t find the solution yet.
Step by Step Instructions
Open the Google Chrome Console by pressing F12 key.
Select “Application” in the console’s top menu.
Select “Local Storage” in the console’s left menu.
Right click your site(s) and click clear to delete the local storage or better remove the entry: historyPickedValue.
Hm…what happened to Yamaha integration? It vanished after the update. I have it configured through the main config file but it doesn’t work…Oh, I see some error in the logs:
Logger: homeassistant.components.media_player
Source: components/yamaha/media_player.py:127
Integration: Media Player (documentation, issues)
First occurred: 6 July 2022 at 22:54:09 (1 occurrences)
Last logged: 6 July 2022 at 22:54:09
Error while setting up yamaha platform for media_player
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 250, in _async_setup_platform
await asyncio.shield(task)
File "/usr/src/homeassistant/homeassistant/components/yamaha/media_player.py", line 150, in async_setup_platform
receivers = await hass.async_add_executor_job(_discovery, config_info)
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/yamaha/media_player.py", line 127, in _discovery
for recv in rxv.find():
File "/usr/local/lib/python3.10/site-packages/rxv/__init__.py", line 19, in find
return [RXV(**ri._asdict()) for ri in ssdp.discover(timeout=timeout)]
File "/usr/local/lib/python3.10/site-packages/rxv/ssdp.py", line 68, in discover
m = re.search(r"LOCATION:(.+)", res.decode('utf-8'), re.IGNORECASE)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte
While I completely applaud the efforts by the dev team to make the OOTB experience easier for new users, I ask that perhaps more thought and consideration be given to those of us who have been around a while and crawled through the trenches when that was the only way.
Although I would probably have loved being able to buy a Yellow and plug it in and control some lights all from the UI, there is ABSOLUTELY NO WAY that my home would be as automated or secure as it is today without that forced learning experience or knowledge of HA’s inner workings.
I find the way recorder, history, and their filters work incredibly logical, easy to use, and very effective. It was one of the first things I nailed down because of its importance.
IMHO, in perhaps a rush to quell complaints, a valuable resource used silently by many of us daily was lost. I only hope it is returned, as being suggested.
I am getting some weird errors related to ZHA, where it blocks the loading of the Automation component.
Thing is, I uninstalled ZHA some time back, and migrated to Z2M.
It works reverting to 2022.6.X
Logger: homeassistant.setup
Source: components/zha/core/helpers.py:173
First occurred: 20:47:27 (1 occurrences)
Last logged: 20:47:27
Error during setup of component automation
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 235, in _async_setup_component
result = await task
File "/usr/src/homeassistant/homeassistant/components/automation/__init__.py", line 241, in async_setup
if not await _async_process_config(hass, config, component):
File "/usr/src/homeassistant/homeassistant/components/automation/__init__.py", line 648, in _async_process_config
await async_validate_config_item(hass, raw_config),
File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 74, in async_validate_config_item
config[CONF_TRIGGER] = await async_validate_trigger_config(
File "/usr/src/homeassistant/homeassistant/helpers/trigger.py", line 59, in async_validate_trigger_config
conf = await platform.async_validate_trigger_config(hass, conf)
File "/usr/src/homeassistant/homeassistant/components/device_automation/trigger.py", line 69, in async_validate_trigger_config
return await platform.async_validate_trigger_config(hass, config)
File "/usr/src/homeassistant/homeassistant/components/zha/device_trigger.py", line 41, in async_validate_trigger_config
zha_device = async_get_zha_device(hass, config[CONF_DEVICE_ID])
File "/usr/src/homeassistant/homeassistant/components/zha/core/helpers.py", line 173, in async_get_zha_device
raise ValueError(f"Device id `{device_id}` not found in registry.")
ValueError: Device id `ba8102de620e48a39a4188e5531b57fa` not found in registry.
Another option is instead of an additional ALL button, logic is included so that IFF there are filters set on recorder and/or history, that those filters are taken as the DEFAULT entities and are shown without further action (since the user has already indicated what History they wanted to see). That would be the ultimate return to the way it was for those users, but perhaps a little more work for the Devs.