Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Mi Band v1.1] (with white LEDs) does not initialize #136

Closed
computerlyrik opened this issue Oct 4, 2015 · 56 comments

Comments

Projects
None yet
6 participants
@computerlyrik
Copy link
Contributor

commented Oct 4, 2015

App says
"paring"
or "initialize" inside overview.

...forever.

Miband gets paired in USB settings and SmartLock asks me about new BT Device for auth.

But Miband does not vibrate or blink to show pairing success.

Both - App from F-Droid and fresh checkout from source.

Want to develop for Mi Scale and Mi Yeelight, but failing at the first steps. Any development guidelines or architecture diagrams out there?

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

When paring manually (via BT Management) following error appears in log of app (when tapping miband => connect):

10-04 14:41:04.978 32177-32588/nodomain.freeyourgadget.gadgetbridge D/nodomain.freeyourgadget.gadgetbridge.service.btle.BtLEQueue: characteristic write: 0000ff05-0000-1000-8000-00805f9b34fb (failed: 133)
10-04 14:41:04.979 32177-32588/nodomain.freeyourgadget.gadgetbridge W/nodomain.freeyourgadget.gadgetbridge.service.devices.miband.MiBandSupport: Could not write to the control point.
10-04 14:41:04.979 32177-32588/nodomain.freeyourgadget.gadgetbridge I/nodomain.freeyourgadget.gadgetbridge.service.devices.miband.MiBandSupport: handleControlPoint write status:133
10-04 14:41:04.979 32177-32588/nodomain.freeyourgadget.gadgetbridge I/nodomain.freeyourgadget.gadgetbridge.service.devices.miband.MiBandSupport: handleControlPoint WROTE DATA:0x       f
10-04 14:41:04.980 32177-32588/nodomain.freeyourgadget.gadgetbridge I/nodomain.freeyourgadget.gadgetbridge.service.devices.miband.MiBandSupport: handleControlPoint WROTE DATA:0x       0
10-04 14:41:04.980 32177-32588/nodomain.freeyourgadget.gadgetbridge D/nodomain.freeyourgadget.gadgetbridge.service.btle.BtLEQueue: failed btle action, aborting transaction: 0000ff05-0000-1000-8000-00805f9b34fb (failed: 133)
@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

Firmware Version (from original Miband App) : 5.15.8.21

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

Is MiFit running while you do this? You have to quit it, or disconnect if possible.

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

MiFit - Band disconnected and killed via App-Manager

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

The firmware version is completely unknown to me. We know about versions 1.0.9.x and 1.10.x.

Never heard of 5.x. If that's indeed the firmware version, you might try downgrading to one of the supported versions (see the wiki).

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

Also: which phone is this, and does MiFit properly work with it?

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

SW/HW: http://get.cm/get/jenkins/128662/cm-12.1-20151004-NIGHTLY-d802.zip (upgraded from snapshot 20150903 yesterday because i wanted to make sure, it is no temporary bug)
D802 = LG G2

Mi fit works totally.

My Band has NO led-color change ability. Just "Apple"-White lights. Could be a newer version?

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

The Mifit App did an firmware upgrade few days ago. Firmware before was 5.15.7.2

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

I really want to debug and develop some features, but i do not know

  • bluetooth - only basics
  • the application architecture - i am more the web-app-guy
@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

Could it be that 5.x is Mi Fit version instead of MiBand firmware version?

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

Settings -> Mi Band -> Firmware version (really far below the "Locate"-Setting)

Mi Fit is v 1.6.122

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

http://en.miui.com/thread-162761-1-1.html
New Band released Aug, 16 - only white leds

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

Just for the record: looks like there are problems with the LG G2 and the Mi Scale: http://www.android-hilfe.de/thema/app-mifit-deutsch-immer-aktuell.652763/page-26

Could you create a bluetooth hci dump when connecting with Mi Fit? Then we might be able to find out what's different wrt the older Mi Band.

@danielegobbetti

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

Oooh that's interesting!

Your miband seems indeed a completely different beast than the older one, even though apparently only the led color changed.

What I noticed from your log is error 133 from the Bluetooth stack. This usually means too many connections are being made to the device. Could you somehow arrange trying to connect to the device without the original app installed? Ideally after a reboot?

A word of warning, do not install firmwares to this miband hw with gb (assuming you manage to connect).

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

@cpfeiffer: Mifit App works wonderful with my G2 and Mi Scale.

@danielegobbetti: while Debugging, it runs my Breakpoint in ble-service two times each gui-touch. Could not dig deeper, due to my lack of understanding the code :/

@cpfeiffer : github will not accept my btsneep_hci.log file - where to upload?

@danielegobbetti thanks for Warning

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

You could try http://pastie.org/ for example.

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

@cpfeiffer it's a binary blob, can be opened with wireshark

http://www.file-upload.net/download-10952076/btsnoop_hci.log.html

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

That upload didn't work, it's 0 bytes long. With hcidump you can convert it to plain text.

@cpfeiffer cpfeiffer changed the title Miband does not initialize Mi Band (with white LEDs) does not initialize Oct 4, 2015

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

BTW, you could try commenting two lines in MiBandSupport.java: line 95 and 96 like this:

//                .setWearLocation(builder)
//                .setFitnessGoal(builder)
@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

breakpoint on pair(builder) not hit.

did not figure out how to convert file with hcidump -
give it another try http://www.filedropper.com/btsnoophci
retested.

@computerlyrik computerlyrik changed the title Mi Band (with white LEDs) does not initialize Mi Band (with white LEDs v1.1) does not initialize Oct 4, 2015

@computerlyrik computerlyrik changed the title Mi Band (with white LEDs v1.1) does not initialize [Mi Band v1.1] (with white LEDs) does not initialize Oct 4, 2015

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

Thanks, that worked.

hcidump -a -r btsnoop_hci.log > ascii.log

Pairing will only be performed through the (initial) pairing activity, not through normal connect.

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

Did you configure Gadgetbridge with (any) user info? Mi Band needs user info (nick, age, weight, ... in the settings).

It could be that Mi Band thinks it is already paired and now Gadgetbridge wants to connect, but lacks user info.

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

@cpfeiffer was in my mind too - one or two times, i filled out completely. but the other 137 times i used dummy data.

I do have a second miband with the FW mentioned #136 (comment)

This did also not work - and has never been paired before.
In the mean time, i also paired the second miband with mifit app (but did no fw upgrade).

I tried both - 1.6.538 and older 1.6.122 app. Both work with both bands. btw..on two devices (phone/g2+tablet/nexus 7 cyanogen))

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 4, 2015

@cpfeiffer is there any possibility to write a test to try the pairing process only on backend? how can i dig into a component-testframework for the app?

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

OK, time for some "history":

  • my original Mi Band with FW 1.0.4.3 did not support bluetooth-level pairing at all. It only had an application level bonding. Because of this Gadgetbridge does not attempt to perform a bluetooth-level pairing for Mi Bands.
  • with a newer FW, my Band does support bluetooth-level pairing, so this is what I did, using the Android bluetooth dialog.
  • additionally, Mi Band still has the application-level bonding, as well as an explicit "pair" characteristic (in BLE speak). The use the latter in Gadgetbridge's pairing activity, when you connect the device for the very first time.

So, if it all works the way I remember, you have to do these steps:

  1. perform a bluetooth-level pairing
  2. search for the device in Gadgetbridge and invoke the pairing activity. This should also ask you to configure user info -- you must enter something there.
  3. when you then connect, it should perform the pairing with blinking LEDs which you have to confirm by tapping a few times onto the band.
@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

Regarding component testing: this could be easy, although we do not currently have device-level tests. Have a look at GBApplication.deviceService(). You can call connect() with the MAC address (upper case!) and performPair = true.

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

You could also have a look at the Debug activity for easy click-testing of features.

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 4, 2015

I read that it might take minutes, but this never happened to me.

@platinumthinker

This comment has been minimized.

Copy link

commented Oct 7, 2015

my device repeat the this situations

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2015

So did you manage to connect with Gadgetbridge at all?

@sarg

This comment has been minimized.

Copy link
Contributor

commented Oct 17, 2015

I looked into device discovery code, and found that you determine device by its name:
if (btDevice.getName() == null || btDevice.getName().equals("MI"))

I have newer version of device (the white leds one), and it's name is MI1S. So, your MI check will be false. Maybe you should test for btDevice.getName().startsWith("MI")? Otherwise DeviceSupport will be null and no pairing will be performed.

I digged inside of xiaomi app, and found that it filters discovered devices by service UUID. I think that functionality could be implemented in GB.

Also, cool project! Definitely would contribute to it.

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 17, 2015

Thanks for the pointer! This check is indeed bad and I knew it would bite us somewhen. Current MI Band firmwares actually support real bluetooth pairing, and this code is a relict from times where the band did not pair.

The correct solution would be

  1. to get a list of all available and all paired devices
  2. to ask all DeviceCoordinator classes whether they support each device
  3. display all devices for which support was signaled

Checking for support would then either check for services as you suggest, or, at least for known device mac addresses.

We actually have some infrastrcture for this, see DeviceHelper (for an abstraction over all available DeviceCoordinators) and its isSupported() methods.

The discovery activity actually makes use of that, just the ControlCenter activity does not. Its code needs some cleanup, I suppose.

With some help/feedback, we can surely get the MI1S supported in little time.

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 17, 2015

@sarg Can you check whether your MI Band's MAC address starts with 88:0F:10? Only then would the discovery activity display it (see MiBandCoordinator#supports()).

cpfeiffer added a commit that referenced this issue Oct 17, 2015

@computerlyrik

This comment has been minimized.

Copy link
Contributor Author

commented Oct 18, 2015

My Band says:

Name: MI1A
MAC: 88:0F:10:D1:**

There has been a App and Firmware-Upgrade yesterday: 5.15.10.9

@danielegobbetti

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2015

Just a warning: assuming you managed to connect and gb talks with the new miband, the firmware update procedure will happily let you flash the firmware of the old band to the new one, and this is probably very bad for the band and should be avoided! (I guess there are safety measures in place on the band itself, like the checksum is different or hw version checks, but our code is pretty simple and only check if a single byte has a specific value).

Having said that, it'd really cool to add support for the new band, thanks! :)

@sarg

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2015

Ok, I changed sendUserInfo a bit, and successfully paired with MI1A.
MI1A expects some data from DeviceInfo to appear in UserInfo.

    sequence[9] = (byte)(deviceInfo.feature & 255);
    sequence[10] = (byte)(deviceInfo.appearance & 255);

I suggest we make MiBandSupport aware of fw/hw version of device, so it can choose correct communication protocol.

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2015

Awesome! I will have a look at this in the evening.

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2015

The question is, how do we know the fw/hw revisions before connecting? :-?
I hope we can check that when connected without sending user info in advance.

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2015

BTW, what's your hw revision?

@sarg

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2015

@cpfeiffer 5.15.10.9
Also, check my pull request. There you will find answer for your question :)

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2015

+1, great job! So what's the status now with Mi Band 1A? Does it sync activity data? Does it support notifications? What's left to do?

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2015

BTW, we're about to release a new version today. If there's anything left for 1A support, we can either add this before the release, if you think you/we can fix it in short time, or we'll do it for the next release.

@cpfeiffer cpfeiffer added the device mi label Oct 18, 2015

cpfeiffer added a commit that referenced this issue Oct 18, 2015

@sarg

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2015

@cpfeiffer Hi again, fixed small bug in DeviceInfo checksum. (comparing signed vs unsigned bytes).
Current status: 1A pairs, syncs activity, vibrates when clicking buttons in "Debug" activity. "Find lost device" function does not work.

@sarg

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2015

"Find lost device" for MI1A should use UUID_CHARACTERISTIC_ALERT_LEVEL.

@danielegobbetti

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2015

@sarg @cpfeiffer the same is true for the latest firmwares of the old miband, I forgot to change it when adding support for notifications.

@danielegobbetti

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2015

I believe the byte 'firmwareVersionMajor' (see https://github.com/Freeyourgadget/Gadgetbridge/blob/master/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/devices/miband/MiBandFWHelper.java ) could identify the compatible hardware revision.

@sarg can you please check if my speculation is true? (If you have the official app that brought your band to the current firmware, you can extract the fw from it and check if the bytes at the positions you read in the fwhelper class match)

@sarg

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2015

@danielegobbetti

❯ dd if=assets/Mili_1a.fw skip=1056 count=4 bs=1 status=none | hexdump -e '/1 "%02X "' 
09 0A 0F 05
❯ dd if=assets/Mili.fw skip=1056 count=4 bs=1 status=none | hexdump -e '/1 "%02X "' 
06 0B 00 01
@danielegobbetti

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2015

Good to know, we can tie the firmware to the right hardware then!

Thanks!

Il 19 ottobre 2015 20:17:08 CEST, Sergey Trofimov notifications@github.com ha scritto:

@danielegobbetti

❯ dd if=assets/Mili_1a.fw skip=1056 count=4 bs=1 status=none | hexdump
-e '/1 "%02X "' 
09 0A 0F 05
❯ dd if=assets/Mili.fw skip=1056 count=4 bs=1 status=none | hexdump -e
'/1 "%02X "' 
06 0B 00 01

Reply to this email directly or view it on GitHub:
#136 (comment)

@satdxler

This comment has been minimized.

Copy link

commented Oct 21, 2015

hello,
I always have this new version of the mi Band with white LEDs only.
The firmware version is: 5.15.10.9
OpenBand ist able to check the battery status and firmware version, the rest doesnt work
and also your app, I prefer, is able to pair, then tries to connect and the connection abortet, after the H/W or F/W Version is unkown
How can I help you to support the newest versions?

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 21, 2015

@satdxler Did you compile Gadgetbridge yourself from git or do you use the version from f-droid? The current version from git is supposed to work better, see sarg's comment: #136 (comment)

If you can't / don't want to compile yourself, please be a little patient, we're going to release a new version in the next days.

cpfeiffer added a commit that referenced this issue Oct 21, 2015

Make "Locate device" work with newer firmware and MI1A. (#136)
Separate the different notification logic into distinct strategy classes.
@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2015

I think we can close this issue now. Mi1A should be reasonable supported now. If there's still anything missing, please open a new issue.

@cpfeiffer cpfeiffer closed this Oct 22, 2015

@cpfeiffer

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2015

Forgot about firmware update. Let's create another ticket for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.