Yeah, workarounds are required now, but this will soon be fixed surely.
You know you can also do it via Local storage in inspector ?
My integration was getting this error:
ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:997)
I was able to solve it by adjusting the SSL context:
context = ssl.create_default_context()
context.set_ciphers("DEFAULT")
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE
self.ssl = context
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.
1 Like
HA OS (version 8.2).
1 Like
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.
2 Likes
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.
2 Likes
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.
I think you have to map the dbus into your container.
2 Likes
Ha, thanks @firstof9 , I was just about to post my solution found here 
Found the solution here
I had to make changes to my docker to give it permissions to dbus so bluetooth could work with bleak.
1 Like
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
I have same Problem
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.
6 Likes
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.
Did you happen to see my other post with a fix for this issue?
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.
2 Likes
This looks exciting Add bluetooth integration by bdraco · Pull Request #74653 · home-assistant/core · GitHub
1 Like
Fought with this one this morning. Ended up downloading latest Putty, gen’d new keys, and after doing this about five times and making sure old authorized keys under Configuration\Options were gone, I finally got in.
1 Like
Definitely an option for sure. In my case, I could use an entities: line and list them all below it instead of the filter:. I do that for a my CPU Stats card. I wouldn’t consider it a better solution than what we had before, though. 
type: history-graph
entities:
- entity: sensor.cpu_temp
- entity: sensor.processor_use
refresh_interval: 0
hours_to_show: 24
title: CPU Stats
For me the history has become useless too. I have very extensive history.yaml and recorder.yaml files to configure the history and use it as a system overview, which now doesn’t work anymore. I would like to have an “all” filter too to get back the old behaviour.
2 Likes