🦚

Bluetooth proxies, BP1 and BP2; BP2 has excellent capture efficiency.

Date

Jun 25, 2026 9:11 AM

Sensors

BP2-POEBP1BLEDongle-1M

BLE sensors offer several unique advantages: on the one hand, they are low-power; on the other, they require no additional connections, relying solely on broadcasting. In our recent experiments, we used the nRF52840 to broadcast to BTHome once per second, then observed the gateway’s capture efficiency. The packet loss rate for BP1 was as high as 100, whilst the BLE-to-Ethernet adapter for BP2 managed to keep it in single figures, sometimes as low as 2 or 3. Provided that running an Ethernet cable is not too much of a hassle, the POE-powered BP2 clearly has the potential to enable these low-power broadcasting devices to perform more effectively. Another finding was that, within HA’s Bluetooth settings, blocking a BP device may not actually block it; the devices continue to receive signals. However, disabling the entire device within ESPHome does have the desired effect. This suggests there may be some sort of bug in the system. Of course, you are free to simply unplug the power from those gateways. Another point is that devices sometimes switch between different gateways; for example, the device in question had been connected to the BP2 all along but later migrated to the BP1, which is also a possible scenario. Overall, we have observed that the POE Bluetooth gateway is capable of capturing Bluetooth broadcast packets very effectively.

Here are some points worth noting:

Bluetooth gateways using BLE-Wi-Fi lose a significant number of data packets during capture gaps; in this instance, out of 255 packets, more than 130 were lost.

When using the BP1 or BLEDongle-1M, some packets are lost; when the sensor operates in real time and does not retransmit broadcasts, this loss can be significant. The scenario shown here represents an extreme case.

Under normal, reasonable circumstances, the packet loss rate is around 100/255, which is broadly in line with expectations. Wi-Fi and BLE are used in conjunction, and the default scan interval is approximately 1/3 of a second(

Switching gateways here reveals some rather dramatic changes.

Packets are not always routed to the node with the weakest signal; sometimes they are routed to a more distant node, and as the signal travels further, the probability of packet loss increases accordingly.

One current issue with HA is that, on occasion, they may be assigned to different nodes even when they are in the same location; this behaviour is uncontrollable. We have found that the only change we can make is to disable the currently connected BP, thereby forcing it to move to another node.

Ideally, by using a BP2 with PoE and ensuring that the device is connected to the access point with the strongest signal—as in this case—a fairly good signal capture rate can be achieved.

When conditions are ideal, everything happens almost in real time, and the chances of them being lost are very slim.(The smaller the missing number, the more favourable the situation)

To illustrate this clearly, this is what a change in the properties of a device broadcasting once every second looks like. The pattern of change is an incrementing sequence from 1 to 255, after which it loops. The fewer numbers that are missing, the better; the faster the updates, the better.

As the gateway, BP1 can see that some of their packets are being lost.

This shows the result of withdrawing funds from BLE-POE, as reported by BP2, They look incredibly smooth and fluid.