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.