pvvx
commented
1 year ago rfc8428 is designed for HTTP and other protocols in which it is possible to include structures with almost unlimited size.
The Maximum Length of Data you can Include in a BLE Advertising Packet = 29 bytes. Of these, part goes to the header (structure size, structure type, structure identifier, i.e. from 4 bytes) and another 3 bytes to standard flags describing the type of device. As a result, no more than 22 bytes remain for information.
Larger sizes are possible only in the Bluetooth 5.0 version. But its support in Linux is not expected since 2016. And today it requires a revision of the functions of the kernel and most of the applications, which will take at least five years with the active support of a group accepting changes in Linux. What is not and is not expected. There is only the opposite - resistance. Active actions to restore the Linux kernel after the introduction of curves and malicious implementations for BLE are accepted only in Android. But this is a Google option, not a public one.
Today, Bluetooth 5.0+ support is available only in Linux implementations for single - boarders with alternative patches from Chinese programmers.
The WEB Bluetooth API does not yet have Bluetooth 5.0 support. The reasons are described above. As a result, the use of RFC8428 is simply impossible.
gebsl
Hello, this is a not a feature request per-se, but rather a "question/discussion" issue.
Is your feature request related to a problem? Please describe. Are there any plans of aligning the BTHome format with SenML, specified in RFC8428. As SenML is an already established standard that includes a binary representation (CBOR), format alignment could enhance compatibility with other sensors.
Describe the solution you'd like Format compatibility with SenML, or alternatively allowing SenML as an alternative format to transmit data.
Additional context SenML RFC: https://datatracker.ietf.org/doc/html/rfc8428