Gigaset G-Tag - Failed to find characteristic

[kroman666]

With OpenMQTTGateway-0.9.10 I cannot make reading out the battery level from a Gigaset G-Tag (not the Keeper).

T: Hey I got a callback home/OMG1/commands/MQTTtoBT/config
N: [ MQTT->OMG ]: {"ble_read_address":"7C:2F:80:AA:BB:CC","ble_read_service":"0000180f-0000-1000-8000-00805f9b34fb","ble_read_char":"00002a19-0000-1000-8000-00805f9b34fb","immediate":true}
T: MQTTtoBT json set
T: update WorB
T: update WorB
T: BLE ACTION TTL = 1
T: BLE ACTION Read
T: getDeviceByMac 7C:2F:80:AA:BB:CC
T: update 7C:2F:80:AA:BB:CC
T: getDeviceByMac 7C:2F:80:AA:BB:CC
N: BLE Connect begin
T: Model to connect found: 7C:2F:80:AA:BB:CC
T: processing BLE read
T: Found service: 0000180f-0000-1000-8000-00805f9b34fb
T: Client isConnected, freeHeap: 143940
N: Failed to find characteristic UUID: 00002a19-0000-1000-8000-00805f9b34fb
N: BLE Connect end
N: BLE Connect begin
N: BLE Connect end
N: Send on /BTtoMQTT/7C2F80AABBCC msg {"id":"7C:2F:80:AA:BB:CC","service":"0000180f-0000-1000-8000-00805f9b34fb","characteristic":"00002a19-0000-1000-8000-00805f9b34fb","success":false}
T: jsonPubl - ON
T: [ OMG->MQTT ] topic: home/OMG1/BTtoMQTT/7C2F80AABBCC msg: {"id":"7C:2F:80:AA:BB:CC","service":"0000180f-0000-1000-8000-00805f9b34fb","characteristic":"00002a19-0000-1000-8000-00805f9b34fb","success":false}

The service is found, but the characteristics is not. But actually the UUID of the characteristics should be correct.

$ sudo gatttool -b 7C:2F:80:AA:BB:CC --primary
attr handle = 0x0001, end grp handle = 0x0009 uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle = 0x000c, end grp handle = 0x000f uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle = 0x0010, end grp handle = 0x0018 uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle = 0x0019, end grp handle = 0x001c uuid: 0000180f-0000-1000-8000-00805f9b34fb

$ sudo gatttool -b 7C:2F:80:AA:BB:CC --characteristics
handle = 0x0002, char properties = 0x02, char value handle = 0x0003, uuid = 00002a00-0000-1000-8000-00805f9b34fb
handle = 0x0004, char properties = 0x02, char value handle = 0x0005, uuid = 00002a01-0000-1000-8000-00805f9b34fb
handle = 0x0006, char properties = 0x0a, char value handle = 0x0007, uuid = 00002a02-0000-1000-8000-00805f9b34fb
handle = 0x0008, char properties = 0x02, char value handle = 0x0009, uuid = 00002a04-0000-1000-8000-00805f9b34fb
handle = 0x000d, char properties = 0x22, char value handle = 0x000e, uuid = 00002a05-0000-1000-8000-00805f9b34fb
handle = 0x0011, char properties = 0x02, char value handle = 0x0012, uuid = 00002a29-0000-1000-8000-00805f9b34fb
handle = 0x0013, char properties = 0x02, char value handle = 0x0014, uuid = 00002a24-0000-1000-8000-00805f9b34fb
handle = 0x0015, char properties = 0x02, char value handle = 0x0016, uuid = 00002a26-0000-1000-8000-00805f9b34fb
handle = 0x0017, char properties = 0x02, char value handle = 0x0018, uuid = 00002a28-0000-1000-8000-00805f9b34fb
handle = 0x001a, char properties = 0x12, char value handle = 0x001b, uuid = 00002a19-0000-1000-8000-00805f9b34fb

$ sudo gatttool -b 7C:2F:80:AA:BB:CC --char-read --uuid=00002a19-0000-1000-8000-00805f9b34fb
handle: 0x001b value: 42

Does the Gigaset G-Tag need special treatment on OMG or anyone knows what's the problem?

Thanks in advance!

[DigiH]

Hi @kroman666, just out of curiosity, have you tried with 16 instead of the complete 128 bit service and characteristic. and/or including the expected value_type?

{"ble_read_address":"7C:2F:80:AA:BB:CC","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","immediate":true}

At least for some of my devices I have to use the shorter 16 bit service/characteristic.

[kroman666]

Hi @DigiH, I have tried so many things without success.
But not this, which works :)
Thank you so much!

[1technophile]

Hi @kroman666,

It could be interesting to integrate this natively into OMG. Could you share some broacasted advertisement payload examples from this device. You can find those into the BTtoMQTT topic from your broker.

[DigiH]

@1technophile, also as this is the default service/characteristic combination for the battery level it could be the start of possibly introducing READ presets, something like

{"ble_read_address":"AA:BB:CC:DD:EE:FF", "ble_read_preset":"battery_level}

to allow for easy reading of such common service/characteristic combinations.

[kroman666]

Hi @1technophile,

that sounds great!
This is what OMG is sending for that beacon (untouched now):

N: Send on /BTtoMQTT/7C2F80C390FF msg {"id":"7C:2F:80:C3:90:FF","mac_type":0,"manufacturerdata":"80010215123480c390ffbbc5","rssi":-83}

And for the battery level it looks like this:

N: [ MQTT->OMG ]: {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","immediate":true} N: Send on /BTtoMQTT/7C2F80C390FF msg {"id":"7C:2F:80:C3:90:FF","service":"0x180f","characteristic":"0x2a19","read":"42","success":true}

[1technophile]

Thanks @kroman666 , is it sending always the same manufacturerdata or do you see changes over the time?

@DigiH makes sense, we could even auto detect the devices that have this pair of information and publish the battery level every X scans

[DigiH]

"80010215123480c390ffbbc5"

8001 - Gigaset Company identifier
123480c390ff - device MAC address with the first 4 indexes masked, I think ;)

we could even auto detect the devices that have this pair of information and publish the battery level every X scans

@1technophile even better :) and looking at all the other normative service/characteristics like Pulse Oximeter, Blood Pressure, Health Thermometer etc. it might be a good alternative to implementing connection decoders for specific devices in such categories by auto detection or presets for such device classes if they adhere to the standards and not implement their own.

[kroman666]

123480c390ff - device MAC address with the first 4 indexes masked, I think ;)

Good guess I think :)

I have 3 of those G-Tags and this grep always matches for all 3 of them:

grep 80010215123480c3....bbc5

we could even auto detect the devices that have this pair of information and publish the battery level every X scans

That would be perfect. If the interval for checking the battery level would be configurable it would be even better. Btw in practice e.g. 1 day is a good value for me.

I'm using this setup for presence detection to e.g. switch on the light when/even before the door opens. So it needs to be fast.

Sometimes I experienced this issue when reading the battery level (the code tag doesn't like newlines it seems):

N: BLE Connect begin lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) E NimBLEClient: "Connection failed; status=574 " E: Connect to: 7c:2f:80:c3:90:ff failed

I played a lot with parameters and I think it just happened with TimeBtwRead=0.
Sometimes also when asking for the battery level, OMG stopped to scan then.

Just wanted to say that with these setup it works quite well now:

'-DAttemptBLECOnnect=false' '-DScanBeforeConnect=1' '-DActiveBLEScan=false' '-DTimeBtwRead=5000' '-DScan_duration=1000' '-DBLEScanInterval=5000' '-DBLEScanWindow=1000'

while seeing this:

N: [ MQTT->OMG ]: {"ble_read_address":"7C:2F:80:C3:90:FF","ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","immediate":true} N: BLE Connect begin lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2) E NimBLEClient: "Connection failed; status=574 " E: Connect to: 7c:2f:80:c3:90:ff failed N: BLE Connect end N: Send on /BTtoMQTT/7C2F80C390FF msg {"id":"7C:2F:80:C3:90:FF","service":"0x180f","characteristic":"0x2a19","success":false}

If you have some recommendation for the parameters, I'd appreciate if you'd tell me.

Actually what I wanted to say is that if you implement to read the battery level in a controlled way, this should not happen anymore, right?

[DigiH]

I have 3 of those G-Tags and this grep always matches for all 3 of them:

grep 80010215123480c3....bbc5

so only really the difference in the last parts of their MAC addresses.

From going through its manual I found that other than being a presence beacon it doesn't have any other functionality like temperature etc. the only other thing I could think of, which would also affect the TimeBtwRead and Scan_duration setting is if it's possible to set the beacon broadcast interval? Just read that the broadcast interval is not configurable for the G-Tag, so I assume as with most other most beacons without that possibility it has a 2 sec interval.

Btw in practice e.g. 1 day is a good value for me.

I do the same for my Playbulb candles, but they don't leave the house ;) With a beacon like yours I'd get the battery level at least every 12 hours, so that most likely one of them at least would fall into a time when the beacon is at home. Or implement the battery level check only once at the first successful scan every new day?!?

If you have some recommendation for the parameters, I'd appreciate if you'd tell me.

I would leave the '-DScan_duration=1000' at its default 10000, as within these 10 seconds it's very likely that it catches the beacon braodcast - again, depending on the beacon broadcast interval questioned above and with the suspected 2 sec interval it should get scanned 4-5 times within these 10 seoconds.

The same with -DBLEScanInterval=5000, which defaults to 52 and -DBLEScanWindow=1000 with its default 30.

Actually, all I would adjust, and do for my beacons, which I use in a very similar way as you do, is

'-DAttemptBLEConnect=false' // even that could be left at true if you also have other ble sensors which need connections
'-DTimeBtwRead=5000' // or even lower if you prefer, as 5 seconds or below should be fine to switch on the lights when you come into the OMG_BLE gateway range.

[kroman666]

so only really the difference in the last parts of their MAC addresses.

from what I see from my 3 G-Tags, yes.

With a beacon like yours I'd get the battery level at least every 12 hours, so that most likely one of them at least would fall into a time when the beacon is at home.

I was thinking to fetch the battery level via MQTT when the beacon is at home and shortly after it reported to the server.

Or implement the battery level check only once at the first successful scan every new day?!?

That would be the better solution I think. Once a day is enough, the time doesn't matter. But still curious if problems I mentioned before could be avoided by doing so.

'-DAttemptBLEConnect=false' // even that could be left at true if you also have other ble sensors which need connections

Nothing else to do for my OMG currently, so I thought "false" is the better option.

With TimeBtwRead=5000, others at default, most of the time it takes ~15sec between detections.
It could be TimeBtwRead + Scan_duration?

Putting TimeBtwRead=0 it reduces to ~10sec.

Then with Scan_duration=5000 I'm achieving ~5sec which I will keep I think.

DBLEScanInterval and DBLEScanWindow I will keep default as you said.

Thank you!