#1791 Declaring capabilities not always available

Open
opened 3 weeks ago by TaaviE · 2 comments
TaaviE commented 3 weeks ago

I have described this issue before, but I'd really love solving this.

The issue is that if a DeviceSupport class declares a capability but devices across firmware or hardware revisions lack it, GB will continuously try to read the characteristic, fail in doing so and then initiate reconnection. This is not exactly ideal.

How could GadgetBridge be altered to allow a device support class to be more universal and handle errors related to reading characteristics?

I have described this issue before, but I'd really love solving this. The issue is that if a DeviceSupport class declares a capability but devices across firmware or hardware revisions lack it, GB will continuously try to read the characteristic, fail in doing so and then initiate reconnection. This is not exactly ideal. How could GadgetBridge be altered to allow a device support class to be more universal and handle errors related to reading characteristics?
ashimokawa commented 3 weeks ago
Owner

fail in doing so and then initiate reconnection

Where exacly, any example?

I was not aware that reading errors will be fatal.

You do have access to the firmware version, and can do various checks, but in any case errors should not be fatal.

> fail in doing so and then initiate reconnection Where exacly, any example? I was not aware that reading errors will be fatal. You do have access to the firmware version, and can do various checks, but in any case errors should not be fatal.
TaaviE commented 3 weeks ago
Poster

@ashimokawa

Where exacly, any example?

The prerequisite is that reconnection is enabled. In my case this is one of the iTag devices, it seems to really dislike reading the battery status and then terminates the connection. Then it reconnects and the cycle repeats. So it'd be a nice to have a per-device way to disable checking battery status before a connect, is there a way?

One other device will disconnect with 133 (GATT_ERROR) when the button press UUID is attempted to be read. They're all annoyingly unique but should do literally the same.

You do have access to the firmware version

As far as I can see there's only “Generic Access” and “Generic Attribute” and on the eight iTag devices I have, none have a way to determine any firmware version.

There's also other oddities I've noticed, maybe you've got any ideas:

  • One device starts disconnecting with GATT error 61 (MIC failure) after some indeterminate amount of restarts, a re-bond seems to be necessary to fix that. I am wondering, is there a way to hint to the user that it has to be done from a device support class? This will also cause a reconnection loop, that in this specific case cause the device to beep continuously (because the disconnection triggers the device's disconnection alarm) and thus run out of battery.

  • One other device disconnects randomly with GATT error 8 (GATT_CONN_TIMEOUT), other than reconnection I don't know how to fix that. Any suggestions?

@ashimokawa > Where exacly, any example? The prerequisite is that reconnection is enabled. In my case this is one of the iTag devices, it seems to really dislike reading the battery status and then terminates the connection. Then it reconnects and the cycle repeats. So it'd be a nice to have a per-device way to disable checking battery status before a connect, is there a way? One other device will disconnect with 133 (GATT_ERROR) when the button press UUID is attempted to be read. They're all annoyingly unique but should do literally the same. > You do have access to the firmware version As far as I can see there's only "Generic Access" and "Generic Attribute" and on the eight iTag devices I have, none have a way to determine any firmware version. There's also other oddities I've noticed, maybe you've got any ideas: * One device starts disconnecting with GATT error 61 (MIC failure) after some indeterminate amount of restarts, a re-bond seems to be necessary to fix that. I am wondering, is there a way to hint to the user that it has to be done from a device support class? This will also cause a reconnection loop, that in this specific case cause the device to beep continuously (because the disconnection triggers the device's disconnection alarm) and thus run out of battery. * One other device disconnects randomly with GATT error 8 (GATT_CONN_TIMEOUT), other than reconnection I don't know how to fix that. Any suggestions?
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.