More info on the watch

[krzys-h]

Hey! This protocol looks awfully similar to a watch I got this Christmas. I already reverse engineered the thing a few months ago and have a mostly working Gadgetbridge implementation that I need to finally finish and send them a pull request:

• https://github.com/krzys-h/Gadgetbridge-MT863/blob/mt863/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/devices/dafit/DafitConstants.java
• https://github.com/krzys-h/Gadgetbridge-MT863/blob/mt863/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/devices/dafit/MT863DeviceSupport.java
• https://github.com/krzys-h/Gadgetbridge-MT863/tree/mt863/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/devices/dafit
• https://github.com/krzys-h/Gadgetbridge-MT863/tree/mt863/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/devices/dafit

From what I could figure out by analyzing the app, the company that makes these rebrands them hundreds of times with the same underlying protocol and firmware - you can find the complete list hidden in the app files (although it needs to be decrypted). The common thing seems to be the MOYOUNG or MOYOUNG-V2 string in the manufacturer name (that is also used as a protocol version).

Interestingly enough, the reverse engineering notes you are relying on were created before I even got my watch, but Google doesn't seem to return them for any combination of MOYOUNG and UUIDs I tried...

I just happened to be looking for the BTLE UUIDs it uses for something completely unrelated and found this repo ;)

[rogerdahl]

Your project looks awesome, thank you for that and the info! I hope you can get that PR done soon. My repo is still the only hit on GitHub for "uwatch2". Not even kabbi's shows up, unless doing the search from Google instead of from within GitHub.

I'm impressed with the firmware on the watch. The protocol is consistent and I've never had the watch crash even though sending it all kinds of broken stuff while working on the library. Not what I'd have expected from a $25 smart watch. What you say about it being common across many brands explains it.

[rogerdahl]

@krzys-h Is your fork of Gadgetbridge in a usable state? I thought I'd build it and give it a spin. If so, what should I expect to work and not work?

[krzys-h]

It is indeed usable and I've been using it for the last three months. Here is my current rough TODO list:

• It does seem to close by itself from time to time - I'm not sure if it's from crashing or some battery optimization thing kills it
• Features that are present in the protocol but not on my watch are not implemented (marked with (*) in this file). One of the most notable things is probably sending custom watch faces - my watch simply doesn't seem to support that, even in the official app.
• I never implemented starting single-shot blood pressure and oxidation tests (or displaying the results, although I'm collecting them in the database), no other watch in Gadgetbridge had that implemented so there was no UI for it
• I was playing around with how the past activity view is displayed since unlike other Gadgetbridge watches, this one does not directly report a direct "intensity" value, it does seem to work but you can see some glithes in the chart sometimes and I never fully verified that the values are correct. Also I never finished the code to correctly handle other Gadgetbridge watches.
• Oh, and the notifications sometimes display only who the message came from and not the message content itself but that's just the matter of fixing which values I take from the notification object. I can't believe I haven't fixed it yet, notifications are literally the only feature I care about :stuck_out_tongue:

I've never had the watch crash even though sending it all kinds of broken stuff while working on the library.

I did manage to get it to crash once - I think it was by doing requestMtu(256) and then sending a message with that size. I never managed to get MTU to work even though it's using the newer protocol version that's supposed to support it. The watch freezes for ~30 seconds after which some kind of watchdog reboots it. I've also seen some weird things happening to the battery indicator after that (it seemed to be a lot lower after every reboot - is it possible that the CPU was stuck in an infinite loop eating though the tiny battery like crazy? or maybe it's just that the reboot forces it to take a measurement again?)

Also, if you send weather ID > 7 you get random pixels in place where the image should be.

And about The protocol is consistent... umm... GOAL_STEP uses big endian for set and little endian for get. QUICK_VIEW_TIME and DO_NOT_DISTURB_TIME use (uint8 hours, uint8 minutes) for set and a single uint16 equal to hours*60+minutes for get. The sync time packet has a timezone field, but it's ignored and GMT+8 is always used no matter what you do. Yesterday and two days ago for steps and sleep are swapped to what they are supposed to be according to their names in the code (even in the official app it seems!). How is that consistent? :stuck_out_tongue:

[tmalone14]

Any chance you could provide an APK of your branch? I really like the uwatch, but I am not a fan of dafit.

Thanks for your work!

[icedman]

Custom Watchface works on P8!

https://github.com/icedman/uwatch2-client/tree/file-upload

This fork has some tools to decompile + compile a custom watchface, and an added command to upload the watchface to the watch. 1_compiled.bin is a sample custom watchface which I ported from an amazfitbip watchface.

To upload use 'f' command + filename of watchface:

f 1_compiled.bin

Issue: I'm sending packets on brute force - without check any acknowledgements. Sometimes dial is not updated after upload. I simply reset my bluetooth using hcitool (hci0 down, hci0 up). Or I reset the watch before trying again