Same here. There is an error in de log for each attempt to load a dashbord:
https://…my nabucasa FQDN here…nabu.casa/frontend_latest/08219b6a.js:362:5549 Uncaught TypeError:Cannot read properties of undefined (reading ‘1’)
GUI->Settings->System->Hardware … I have this working. Nice!
Perhaps off topic, I just happen to notice that GUI->Settings->System->Storage is missing from a venv HA Core version I’m running. I’m not using default_config but I can’t seem to figure out that that’s the cause or if it is something else. Any ideas?
Hi,
I am replying to my earlier post, to update my understanding of the bluetooth_tracker and whether it is likely to be fixed soon as many people hope.
Short answer - don’t hold your breath!
I wish I had researched this earlier because I wouldn’t have been patiently stuck on 2022.6.7 and waiting with blind faith that this would be fixed.
We were informed, in the 2022.7.x release notes’ breaking changes that bluetooth_tracker would break, and the suggested solution was to use Bleak as the bluetooth stack.
This was also reiterated by Frenck in the open issue raised on Github.
https://github.com/home-assistant/core/issues/75049
And in particular this:
https://github.com/home-assistant/core/issues/75049#issuecomment-1200479796
Where Bleak is stated as being the solution.
However as Kevdliu pointed out in the same open issue, Bleak does not support Classic Bluetooth.
In fact, if you look at the Bleak webpage
bleak — bleak 0.17.0a1 documentation
it says that BLEAK is an acronym for Bluetooth Low Energy Active Klients.
So this means that Bleak is not a solution even though we are told that it is!!
Therefore all those who have added their voices to requesting a quick fix should maybe lower their expectations. As I have done.
I wish I had looked into this earlier and not wasted 2 months.
Hopefully we can we get a realistic timeframe on a new working integration or an update on any work being done. Or just any response! 
2 Likes
From an above post, you can check the status of the build on Github:
EDIT: And I just successfully pulled the image and am running 2022.9.2.
Also wondering what adopt was for. I adopted all 3 of mine but I don’t know if I should have don’t that. It’s not picking up any of my 3 SwitchBot bots unless I bring them close to my actual raspberry pi even if there are next to one of my new Esp32 devices.
Why are you disabling automations so often? Seems odd.
Regardless if there are particular automations you disable and re-enable manually a lot you can just put those in a dashboard. If you include automations in the UI in an entities card they still show up with a toggle.
1 Like
Got it working with the v3.8 update for my LYWSD03MMC. Thanks @solyxius and @Edwin_D.
I had these installed more than a year ago (no idea what version of ATC). Connected to them via the telelink flasher, installed v3.8 and set the advertising protocol to BTHome and they started to appear in the devices & services section
Haven’t tried the plant sensors yet but this is a good start.
However I would still like to know how I can connect to the device for the log. At the moment I can only see the log when the ESP32 is connected to the laptop (via the Bluetooth proxy page - ESPHome Bluetooth Proxy). I see that the ESPs are “discovered” in ESPHome and can be adopted but not sure what this does…
Mentioning this because I didn’t see it searching the thread, but there is a pretty bad bug in the required version of zwavejs that prevents communication with certain devices (all of my Zooz brand devices in my case). The bug is documented here: META Issue: Communication problems on v10.x · Issue #4994 · zwave-js/node-zwave-js · GitHub
If you haven’t already, I recommend not updating until this is fixed if you have any Zooz devices. I wish I could safely go back and wait this out, but the next best thing is warning anyone else to avoid my fate.
Not intending to say there’s no issue… but for context, my zwave controller is a Zooz ZST10 stick, and I have ZEN15 and ZEN22 devices that have had no issues since upgrading to 2022.9.
2 Likes
Wow, I found myself in the same position. Would really love for Bluetooth_tracker to work again soon.
Thnx, indeed in the meantime updated as well.
I haven’t yet found the true reason for my HA crash yesterday but so far it appears to be caused by updating from 2022.8.7 to 2022.9.2
My issue is documented here.
More of a warning than error. I always seem to get a few of these.
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
hass-nabucasa 0.54.1 requires cryptography<37.0,>=2.8, but you have cryptography 37.0.4 which is incompatible.
I think I’ve run into an inconsistency in the new (beautiful) Automations view. When I select a Timer as a trigger, I can’t select “active” or “idle”, only “on”, “off”, “unavailable” or “unknown”. Shouldn’t I be able to actually see the “active” or “idle” values rather than the generic “on”, “off”?
Those are translations in your selected language. After creating it, look at the yaml and it should have active or idle. If it doesn’t, that’s a bug, if it does, it’s your language.
Here’s what in the YAML after I created the automation in the IU, no sign or active or idle:
alias: Turn kitchen timer back on again
description: "Test af automatisk slukning af lyset i køkkenet "
trigger:
- platform: state
entity_id:
- automation.kitchen_light_timer
from: "on"
to: "off"
condition:
- condition: state
entity_id: timer.light_kitchen_timer
state: idle
action:
- service: timer.start
data: {}
target:
entity_id: timer.light_kitchen_timer
mode: single
That was embarrasing.
Updated: This time around the drop-down list boxes (from, to) only show “unavailable” or “unknown”. I had to type in “on” and “off”.
alias: Turn kitchen timer back on again
description: "Test af automatisk slukning af lyset i køkkenet "
trigger:
- platform: state
entity_id:
- timer.light_kitchen_timer
from: "on"
to: "off"
condition:
- condition: state
entity_id: timer.light_kitchen_timer
state: idle
action:
- service: timer.start
data: {}
target:
entity_id: timer.light_kitchen_timer
mode: single
Looks like timers don’t have state translations yet, so you have to manually put them in.
Check! 
Should I point this out to someone or put a comment about missing state translation somewhere?
/// Bjarne