So just as an experiment, I applied a quick hack to the health app on my watch to avoid the double-division to see what would happen. Toward the end of the day I got a daily summary “movement” value in the Health app of about 49. In the debug console I grabbed the log of hourly health data for that day and manually averaged it to compare:
and finally got a value that agreed with the written summary for that day, 49.41666666666. This is after making both code changes that I mentioned above, having the Health summary code read the correct byte of the record, and also not dividing the already-divided result when calculating and writing the summary.
I don't want to be too quick to assume things since I'm new here and don't know about all of the design decisions that might have been made, but so far this does seem to confirm my above suspicions. If it is a bug, I'm up to seeing if I can try to put together a pull request.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
So just as an experiment, I applied a quick hack to the health app on my watch to avoid the double-division to see what would happen. Toward the end of the day I got a daily summary “movement” value in the Health app of about 49. In the debug console I grabbed the log of hourly health data for that day and manually averaged it to compare:
and finally got a value that agreed with the written summary for that day, 49.41666666666. This is after making both code changes that I mentioned above, having the Health summary code read the correct byte of the record, and also not dividing the already-divided result when calculating and writing the summary.
I don't want to be too quick to assume things since I'm new here and don't know about all of the design decisions that might have been made, but so far this does seem to confirm my above suspicions. If it is a bug, I'm up to seeing if I can try to put together a pull request.