decoder

decoder copied to clipboard

Is your feature request related to a problem? Please describe.

I have a sensor device that advertises service data for two UUIDs, and I want to create a decoder for it (https://github.com/theengs/decoder/pull/138). Currently, Theengs Decoder seems to support only one servicedatauuid and one servicedata property.

Describe the solution you'd like

This is how service data for my particular device are sent to the decoder now:

❯ python3 examples/python/ScanAndDecode.py |grep RDL
D8:4B:C1:98:69:1E RSSI: -71 AdvertisementData(local_name='RDL52832', manufacturer_data={76: b'\x02\x15\xfd\xa5\x06\x93\xa4\xe2O\xb1\xaf\xcf\xc6\xeb\x07dx%\x00\x01\x00\x02\xd8'}, service_data={'00001803-0000-1000-8000-00805f9b34fb': b'\xd8K\xc1\x98i\x1e\x00\x01\x00\x02\x07\x03\xe8d', '00000318-0000-1000-8000-00805f9b34fb': b'\x15O8E\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\t\x07'})
data sent to decoder:  {"servicedatauuid": "1803", "servicedata": "d84bc198691e000100020703e864", "manufacturerdata": "4c000215fda50693a4e24fb1afcfc6eb0764782500010002d8", "name": "RDL52832"}

The example Python script only sends the first service data to the decoder, in this case for UUID 1803, while for this particular device I'm interested in the service data for UUID 0318.

What I would like is that I could send something like the following JSON data to the decoder and the service data for both UUIDs should then be available for further decoding:

{"servicedata": {"1803": "d84bc198691e000100020703e864", "0318": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}, "manufacturerdata": "4c000215fda50693a4e24fb1afcfc6eb0764782500010002d8", "name": "RDL52832"}

Describe alternatives you've considered

I could first check the name of the device (e.g. in Theengs Explorer) and then send the service data for UUID 0318 to the decoder if that specific device is detected, but this is just a hack.

Additional context

I'm not sure there are many devices that advertise service data on multiple UUIDs (this is the first one I discovered), but a general approach for this case seems nice to have.

I remember having this decoding case with a Xiaomi device, with OMG we are looping on the service data, and for each service data passing a complete JSON object with all the parameters: https://github.com/1technophile/OpenMQTTGateway/blob/a388f14e7518cd8923b1c82569ca12cff052638d/main/ZgatewayBT.ino#L475

Do you think this method could be used in your case as a short-term solution?

In the mid-term, I agree with you, that we should handle a comprehensive definition of the BLE device, so this passes by having the capability to handle multiple service data.

Sure, I can implement this method in Theengs Explorer too as a short-term solution!

Implemented in Theengs Explorer in https://github.com/theengs/explorer/pull/7. This is able to reliably detect the RDL52832. Theengs Gateway should probably also implement a similar method as a short-term solution for these devices.

This should be simple, just need to check for a nested JSON object in the servicedata and proceed accordingly.

This is implemented in OpenMQTTGateway already, sending separate messages with the different serviceuuids and servicedata to Decoder to also allow for single uuid/servicedata model condition recognitions.

Implemented in Theengs Gateway in https://github.com/theengs/gateway/pull/154.