Maximum advertisement packet size limits the number of readings of one type

[MartinEssink]

I am trying to transmit readings from a digital smart meter over BLE to home assistant. BTHome appears well suited for broadcasting these values. However I am running into issues relating to the maximum packet size of a BLE advertising packet.

Given the maximal advertisable data (37bytes, with 6 for MAC, 3 for capabilities), 28 bytes are left for BTHome. Then, when using encryption, this leaves only (28-4(len, uuid, header)-4(counter)-4(mic)=) 16bytes. It is possible to transmit multiple advertisement containing different value types, but it is not possible to, for example, transmit 4 kWh readings.

I have looked at advertising using extended advertisements. This works well on the transmitter side, but is currently not feasible due to the lack of support in bleak (related to issue #45).

Therefore, would it be possible to add the possibility to 'tag' individual readings. For example, if a certain bit is set in the BThome header a measurement id is followed by an id. That would mean the data, even for the same reading type, can be spread over multiple advertisement packets.

In that case an advertisement of two temperatures could be:
0x44 0x02 0x00 0xC4 0x09 0x02 0x01 0xC4 0x09

where partial updates would be possible as well:
0x44 0x02 0x01 0xC4 0x09

[Ernst79]

I understand your question, but that would require a big change, as the length of the sensor dat is now fixed. If we optionally add a ID, we need another byte and we have a different length of the sensor data.

It might be possible if we set a flag bit that tells the receiver that it should expect an extra byte with the ID. , but I’m afraid all receiving devices that aren’t updated will receiving incorrect data. This will definitely be a breaking change. I will have to seriously think if this is possible

[MartinEssink]

Indeed, this would be a big change, and would require some very careful consideration. Using an additional bit in the header would allow for switching between the two methods of transmitting data, but I don't know what the current version does when one of those bits is set. I do not want to strictly suggest one solution, but I want to indicate this is a shortcoming of the protocol that may warrant some changes.

There is also another method of getting around this issue, which is to include a dummy sensor (like the packet id 0x00), which is a sequence number for the packet, such that multiple advertisement packets can be chained together. This would however be a bit more involved on the receiver side, since the packets cannot be processed out-of-order.

[pvvx]

However I am running into issues relating to the maximum packet size of a BLE advertising packet.

Turn on "Extended Advertising".
BTHome accepts "Extended Advertising" without any problems.
https://blog.nordicsemi.com/getconnected/bluetooth-5-advertising-extensions

[MartinEssink]

However I am running into issues relating to the maximum packet size of a BLE advertising packet.

Turn on "Extended Advertising". BTHome accepts "Extended Advertising" without any problems. https://blog.nordicsemi.com/getconnected/bluetooth-5-advertising-extensions

Yes, bthome does accept it, but the underlying layers do not. As stated in my initial message, bleak does not appear to support extended advertising. Additionally, driver support for the extension is very poor.

[pvvx]

Forget about Linux. Everything is bad in it and has not met current standards for a long time. In Android, everything works on the basic API.

Bleak is not even going to add Bluetooth v5.0. And today devices with v6.0 are already on sale. Bluez only supports core v4.2.

All the cheapest сhinese BLE chips have open SDKs with examples of work in BT Core v5.3.

Passive BLE Monitor integration works in Linux bypassing legacy APIs. Aioblescan is used with operation via HCI.

[mhaberler]

I concur

esp32 extended advertising works just fine

both iOS and Android support it as well - for instance, Sensor Logger can record extended ads perfectly on both platforms

and if Linux BLE support doesnt cut it, there's the escape hatch of dongles like BlueIO or https://github.com/pvvx/ADV_BLE2UARThttps://github.com/pvvx/ADV_BLE2UART

it is time to extend the spec to cover extended advertising and not be held back by defunct stacks

[pvvx]

Many сhinese SDKs for cheap SoCs already include examples with "PAwR" support from BLE version 5.4.
This is already a two-way communication. How will the "BTHome" integration live on?

@mhaberler - BluedIO can be considered if it supports Bluetooth version 5.4. Otherwise, the purchase does not make sense.

[mhaberler]

interesting - wasnt aware of PAwR, thanks

not sure where the response path helps here; I'm just trying to funnel larger packets over ads

BlueIO uses Renesas 5.0 chips