BLE device visible in nRF Connect but never discovered by HA Bluetooth integration

Setup

  • Home Assistant OS 18.3 / Core 2026.9.3
  • Raspberry Pi 4
  • BLE Battery Management System integration v2.17 (BMS_BLE-HA)
  • 4x Dyness AR1.2 100Ah LiFePO4 batteries with Bluetooth only BMS

The Problem

I have 4 identical Dyness AR1.2 batteries. Three are discovered and working
perfectly in HA. The fourth (serial 1372) has never appeared in HA’s Bluetooth
integration scan despite being visible to every other Bluetooth tool I’ve tried.

What I’ve tried

  • Physically moved Pi to within 5ft of all 4 batteries
  • Pulled surrounding batteries out of compartment for clear line of sight to 1372
  • Force closed Dyness app on phone to release any BLE connection
  • Disabled one of the working batteries in HA to free up a connection slot
  • Restarted HA multiple times
  • Reloaded Bluetooth integration

What CAN see battery 1372

  • nRF Connect on Samsung S25 Ultra — sees it at -77dBm from Pi’s position
  • Dyness app on phone — connects and shows full data
  • HA Bluetooth scan sees the OTHER three batteries fine at -88dBm

MAC addresses of all 4 batteries

  • 1101: 04:D8:10:0D:31:35 (working)
  • 1109: C0:D1:00:0C:31:35 (working)
  • 1725: AB:21:00:0C:31:35 (working)
  • 1372: B1:41:10:0B:31:35 (never discovered)

Key observation

All four batteries are identical hardware/firmware (Nations NS-BLE-1.0 BMS,
same GATT structure, same firmware version). The three working batteries were
discovered immediately when the integration was first installed. 1372 has
never appeared in HA’s Bluetooth scan at all, even with clear line of sight
and other batteries disabled.

Notice the MAC addresses — 1101 starts with 04 (public address), while
1109 (C0), 1725 (AB) and 1372 (B1) all appear to be random addresses.
Three of the four random-address batteries work fine, but 1372 never
appears. Could there be something specific about the B1 prefix that
causes HA to filter it out?

Could there be a caching or blacklist issue in HA’s Bluetooth stack
preventing this specific device from being discovered?

Any help appreciated!

I’m by far not anything like a BT expert…

I ran into a similar issue trying to reach my Meater Pro BT probes with a custom integration.

Apparently the ESPHome BT proxy I was using only enabled three connection channels by default. I didn’t realize this until I had given up on the integration and resigned to use the built-in cloud app instead. I have since reconfigured the ESPHome BT Proxy to enable 4 connection channels. I haven’t tried the other integration again so I don’t know if that actually solved the issue I was having or not.

I don’t know if that’s related to your issue or not since I don’t know if the RPi sets the connection channels to 3 by default. But it’s worth a shot to check. But don’t ask me how. I have no idea.