So they cannot be used together? How about auto lock? Did you use node red or the built-in one?
I use the built-in auto lock
You can use the built-in auto unlock, I just don’t do it
1 Like
Thanks for the information
1 Like
how do you get those quick response times? 
I use an ESP32 DevKitC v4, with
Home Assistant 2022.12.5
Supervisor 2022.11.2
Operating System 9.4
Frontend 20221213.0 - latest
and ESPHome 2022.12.0 (switched back to the stable branch - but the latest beta should be the same, right - they are both named 2022.12.0)
the ESP is maybe 30cm from the lock and the WIFI accesspint is not even 5m away from the ESP but still the absolute BEST response time I get is 5 seconds - more often than not, it’s somewhere between 10 and 15 seconds. That being the time between the moment I click on unlock, and the lock starting to move.
Am I doing something wrong?
I just ordered an ethernet ESP32 board to play around with - maybe this will make the reaction time better…
just to be clear: I’m using the Yale Access Bluetooth integration
I’m using a Olimex ESP32 Power-over-Ethernet ISO right near the lock with esphome 2022.12.0 and esp-idf not arduino
I flashed using a serial cable to use the new partition scheme. When you switch from arduino to esp-idf or from anything earlier than 2012.12.0 you must flash with a cable and not OTA or you will not get the speed up.
I honestly don’t know what that means - never heared I could (should?!) do that. A quick search didn’t bring up anything (except theoretical stuff)
do you have a comprehensive link on that topic and how to change it?
oh well, that looks doable 
will try when the new board arrives - Thanks!
Edit - just flashed the POE ESP32 - and boy, that’s a quick response now … Honestly, I thougt you were exaggerating with 1-1.5s, but it’s definitely true!
There are still a few bottlenecks in the lib that are worth solving now that the connect times are better.
Should have them sorted out for 2023.1.0
this question might be a bit OT, but I didn’t want to create a new thread…
I have my Yale Linus lock connected via the Yale Access Bluetooth integration, and the key got loaded through the August integration.
Can I now safely disable the August integration again? The lock still work when I do so - but will it in the long run? I just fear that it might stop working some day (maybe because the key gets updated or whatever) and I’m locked out of the house
The offline key shouldn’t change unless you delete the user from the lock that the key came from.
Well, I finally got my M5Stack Atom Lite. It was super easy to set up and add to HA. I then easily added my two Yale Assure Lock SL locks to HA using the Yale Access Bluetooth integration. So far, so good!
But that is where the goodness ends. They are sooooooooo slow. And half the time they don’t update at all. I mean, to the point where they are essentially unusable. They are only about 10 feet away from the Atom Lite, so I don’t think signal is an issue. Any thoughts on why this is happening? I expected the bluetooth connection to be significantly better than cloud.
Make sure you are using esphome 2022.12.x or later and you have done a serial flash after switching the framework to esp-idf
Hey @bdraco! Thanks for the quick response! Although I have been using HA for several years, this is my first experience with esphome. I believe I have the current version:
I flashed using this site, which you recommended earlier in this thread:
Other suggestions?
Do you have the HomeKit pairing setup?
OK, I made some progress. I do have the HomeKit pairing codes, so I added the locks to HomeKit Controller. The HomeKit Controller integration does seem to register changes faster now, as well as the Yale integration. Although, I THINK HomeKit seems to be a bit faster. Not sure why that would be? Also, the HomeKit version fails when I use it to lock/unlock the door. I get:
[140277732274144] 78:9C:85:08:B9:30: PDU status was not success: Insufficient authorization
You can’t use the HomeKit integration in HA for this lock since we don’t have the manufacturer specific authorization data.
1 Like
@bdraco So this is interesting. Everything is working correctly for me, but it still takes up to 5 seconds for HA to recognize a change in lock state.
When I download diagnostics, it looks like I have the correct esphome_version:
"storage_data": {
"device_info": {
"uses_password": false,
"name": "atom-bluetooth-proxy-0cf188",
"mac_address": "**REDACTED**",
"compilation_time": "Dec 13 2022, 06:54:17",
"model": "m5stack-atom",
"manufacturer": "Espressif",
"has_deep_sleep": false,
"esphome_version": "2022.12.0b5",
"project_name": "esphome.bluetooth-proxy",
"project_version": "1.0",
"webserver_port": 0,
"bluetooth_proxy_version": 3
},
However, I upgraded HA to 2023.1.1 this morning and received this warning:
Thoughts?
Looks like you are running run of the older beta versions and not the production code so you’ll need to reflash with the latest
