Wohooo, thanks again- Great Release! Bluetooth support is rocking. Looks like i can remove 3 ESP32 that relayed some Sensor Status to Homeassistant
1 Like
@cogneato says it doesn’t work. You say it does.
I guess I’ll just have to try myself 
These “people” working on v4 for Docker - who are they? Do you have a link to GitHUB or a Forum where I can get i touch with them?
i’m using it now, idk who they are… right now im on v4 and works as expected
Has anyone tried a Schlage Sense homekit deadbolt yet with this new bluetooth/homekit feature?
3 Likes
Ok, in what environment did you install it ?
in docker, but lets go further in this topic, as other people got it to work also. i posted a guide how to do it.
As Bluetooth range is quite limited, it would be nice to have some “remote bluetooth” so I can use it where my BT devices are. E.g. with using a ESPhome device that would route the bluetooth traffic, and would appear in Home Assistant just like a usb stick, but handling everthing. I know I can run platforms directly on ESPhome, but it’s just limited by it’s hardware (e.g. I need 2 esphome devices because I have too many Mi Floras and I have 2 additional esphome which can only handle 1 platform each). This would also open options for precence/room tracking.
5 Likes
Sorry, but that is a Google Cloud Project Guide and not a guide on how to install Assistant Relay in Docker. If you don’t mind, I’d like to request your assistance to get this running in docker as well as how to call it from HA (how to pass commands). But perhaps we should go somewhere else with this discussion? Perhaps here: Assistant Relay - Third party integrations - Home Assistant Community (home-assistant.io)
Unless you rather not be bothered 
Great work again, upgrade went fine and everything is working perfectly except for:
Config entry 'SpeedTest' for speedtestdotnet integration not ready yet: HTTP Error 403: Forbidden; Retrying in background
I am not able to configure it again. Removing the integration and adding it again made no difference.
No big deal, just wanted to report it.
1 Like
So you’re suggesting that in the end we should all move to the native integration as this one will be supported from now on, and the BLE monitor will be phased out in the future? I’m using it for all my temp sensors (Xiaomi round and square ones (how’s that for technical naming? ;)) with custom firmware).
Ha! You’re right. I forgot to put that - fixed. It’s RX-V673 so I can’t use MusicCast. I’m using this integration mostly for some automations revolving around changing sources anyway.
@silvrr Nope. Unfortunately RX-V673 doesn’t have MusicCast support.
Thank you for this amazing update! I normally wait for the .3 release, but have upgraded immediately this time, due to what I consider to be such major improvements, mainly the Bluetooth functionality and the Repair feature, in this release. I love them both. The native Bluetooth support has made integrating my MiFlora sensors a breeze. It’s something I had been meaning to get round to doing for a long time and I finally have them in Home Assistant with no friction at all. I’m hoping that this will unlock additional functionality in future for other Bluetooth devices, such as Bluetooth lock keypads (e.g. from Yale/August and Nuki) and that Bluetooth presence gets a look in next month.
The second time today I revert to the last 2022.7.X version.
As soon as I update to 2022.8.0 all my Onvif devices lose connection and cannot be reconnected anymore.
Reverting back to 2022.7.X solves the issue.
Also the streams are working fine in the Onvif Device Manager.
I will await a future update in which Onvif works as it should again.
5 Likes
What about Infrared? Very nice that Bluetooth is available.
As for Infrared, the LIRC integration is broken, has no code owners, and submitted issues time out and the bot closes them. I understand, but hope that since there are no code owners and any new issues just fall into the abyss, maybe someone might be interested if they heard about it.
I’ve gotten LIRC IR blasting working using command_line executing bash scripts and with a managing cron job without the integration. How is beyond this thread. If any Devs are interested I’m happy to share, but I’m not python savvy enough to do python integration development myself.
Cheers
INKBIRD, you had me salivating, but my keezers use the ITC-308-WIFI to keep the beer cold. Yes wifi, not Bluetooth. Oh well.
1 Like
Yes, but currently we dont support LYWSD03MMC and similar sensors with custom firmware yet. For these sensors, you will have to use BLE monitor for now, but we will move this to a core HA integration in the future.
Very cool. Thank you for the latest release and putting focus on BLE devices.
Is there any chance this might lead to better support of BLE devices via hubs like a Tasmota ESP32 or similar?
The august locks require additional authorization data to work in HomeKit. We don’t have that data yet. But here is some good news on this front as I’m working on a Yale Access Bluetooth integration which will work with the August locks as well for next month. Checkout the release party video stream for a demo.
3 Likes
Is this also the reason Schlage Sense bluetooth/homekit lock doesn’t seem to want to pair after it’s discovered by HA?
Having multiple Mi Flora sensors I can say these new integration makes a lot of mess currently.
Automatically recognized devices (by passive monitor) have all the same names “Flower care” and all of them have the same sensors differing only by sequence number (sensor.flower_care_moisture, sensor.flower_care_moisture_2, etc.).
This way there is no way I could recognize which sensor it really is - there are no MAC addresses given/visible which other (HACS) integrations are commonly using to identify sensors.
In fact, I don’t know how to use it - with 10 MiFlora sensors it’s a kind of disaster 