Fix LD2410 BLE detection with passive scans

[bdraco]

Proposed change

Fix LD2410 BLE detection with passive scans

The local name doesn't appear to ever be sent passively, however
they can be detected by a combination of manufacturer_data
and service_uuid after a few hours.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @930913, mind taking a look at this pull request as it has been labeled with an integration (ld2410_ble) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of ld2410_ble can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Change the title of the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign ld2410_ble Removes the current integration label and assignees on the issue, add the integration domain after the command.

[bencorrado]

I am fairly confused on what is going on here with the manufacturer ID. It appears they are using TomTom's manufacturer ID (256 / 0x100) and the chip vendor Zhuhai Jieli technology Co.,Ltd (1494 / 0x05D6) that is on the board. I think we should probably stick with the chip vendor as the TomTom one is probably a firmware bug (and likely unauthorized). @bdraco are you seeing both in your passive scans or just TomTom (256 / 0x100)?

When I take a raw GAP scan I get 0x020106030330AF10FF000107011615092200E7781897D3620CFFD60508004A4C414953444B1109484C4B2D4C4432343130425F44333632

[bdraco]

I only see 256 for both of my test devices

[bencorrado]

I only see 256 for both of my test devices

Interesting, what tool are you using to scan? nRF Connect is showing both for me. I wonder if what you are using is just grabbing the first manufacturer specific data section and ignoring the next one. Probably not a huge harm to using it the way you are above, but it is certainly odd to see two in one GAP profile and maybe they will fix it at some point to just be the valid JZ (1494 / 0x05D6).

[bdraco]

I'm just looking at the diagnostics with active scans disabled

          {
            "name": "",
            "address": "47:5D:EC:E3:06:35",
            "rssi": -95,
            "advertisement_data": [
              null,
              {
                "256": {
                  "__type": "<class 'bytes'>",
                  "repr": "b'\\x07\\x01\\x16\\x15\\t\"\\x00G]\\xec\\xe3\\x065'"
                }
              },
              {},
              [
                "0000af30-0000-1000-8000-00805f9b34fb"
              ],
              -127,
              -95,
              []
            ],

[bencorrado]

I am unable to reproduce with the exact same results after 3 hours of testing. Some interesting findings though. The devices with updated 2.01.x firmware report normally in passive mode and show up as seen below. However my units running the older 1.07.22091516 never showed up at all in passive mode during that time, I will see if it catches it overnight.

2023-02-06 20:20:20.991 DEBUG (MainThread) [homeassistant.components.bluetooth.manager] ble-monitor (24:0a:c4:9e:fe:f4): CA:36:4C:D8:6B:74 AdvertisementData(local_name='HLK-LD2410_6B74', manufacturer_data={256: b'\x01\x02\t\x02\x02#\x00\xca6L\xd8kt', 1494: b'\x08\x00JLAISDK'}, service_uuids=['0000af30-0000-1000-8000-00805f9b34fb'], tx_power=-127, rssi=-74) match: set()

Where ble-monitor is a ESP32 setup for passive monitoring only.

2023-02-06 20:05:20.183 DEBUG (MainThread) [homeassistant.components.bluetooth.manager] hci0 (7C:5C:F8:2F:08:D6) [connectable]: CA:36:4C:D8:6B:74 AdvertisementData(local_name='HLK-LD2410_6B74', manufacturer_data={256: b'\x01\x02\t\x02\x02#\x00\xca6L\xd8kt', 1494: b'\x08\x00JLAISDK'}, service_uuids=['00001800-0000-1000-8000-00805f9b34fb', '0000ae00-0000-1000-8000-00805f9b34fb', '0000fff0-0000-1000-8000-00805f9b34fb'], rssi=-48) match: set()

And similar here where hci0 is on an Intel NUC also in passive mode.

I think this is a good work around for older version(s) of firmware and it looks like the vendor has patched the device.

[bdraco]

I think this change will only cover the older firmware. Happy to take another PR after this one to add passive support for newer firmwares if needed