Hi all,
Since the bluetooth_tracker was deliberately broken in 2022.7.x (it was not depreciated otherwise we would have had warnings and a timeframe to adjust), I am trying to find an alternative.
Whilst the BLE tracker works it is no good for tracking phones or tablets (as others have already said) as the MAC address is randomised.
I was hoping the new bluetooth proxy stuff with ESP would offer a solution but that uses BLE as well (so it appears) so that seems to be a none starter!
I am shocked that there is crickets (silence) from the devs on when/if the classic bluetooth tracker will be fixed.
Therefore, using the BLE device tracker integration:
How do you track BLE tags without a fixed MAC address? I don’t think that is possible. I would love to be proved wrong.
So can anyone recommend a BLE beacon/keytag that has a fixed MAC address that works with the BLE device tracker?
I use Room Assistant with the classic bluetooth integration for detecting presence but it is slow, which is fine for my application of knowing if a specific phone is in the kitchen, time is not of the essence here.
I was thinking of adding another instance with a bigger RSSI number so that it would detect bluetooth devices further away (called home) i.e. replicating the bluetooth tracker.
However I am unsure if when the tracked device is within range of the kitchen it would change state, if it was still within range of the home instance.
I would appreciate any comments and suggestions, especially on the tags. Links would be appreciated.
BTW I am in the UK.
Thanks
follow those docs, and the bottom blurb may be missleading but just add the text inside the line with spaces, e.g.
GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false"
My August lock is working so much better in this version, love it! Cant say it enough, you guys are doing a great job with Bluetooth.
That said, I do find it a bit slow, takes about 5 to 8 sec to open /close the lock. Is this the expected response time for these locks?, I am already using one of the recommended long rance bluetooth adapter with an extension, a few meterss frim the lock.
In the release party you guys stressed the importance of all the tweaks at the OS level in Home Assistant OS to improve Bluetooth performance. I am currently using Supervised on a RPi4 with Debian and I am indeed contemplating the switch but unfortunately I cannot at the moment due to some dependencies (not really relevant)…
@bdraco, would you be able to to give us a quick, no strings attached overview of the tewaks you have performed in HA OS? That would be awsome for us with Supervised installations…
I’ve been getting this error message quite some times after upgrading to 2022.9.x:
Logger: root
Source: runner.py:119
First occurred: 09:25:29 (149807 occurrences)
Last logged: 22:13:05
A message handler raised an exception: 'org.bluez.Device1'. Traceback (most recent call last): File "/usr/local/lib/python3.10/site-packages/dbus_next/message_bus.py", line 668, in _process_message result = handler(msg) File "/usr/local/lib/python3.10/site-packages/bleak/backends/bluezdbus/manager.py", line 731, in _parse_msg condition_callback() File "/usr/local/lib/python3.10/site-packages/bleak/backends/bluezdbus/manager.py", line 603, in callback self._properties[device_path][defs.DEVICE_INTERFACE][property_name] KeyError: 'org.bluez.Device1'
As I’m lost for suggestions and ideas, does anyone know what this is about?
I can’t take credit for all of those as I’ve only been doing the work on the core side of the house.
Here are the top three changes that make the most difference with performance:
- Update to linux kernel 5.15.65
- Replace dbus with GitHub - bus1/dbus-broker: Linux D-Bus Message Broker (this is the big performance difference)
- Update firmware blobs from kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel
Thanks! Thats exactly what I was looking for…
Do you have the same 5-8 sec response with your August locks?
This is so much better and reliable than z-wave with those locks so I’m happy but if I can further improve it then even better…
I’m having the same issue with temperature control missing from the thermostat.
I’m using a zen thermostat via ZHA. Happened after the 09 update.
Mine are around 3-4s but I’m also using the dev version of bleak which has some more performance improvements
Thanks for the response.
I’m using the BLE monitor custom component at the moment (https://github.com/custom-components/ble_monitor) which recognises the devices in question. The idea was to simplify this using the Bluetooth proxy as the devices “automatically” appear in the integration section.
What puzzles me is the fact the scan on the BT proxy doesn’t find a single device.
What did you do here “Once I stopped ignoring it it was rediscovered and added perfectly. So maybe check the filter to show ignored devices!”? I have no access to the yaml as this is a precompiled binary on ESPHome Bluetooth Proxy
Ok, thanks, I’ll see if I can do some of those tweaks and get closer to that so I can wait until I get the Yellow PoE, hopefully there are no further shipping delays for that one…
Did you solve this Thomas? I’m in the exact same scenario … (i.e. all working fine previously thru BLE Monitor)
PS - also having issues trying to flash newer v3.8 update to the sensors with dreaded “gatt” error, which I think might be the solution (if I can ever resolve).
Could I use the Bluetooth integration to detect which room my phone is in ? If so, what would I need to get his working ? (I am using odroid2).
Edit: actually, considering the limited range of bluetooth, it would be enough just to b be able to tell the range to the phone, and trigger animations when it entered or left a specific target distance.
Other than this, I don’t really see the point of this integration. Bluetooth range is pretty limited, and the only things I can think of in my home that use it are wireless speakers. I guess it might be useful for onboarding new devices, assuming you could bring them close enough, as sometimes things need configuring with the wifi SSD / password, which can only be done via bluetooth. I suppose if I had no speakers in the room I keep my HA hub in, and wanted to play music there it could be OK for that as well. I saw something about Yale locks using bluetooth, but I am guessing that is for the low end locks, the expensive ones like I have on my front door use zigbee and encrpytion.
No, not yet… a bit frustrating seeing the various videos that magically pull in all these new sensors after the Bluetooth proxy is built.
I’ll flash the ATC firmware onto a few new Xiaomi temp/hum sensors later to check whether the fact the current sensors are known to HA has any bearing on this. But the fact there is so much BLE traffic in my house without anything seen on the console still makes me think the BT proxy doesn’t see any of this.
Not sure what the setting ‘type active’ does. I thought the current implementation only supports passive BLE not given this is a precompiled binary I have no idea how to change this
Definitely need to flash 3.8 and then change the advertising type to BTHome … https://github.com/pvvx/ATC_MiThermometer/raw/master/ATC_v38.bin
Was a mission, but stubborn persistence smashing the reconnect and start flashing with new batteries eventually got the job done.
Now I have the devices in BTHome integration with 4 entities attached flowing into grafana nicely.
Hello,
In the change log I found:
Light’s white_value was deprecated in Home Assistant Core 2021.4 by PR #47720 and replaced by color mode white in Home Assistant Core 2021.7 by PR #51411.
Which is kind of awkward since white value was used for rgbw light in mqtt template light.
Mentioned PRs points to new modes which are going to support light based on strictly defined light modes. However I cannot find rgbw supported by mqtt template light
Can some with expertise comment on this oversight?
Afaik the custom component used another bluetooth stack, are you sure you’re using the original stuff now? It should be these:
esp32_ble_tracker:
bluetooth_proxy:
Also be aware, I used to see all ble macs logged at the esp32 at the default logging level. I do not see that anymore, maybe because the proxy is handling them, maybe because they changed the log level, I don’t know. But the proxy it is working for me, HA is seeing my plant sensors and inkbird temp sensor, also the ones definitely not in range of HA itself.
As for the ignored devices, make sure the bluetooth integrations/devices are not ignored in the past (chosen one is just an example of course):
Thanks again for everything that’s been done! It’s so great to enjoy such a lively support base and community behind one of the most sleek and flexible smart home platforms out there. 
Using HA extensively for the past 2+ years, I can also share some well meant feedback, if it helps; I know there are so many different ways people want things to work and different ways to solve things from a user point of view. I am not particularly excited about the way certain options are moved around the interface or tucked away in a context menu. I’m all for simplicity, but I don’t feel something as key as a description for an automation is in the way and should be moved inside a menu. That’s a click too far IMO. The same goes for the system health; while a bit more technical perhaps, keeping this one click away instead of three doesn’t obstruct anything. If there is one thing HA could benefit from, it’s keeping the interface consistent and avoid moving around options on a regular basis as much as possible.
But really I’m not complaining. Just sharing out of caring 
I really don’t like how my picture glance cards when tapped for live view now have all the settings in the popped up dialog box as an artifact of combining them in this release. There’s no way to hide the settings right?