Failing to setup ha integration due to key error

[Daniel-dev22]

The ha integration fails to setup due to a key error here. I was running utecio simplify branch before it was merged with the integration pointing to that and I installed the simplify branch in ha pip environment. Running latest integration as well.

Looking further at the error I believe it's from the U-Bolt Zwave not being read correctly. It does have Bluetooth and instead is being read as GenericLock which doesn't have Bluetooth? Similar issue with being read correctly here #17

I have a latch-5-f and U-Bolt Zwave.

https://github.com/maeneak/utecio/blob/dev/utecio/api.py#L190

Logger: homeassistant.config_entries
Source: config_entries.py:444
First occurred: 9:22:14 AM (1 occurrences)
Last logged: 9:22:14 AM

Error setting up entry Ultraloq Bluetooth for ultraloq_ble
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 444, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ultraloq_ble/__init__.py", line 33, in async_setup_entry
    devices = await client.get_ble_devices()
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/utecio/api.py", line 190, in get_ble_devices
    if device.capabilities.bluetooth:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: type object 'GenericLock' has no attribute 'bluetooth'

[Djelibeybi]

I'm getting the same error with an Ultraloq U-Bolt Pro Wifi lock.

[Daniel-dev22]

I'm getting the same error with an Ultraloq U-Bolt Pro Wifi lock.

Yeah for some reason there's an issue somewhere in the code where u bolts are read as generic locks and it's set to false for Bluetooth. Although the error is as if Bluetooth is not there at all. https://github.com/maeneak/utecio/blob/dev/utecio/__init__.py#L371

Even if you get past this I'm having issues with the bleak implementation where it won't even connect to the locks. The library previously did connect to the locks before bleak retry connector was implemented and a bunch of stuff refactored.

@Djelibeybi I have seen you around in the community/GitHub before do you know anything about Bluetooth/python as the dev is a bit busy as mentioned to me awhile back that he planned to sell his locks and I'm not sure if he did.

I did ask if he could share all of his researc/reverse engineering before then but haven't heard back.

[Djelibeybi]

I noticed that the code has no mention of the U-Bolt Pro series, which is probably why the identification isn't working correctly. If I find some time, I'll debug the response and see if I can at least work out how to get the U-Bolt Pro Wifi identified correctly.

[Daniel-dev22]

I noticed that the code has no mention of the U-Bolt Pro series, which is probably why the identification isn't working correctly. If I find some time, I'll debug the response and see if I can at least work out how to get the U-Bolt Pro Wifi identified correctly.

I wonder if that's why the U-Bolt pro Zwave for me also has this issue. https://github.com/maeneak/utecio/blob/dev/utecio/__init__.py#L263

[Djelibeybi]

That would be my guess, yes. I'm going to take a quick poke around now to see if I can spot anything obvious.

[Daniel-dev22]

That would be my guess, yes. I'm going to take a quick poke around now to see if I can spot anything obvious.

Awesome! Thank you!

[Djelibeybi]

So, the security of the cloud service is pretty bad: it's sending back my admin pin unencrypted. Thankfully it is not sending back the wifi password.

All that aside, I've managed to get the library to identify my lock correctly (though, I haven't actually validated that the capabilities are correct: I just copied the non-Pro definition).

[Daniel-dev22]

So, the security of the cloud service is pretty bad: it's sending back my admin pin unencrypted. Thankfully it is not sending back the wifi password.

All that aside, I've managed to get the library to identify my lock correctly (though, I haven't actually validated that the capabilities are correct: I just copied the non-Pro definition).

Wow and Great progress!

[Djelibeybi]

Sadly, the good news ended there. I've got the Home Assistant integration identifying the lock, but bluetooth commands are failing via my ESPhome Bluetooth proxies. Not sure if the newer locks have a different bluetooth profile or method of authentication, so further debugging is a little out of my wheelhouse unfortunately.

[Daniel-dev22]

Sadly, the good news ended there. I've got the Home Assistant integration identifying the lock, but bluetooth commands are failing via my ESPhome Bluetooth proxies. Not sure if the newer locks have a different bluetooth profile or method of authentication, so further debugging is a little out of my wheelhouse unfortunately.

Yeah that's the issue I'm having. When the utecio and integration switched to using the bleak retry connector I stopped being able to control my latch 5f and my u bolt pro Zwave. Somewhere during that major reactor something broke. In the very early stages of the library I was able to lock and - [ ] unlock my locks.

I also use Esphome Bluetooth proxies.

[Djelibeybi]

I spent most of yesterday with just the utecio library running on a spare Raspberry Pi with its own dedicated Bluetooth controller to see what I could achieve.

I can certainly get it talking, but it seems that my lock doesn't respond like the library assumes a lock should, so I assume the non-Pro devices have different characteristics/responses than the Pro ones, hence the confusion.

Unfortunately, I quickly hit the end of my expertise just getting this far. We need someone with more expertise at reverse engineering encrypted Bluetooth packets to get us further.

[Daniel-dev22]

I spent most of yesterday with just the utecio library running on a spare Raspberry Pi with its own dedicated Bluetooth controller to see what I could achieve.

I can certainly get it talking, but it seems that my lock doesn't respond like the library assumes a lock should, so I assume the non-Pro devices have different characteristics/responses than the Pro ones, hence the confusion.

Unfortunately, I quickly hit the end of my expertise just getting this far. We need someone with more expertise at reverse engineering encrypted Bluetooth packets to get us further.

I'm going to try messaging the developer again to see if he can share all of his reverse engineering research on utecio.