InfiniTime
InfiniTime copied to clipboard
InfiniTimeOrg
"Find My Phone" functionality with Gadgetbridge
I used that feature quite a bit when i was daily driving my Miband. Not sure about what the best place to put it would be though. It doesn't justify being a full watchapp, but the quick settings are full.
Interesting feature, indeed! I think it would be nice to work together with the Gadgetbridge team to find the best BLE API for this functionality. Then, this feature could also be added in other companion apps like Amazfish and Siglo :)
This is one of the features I miss most after moving to a FitBit a while back, so I'd love to see this too! As for interface, it would kinda make sense long-pressing the vibration option on the quick settings screen, but that probably shouldn't be the only way to do it at least, since it's not very discoverable. And I'm not sure if long-pressing quick settings is something that's desirable to introduce in the first place.
I used that feature quite a bit when i was daily driving my Miband. Not sure about what the best place to put it would be though. It doesn't justify being a full watchapp, but the quick settings are full.
As a Mi Band User , I cant exaggerate how MUCH I use this , kind of fun too it disturbs everyone!
I also switched to infinitime from the mi band and enjoyed this feature, if I find the time, perhaps I will look into it from the gadgetbridge side...
On 1.9.0 this is working flawlessly for me and appears as a call from GadgetBridge. Anyone still having hiccups with this feature? Or should the issue be closed?
You got it wrong, what you're showing is 'find my watch', in some other smartbands there is an option to make the phone start ringing and gadgetbridge has support for this.
There's actually a Bluetooth profile for this: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=239389
I think it would be wise to implement the standard, so rather than require phones to have specific Infinitime support for this, they just need to support the standard.
Also relevant: https://www.bluetooth.com/specifications/specs/find-me-profile-1-0/
No need to rely on this hard-to-implement Bluetooth spec. GadgetBridge already has a device event for that: GBDeviceEventFindPhone
In order to get it working on InfiniTime, you'd need to:
- Add new UID for a new service in PineTimeJFConstants.java:
UUID_SERVICE_INFINITIME. Alternatively, we could add a service to emulate UART over BLE. See nRF documentation and WASP-OS's implementation in GadgetBridge. - Register this new service.
- Modify
onCharacteristicChanged()to add support for two new characteristics:UUID_CHARACTERISTICS_FIND_PHONE_STARTandUUID_CHARACTERISTICS_FIND_PHONE_STOP. Or just one characteristic with a value defining whether it stops or starts the find device functionality. - Register these characteristics.
- Forward the event to GadgetBridge:
value = ...
GBDeviceEventFindPhone deviceEventFindPhone = new GBDeviceEventFindPhone();
deviceEventFindPhone.event = value ? GBDeviceEventFindPhone.Event.START : GBDeviceEventFindPhone.Event.STOP;
evaluateGBDeviceEvent(deviceEventFindPhone);
Then you would need to implement the new device event service + a button or an app in InfiniTime to use this new capability.
No need to rely on this hard-to-implement Bluetooth spec. GadgetBridge already has a device event for that: GBDeviceEventFindPhone
The huge downside of this approach, is that the feature would work with a single application (GadgetBridge), on a single OS family (Android). I can't imagine anyone willing to implement this custom GadgetBridge API for that on Linux mobile, given that a standard bluetooth spec exists for the exact same purpose.
Following a standard spec means far wider devices support, and more chances of it working on other devices and vendors.
What's the motivation for GadgetBridge to implement their own custom protocol, instead of using the bluetooth standard?
@WhyNotHugo This spec is over-engineered and a pain to implement. It's several orders of magnitude more time-consuming and a lot more frustration than just implementing it in a few limes in GadgetBridge.
Also just the fact that it's a standard doesn't mean that it would automatically work everywhere. I'd be surprised if it were implemented in the devices you mention.
This said, be my guest if you want to implement it by yourself.
There's actually a Bluetooth profile for this: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=239389
~~Wrong Bluetooth.~~
I think it would be wise to implement the standard, so rather than require phones to have specific Infinitime support for this, they just need to support the standard.
There's the Immediate Alert service but no OS supports or has that natively.
No need to rely on this hard-to-implement Bluetooth spec.
IA is not difficult to implement though.
In order to get it working on InfiniTime, you'd need to:
It's just as much work to implement IA.
The huge downside of this approach, is that the feature would work with a single application (GadgetBridge), on a single OS family (Android).
It wouldn't.
Following a standard spec means far wider devices support, and more chances of it working on other devices and vendors.
As mentioned above, nope.
What's the motivation for GadgetBridge to implement their own custom protocol, instead of using the bluetooth standard?
They haven't.
It's several orders of magnitude more time-consuming and a lot more frustration than just implementing it in a few limes in GadgetBridge.
Not really. You're already implementing 98% the same as implementing IA, 1% being the different UUID.
I'd be surprised if it were implemented in the devices you mention.
It even might be, it is implemented quite often on wearables themselves. The catch is that it rarely works as intended. Doesn't mean IT can't be compliant though.
I'm not interested in addressing your points. I think they are misguided but this discussion is unproductive and I'd rather dedicate my time to implement it.
@devnoname120 If you are going to spend time implementing something, it would be very reasonable to actually get acquinted with the actual standard before dismissing it.
@JF002 curious if this is something that might get some attention? I would love to be able to do that with my pimetime!
I see it's already a feature on gadgetbridge for other devices as mentioned (related issue https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/2967 )
I think someone just needs to program a button to do it at this point. That person could be you.
@TechnologyClassroom I wonder if that's true... and how to program a button.
Assuming all that hubbub about bluetooth vs GadgetBridge feature is true it seems using GadgetBridge is probably easier.
It looks like it requires paring via the Companion Device Management to use that feature - anybody know how to find out if Infinitime pairing with GadgetBridge is currently using that?
Seems like the first step...
@TechnologyClassroom while your hypothetical is compelling, I think it would take me a while to learn enough python (i think?) to add a button... I will consider it for a new year's resolution though :P
EDIT: hrm... seems maybe it's written in C++ - I did do some C++ in highschool :P
I am still very interested on this feature even 2 years after i bought my watch :)
This issues is a bit of a chicken-and-egg situation.
An implementation is needed on the watch side (the "Locator"), and an implementation is also needed on the phone/laptop side (the "Target"). I don't think that it's feasible to test one without the other.
I have written a tiny "Target" implementation using bluer: https://git.sr.ht/~whynothugo/find-my-tux. It works on Linux desktop or mobile (or laptop). For the moment it just prints "Got an alert", but once there's a "Locator" implementation for InfiniTime I can refine this to execute a user-configurable command.
Supporting other platforms (e.g.: BSD) is non-trivial, given that the entire Bluetooth software stack is different. An entirely different implementation is required.
As you might have guessed, this is pretty untested, given the lack of a "Locator"/watch implementation. If someone else wants to pick this up, I'd be very happy to test the InfiniTime changes. These are the relevant specs:
- Find Me Profile 1.0: https://www.bluetooth.com/specifications/specs/find-me-profile-1-0/
- Immediate Alert Service 1.0: https://www.bluetooth.com/specifications/specs/immediate-alert-service-1-0/
- The assigned number for Immediate Alert Service is 0x1802.
The whole profile is just one service with a single characteristic; it's exceedingly simple. The "Locator" implementation only needs to execute a "Write without Response" with the correct alert level on the "Target".
By the way, ImmediateAlertService is already implemented in InfiniTime https://github.com/InfiniTimeOrg/InfiniTime/blob/main/src/components/ble/ImmediateAlertService.h but it seems it is from phone to watch
