We want to support continuous measurements with a configurable interval and time span,
e.g.
All measurements should be recorded in the database.
Note that at least with Mi Band 1S, the mobile must be connected to the band in order for this to work.
Actually, I though about my problem about accessing data from other app, actually, I want to graph the heart rate myself, but Gadgetbridge could graph this too and I think it would be simplier than giving access to other apps to data.
It's not only about the data sharing. Gadgetbridge could force Mi Band 1S to measure heart rate, which in turn could be obtained directly by third party app paired with 1S.
For example, switching on running mode in MiFit allows Endomundo to get heart rate data from paired 1S. The latter also get HR date when Gadgetbridge HR test activated.
Is this still in the works? It would be cool to have the Mi2 measuring heart rate 24/7 and not only during sleep, maybe in intervals like every 3 minutes or so.
I have been messing around with Mi2 continuous heart rate monitoring while "working" on issue 496. I'm teaching myself Android development, Java, bluetooth stuff etc in the process. No-one even remotely competent should wait for me to finish if they think they can knock something out or craft a masterpiece any time soon.
Thanks for the information. I'm glad that this is still sort of being worked on even if it takes some time... ;-) I didn't think about the live activity feature as it doesn't work while the screen is off (at least here). Would be cool to have the heart rate displayed in the same way as I've seen the Pebble 2 does (one value every few minutes, independent of sleep or activity).
I could also help, but first I would like to know how it should look like? Maybe there should be new view just for pulse monitoring? Where on one tab you can define interval etc, on second could be graph and actual value?
In my forked gadgetbridge you can find temporary implementation for continuous measurements which can be triggered from debug menu.
That is a great idea! A new view with two tabs would actually look pretty good, I guess.
@nephe: are you still interested in this? I played with your fork but it doesn't continue measuring after disconnect and reconnect.
I'm still interrested by this feature.
@girlwithnoname my current solution is rather fast workaround and can broke in some conditions. I am working on pulse service to provide better way for pulse measurement but I am not android developer so it can take a while.
@nephe Thanks for the information :)
@nephe if you need any help, just yell!
@nephe I forked and implemented your changes and worked great. I'm just trying to merge latest changes in upstream master onto that right now...
@cpfeiffer for continuous measurements with a configurable interval I need to schedule alarm or postDelayed runnable. Should this be done as separate service (pulseService) or added to DeviceCommunicationService?
@nephe Good question. Using the AlarmManager instead of a timer or postDelayed has the advantage that the OS will try hard to do it in a battery-friendly way, by combining the wakeup with those for other apps (since we do not need 100% accurate intervals).
I'm not sure who should be responsible for scheduling the alarms. This is certainly device specific, since some devices may support this by themselves, without any external triggers. Additionally it should only happen when such a device is actually connected.
I see 3 possibilities:
Following a DMCA takedown notice, we agreed upon removing this content from our issue tracker.
The counter notice is available here:
https://github.com/github/dmca/blob/master/2017/2017-06-20-MiBandTools-Counter-Notice.md
@cpfeiffer here's the log file I collected when moving mi band 1s out of phone's bluetooth range and back. At my first try the connection seems to have been picked up successfully, but the second attempt failed. The second try took place at around 17:42. HTH
Thanks for the log. What's happening is that you trigger a measurement once per second. Automatic reconnection will be happen within one second, it will take much longer. So automatic reconnection when being nearby the device will be irrelevant in this scenario.
The measurement while being disconnected will trigger an implicit connection attempt though (also once per second, which is way too much while being disconnected).
But even then it looks like reconnection did work after all!?
Seems like you're right... however, continuous heart rate measurement was not reenabled and no heart rate data was transmitted after that. Besides, when I checked the sensor it was inactive and the app's connection status was _not connected_.
I have created new method in ServiceDeviceSupport (onSetHeartRateMonitor) which delegates this method to DeviceSupport class.
I have created also HeartRateMonitorService in which based on configuration, alarms could be schedulded. This service is optional and should be only used by devices which does not support continuoues heart measurements by themselves.
I am working now on new activity for hear rate measurments.
Hello, I am looking for options to collect data series that can then be used for heart rate variability analysis. Therefore, I need a series of 100 to 500 beat-to-beat interval values. Is that something which is already possible with Gadgetbridge?
If it's not possible yet, is it worth incorporating into Gadgetbridge?
Any news regarding this feature? I would be glad to help testing if there's anything to test...
anyone solve the continuous heart rate problem?
Hi @tobiaszheller how do we successfully start continuous HRM with MiBand3? I read somewhere that we need to send x15x02x00 and x15x01x00 and x15x01x01 to the HRM CONTROL characteristic. And then listen to HRM DATA characteristic. However when I do that, app crashes. Can you at least show me where in the huge project is this process being done? My client is authorized with Miband3. whats after that for continuous HRM?
Most helpful comment
@girlwithnoname my current solution is rather fast workaround and can broke in some conditions. I am working on pulse service to provide better way for pulse measurement but I am not android developer so it can take a while.