Their API doesn’t discriminate between time in bed and time asleep, which makes the data a lot less useful, so we’re leaving this closed for now.

What do you mean time in bed and time asleep? are there any sleep trackers that distinguish between the two?

@rotemraviv I’m not sure about mobile apps as we haven’t tested many, but all the device trackers like Fitbit, Jawbone UP, Misfit, Withings etc track both. The difference is that “time in bed” is just the duration from when you turn the app on, to when you turn it off again in the morning. Time asleep is the period you were actually asleep (or at least a good guess at it based on noise and movement) which is often a lot less because of the time it takes to fall asleep, any time you woke up during the night, etc. The issue here is Sleep as Android does not track time awake, so it’s technically reporting in its data “you were asleep from as soon as you turned on our app to the time you turned it off again”.

@joshsharp I understand what you mean. It does tell the difference from when you are lightly sleeping as opposed to deep sleep, but it might not show that in the API. The only thing that bothers me is that there are no other apps that have an API and are good on Android Wear watches, so I am stuck with absolutely nothing to use.

@rotemraviv as far as I remember there is light sleep in the API, but that’s not good enough for me ;) all the others track awake time separately to light sleep. I sympathise though, sorry there’s no good solution! I think we’ll try to add Google Fit sometime soon, which I believe they export to. So even though the data isn’t nearly as useful, you’ll have the option of using Sleep as Android via Fit when that’s done :)

Google Fit won’t have the percentage of good sleep though, right?

@rotemraviv right, it won’t be any better, but seeing as we’re adding Google Fit in general, it does give you the option to use that data while we still avoid supporting them explicitly or having to deal with their API. Compromise :)

Thank you!

Subscribing to this in case it changes. I find this interesting: “you were asleep from as soon as you turned on our app to the time you turned it off again” because this is actually one of the few apps I’ve found that has a countdown timer to let you actually fall asleep. I use that because I have a spouse and dogs that sleep with me in bed, so the movement tracking of “sleep” is never accurate to when I’m actually asleep. Anyway, just wanted to voice that I really hope there’s something that works for this app at some point! :)

@danlefebvre2 interesting, I’m curious — if you know the tracking of your sleep based on movement is inaccurate, what do you get out of sleep tracking this way? Do you use it solely as a “time in bed” tracker so you know for how many hours you were potentially asleep?

@joshsharp Yeah, pretty much what you said. I don’t track based on movement, because any movement-based tracking is always inaccurate. I only track the amount of time I’m asleep and not the light/deep sleep cycles. It’s a best estimate, sure, but it tends to be more accurate (I think, at least) than any other method I’ve found of tracking sleep. For example, I don’t use my FitBit to track sleep because it starts tracking as soon as I tap it. But like most people I usually don’t fall asleep as soon as I hit the pillow. So I use the countdown timer to give myself 15-20 minutes to fall asleep.

On the other side it works well, too, because Sleep as Android is my alarm. So it stops tracking when the alarm goes off. I found I’d often forget to tell my FitBit I wasn’t sleeping anymore, so it’d be in sleep mode for the first few hours of my day.

Sad this isn’t possible, but oh well. Voted just in case it ever might become possible as I use this app every day and have done for years now.. :)

Gotta be a way to get this to work.

@pedrorodriguez14 Bump.

If you’d like to see this added, please just vote it up — comments that are the equivalent of “I want this” just add noise and make it harder for us to keep track of and respond to actual discussion :) and unfortunately the mismatched data situation hasn’t changed and is unlikely to.

This post is inspired by a conversation happening on the GFit card, but since it’s really about Sleep as Android, I’m posting it here.

I guess I’m just having difficulty understanding why Sleep as Android’s (SAP) data is “bad” (or objectively worse than sleep data from any other tracker). Having now used three sleep trackers (Beddit, Withings Aura/Sensor, and SAP), I can say confidently that it is not the worst data out there. That award goes to data recorded by the Withings Aura, which records throughout the night on some days and, on others, just stops recording mid-sleep. And for the life of me I can’t figure out how to delete any of these records (I can delete them on the mobile app, but they remain on the web app as well as on Exist). The Beddit sensor worked really well (and was relatively inexpensive), but only syncs with Exist via Misfit, so excludes anyone outside of that ecosystem. So whatever sleep data I’ve synced with Exist has been from Withings and about 50% of that data is (wildly) inaccurate and, thus, imho, worse than anything from SAP.

Also, @joshsharp, you said that SAP doesn’t differentiate between “time in bed” and “time asleep, but that may only be the case for those who use it via the stand-alone mobile app. I know that if you use SAP with a device that has a HR sensor (I use it with a Moto 360), it tracks your heart rate for “automatic awake and REM detection.” (I can attest that SAP records my awake time throughout the night, and does so more accurately/consistently than Withings had. And SAP has many more features and ways to interact with your data than the other sleep trackers I’ve used. I highly recommend it to anyone with a partnered wearable. But I digress.)

So is the issue that SAP’s API simply doesn’t export data that reflects a distinction between in bed/asleep or that not all users are recording the same quality of data? If the former, do you think this is something we/I could lobby SAP to change/improve (I have no idea what API even stands for, much less how they work)? If the latter, is SAP’s data really any worse than Withings’ (I assume Withings Pulse users don’t have the same issues as Withings Aura/Sensor users)?

Sorry for the long post, but sleep data is, to my mind, one of the more useful QS outputs available and I was hoping that once the GFit integration was live, SAP data would also be integrated (@joshsharp, you seemed to suggest this in a previous post).

M

p.s. I love Exist. Keep up the good work.

Hey @elmcityfree, thanks for the post. I totally get that you want to get sleep data into Exist, and you’re frustrated that you can’t. Let me try to explain.

The main issue, as I tried to explain earlier in the thread here, is that when I was testing Sleep as Android by using the app, without a device, it seemed to track the entire period from “I’m starting to track my sleep” to “I’ve turned off the app” as time asleep. We track this as time in bed, with time asleep as a separate number, and to my mind there’s a big difference — being in bed is not necessarily being asleep. (As a side note, I wasn’t aware it integrated with any devices — can the Moto 360 do sleep tracking on its own, directly into Google Fit, or is this specifically a SaA integration with Google Wear?) Anyway, the point is we made a judgement call that because all we could tell the user was a time in bed period, not how long they’d actually slept, the data was not good enough. It’s inconsistent with the data we get from every other integrated service. And having looked at the API docs again, the types of events it tracks do not include “awake during sleep” so it seems if it can track your awakenings via your watch, Mike, it can’t tell us about them :( So possibly, part of the issue is that the API doesn’t return the entire data it has access to. I could be wrong, but that’s how it looks to me. (Someone else mentioned, I think, that we could use the “light sleep” it reports as “time awake” but light sleep is light sleep, not being awake. That’s not going to fly.)

It’s funny that you mention Withings because we’ve had a bunch of users with issues with its data as well. If I had my time again, I’d only integrate Withings for weight and heartrate, excluding the activity tracker data, because it just isn’t very good! But now we have it, we’re stuck with it. We’re forced to maintain it because it would upset users to take away a source of data, even a bad one. Having been in that situation once already, I’m loath to integrate another service that doesn’t seem up to scratch. By doing so we’re implicitly telling users, “this service is good, we endorse it, you can use it without worry”. But I don’t want to endorse dodgy data that will bring us issues from users who want to know about their time asleep, and don’t understand why Sleep as Android can’t provide that like every other sleep integration. You know that phrase “Garbage In, Garbage Out”? Bad data leads to more bad data — in this case bad averages, bad insights and correlations, etc etc. I kinda feel like I’m the Knight of Good Data, sworn to defend Exist’s lands and people from the evil Incorrect Numbers… I take my duties seriously.

Here’s what I propose. (I’ll cross-post this to the Google Fit card for those following along there as well.) Google Fit integration is going to land this coming week as it’s ready to go, sans sleep. Once you and others who also use it for sleep tracking have it connected, with your permission I’ll use your real sleep data as a test to see what SaA’s data looks like once it’s been sent to Google Fit. If it seems to work, and we can reliably track bedtime, wake time, and a duration of time actually spent asleep, I’ll go back and add sleep tracking via Google Fit too. That’s totally fine with me, I’ll be stoked to get the data in there if it works. If we can’t get all that we’re after, I’ll update Trello with the specifics and we’ll decide if getting some data is better than no data. How does that sound?

@joshsharp, thanks a lot; that sounds great!

re: Moto 360, no I don’t think it does sleep tracking on its own; SAA uses its heart monitor and accelerometer as I understand it.

p.s. in have no idea why I was abbreviating that as SAP; I meant SAA. (>_<)

@joshsharp I admittedly haven’t actually tested the SAA API, but this doesn’t jive with my understanding of the data I’ve seen in my SAA backups (Google Drive).

Every sleep record has to and from timestamps that is equivalent to the ‘time in bed’ that you are looking for. The API docs you linked may also be out of date/incomplete. I noticed that I have an ‘AWAKE_START’ event that would provide the other piece of data you are looking for. Generally speaking I’ve found the data I get from SAA to be the most consistent and reliable – it’s using a lot more sensors as inputs than your standard sleep tracker.

Please let me know if there is anything I can do to help out on this integration.

@matthewkelch Yes, Sleep as Android tracks time in bed. It has start and end times. The issue is that it does not discriminate between “time in bed”, ie. from hitting start at bedtime until hitting stop in the morning, and “time asleep”, ie. the time you actually spent sleeping, which should always be less than time in bed. It doesn’t seem to account for awakenings via the API, either as a quantity or as a period, and has no value that corresponds to “awake time”, only different types of sleep. Basically all it’s good for is tracking “I was in bed from this time until this time”. If they do record periods of being awake, then they need to update their API to reflect that! It may be recent because when I tested this to work on the integration I couldn’t see this, only “light sleep” when I was actually awake. Not good enough.

If you’d like to see this happen, you’re more than welcome to talk to Urbandroid and write a Sleep as Android integration for Exist — I’m happy to give you help with our API, etc as needed.

@joshsharp Thanks for the reply, I’ll reach out to you via email.

@joshsharp Hi, Urbandroid team here. I was approached by one of Exist.io users and made aware of this Trello board. I have added the needed information in our API documentation page. Especially the awake event labels (there are two kinds of them - awake events detected by an awake detection algorithm and awake events triggered by user action).

See the docs here: http://sleep.urbandroid.org/documentation/developer-api/sleepcloud-storage-api/#event-labels

@jiirichter thanks for updating your docs. I’ll take a look and reevaluate if we will decide to integrate Sleep as Android.

Hi, any changes in plans for this integration?

@alexanderlindemann2 not at this stage.

Hi Josh - Jiri from Urbandroid again. Did anything change? We are interested in integration with Exist.io. Is there anything we can change in our API to be compatible with Exist? I see that you have put this integration into “Not possible” bin – why is that? Many thanks Jiri Urbandroid Team - Sleep as Android

Hey Jiri, I’ll take a look at this again soon and see if it’s feasible now. Ideally we would get the data via Google Fit as this is already integrated, but last time I looked you didn’t send “time in bed” records, just one total time asleep record — has this changed?

I’m really excited that this is taken up again, I’m counting on this integration to really add enough value to my exist experience that I can continue using it :)

Jumping on board with this. Sleep as Android does a pretty good job of logging my sleep cycles without a wearable and it shows up in Google Fit and Samsung Health with the kind of data I’m looking for like time sleeping, how many times I hit snooze, when I went to bed and when I woke up, etc. If that can somehow be fed into Exist it’d be amazing and I’d have 3 less apps to check on!

I do not see how this integration is not possible. Zenobase does it so it is possible. Time in bed and sleep time might not be the same but it should be. Making this distinction between the 2 I already think is pointless. The deep sleep vs light sleep is the metric that is far more important. Laying in bed without actually sleeping is sort of similar to light sleep. Users can in the morning cut out sleep time that was not actually sleep time. Something that Withings does not allow you to do. So there is as much reason to say that the withings data is not good enough and not integrate with Withings. I think this is point of not possible is mute. And seeing as they probably have the biggest market share when it comes to sleep data I think it is a bit silly that exist does not integrate with sleep cloud / sleep as android.

Thanks for your feedback Jurgen. You can read the past discussion to understand our reasons. Actually I agree that Withings sleep data isn’t great but we supported that platform already, and if we had a chance to do it all again we probably wouldn’t support sleep from Withings.

Imagine that this category is titled “not possible or not planned” because this is the only one in the latter, I think, and I don’t see the need for a separate category just for it 😊

Also, this will be supported by adding Sleep from Google Fit, which is more likely to happen.

Per the Google Fit topic (and my own look at what Sleep as Android sends to Google Fit), Sleep as Android only send the sleep activity, and not the separate activity types for Light sleep, Deep sleep, REM sleep, and Awake (during sleep cycle).

I’ve submitted a feature request for them to support the additional types which would be needed for Exist integration via Google Fit: https://urbandroid.uservoice.com/forums/264867-sleep-as-android/suggestions/31843045-send-awakenings-and-sleep-phases-to-google-fit

If you’d like to see Sleep as Android data be usable in Exist, go there and vote up the request.

A Sleep developer answered and said that Google Fit gets all the needed information for sleep activity (such as awake time and real sleeping time) but just doesn’t display it in the client app. Shouldn’t this be enough to add the data to Exist?

Daniel, Google Fit sleep is already completed. You can see the details here: https://changemap.co/hellocode/exist/task/1824-sleep-from-google-fit/ You’ll notice in the comments there that despite what some developers have said, a lot of data is not being sent to Google Fit, but we have integrated the data we can get from Google Fit at this stage.

I’m sorry but you are being completely stupid and losing a customer because of it. Sleep as Android has incredibly detailed data and if for some reason it wasn’t immediately available to you in the form you wanted, the developer personally jumped in here and offered to help, but you refused for some snobbish reason. I’ve tried your service for a month now, and its totally useless to me because the whole thing I want to do is correlate custom metrics with the QUALITY of my sleep which you refuse to provide.

Hey Kevin, I’m sorry you feel that way. You can of course already use your sleep from Sleep as Android via Google Fit, although this data is not as detailed because of the developer failing to resolve the issues with their integration there. With limited time it doesn’t make sense for us, with Android users already a minority and sleep from Google Fit already completed, to go and add Sleep as Android on top now Fit is supported. The extra sleep detail you’re after could be there right now, if only Sleep as Android exported their data to Fit correctly. So whenever that changes on their end, it’ll be supported in Exist by default 😊

Andrew, If you’re having issues with Google Fit syncing to Exist, you’re welcome to send us a support request about it and I’ll get it sorted — I can’t fix it unless I know about it! 🙂 However, that’s unrelated to adding Sleep as Android. Totally understand about the effort of manual tracking, that’s not a solution for sleep at all, but the broader solution here is that Google Fit exists as a means to sync Sleep as Android data, and if it has issues for you we can get (or could have got) them fixed.

Sorry for my overly negative attitude, but I was having a bad day (probably due to poor sleep!). I’ll try to be a bit more logical today.

As a developer myself I find your attitude towards your product kind of silly. You claim to care about the data and want it to be accurate, but then seem to think that the extra step of jumping through a different 3rd party service first is a good idea. It adds unnecessary complexity that increases the chances of of things breaking or data being lost/inaccurate.

Also, what if someone doesn’t want to give the Google overloads his/her health data? You seem to assume all Android users will be using Google Fit and that simply is not the case.

You know WHY Android users are a minority? Because of poor support and snobbish attitudes. Seriously… all the way down to the category for this issue “Not possible”. That’s a big fat lie, it is absolutely possible you just choose not to. Be at least a little more truthful and make a “Not Planned” category or something.

It’s your product and you can do with it what you want, but you seem to be losing at least some customers that want proper support for this and there are alternatives that work so away we go!

Kevin, your response is really disappointing. Let’s address a few of the things you brought up.

Android users are not a minority because of inferior support, that’s a pretty unfounded claim. Our Android app has often had features before the iOS app, among other things. Not adding this one service you’re after does not constitute a bad experience for an entire operating system.

I already mentioned in an earlier comment that Sleep as Android is in this category because there’s no “Not Planned” category, and I don’t want to make one for this single task. It can live in here until there’s a better reason to separate them out.

The reason we don’t support Sleep as Android natively in the first place is because we care about the quality of data, and yes, it’s not any better from Google Fit, but it’s much easier to add data types from integrations we already have, and cover other sources of sleep data at the same time (for example, Samsung Health). It’s a practical decision.

I totally understand that the choices we make in attempting to cover the most users with the best compromise won’t work for everyone (that’s why it’s a compromise!), and that’s why we have an API available. Every user is able to do the work to add an alternative they’re after individually. We try to cover the common cases, but you have the power to fill in the gaps for yourself if you’re passionate about it. As a developer, I hope you appreciate the value of making that available.

The bottom line here is that there’s little reason to change the situation for Sleep as Android. A solution exists already, and while I understand that it’s super frustrating if it doesn’t work for you, it does for others, and we have limited time and must attempt to use it to make the biggest impact for the most users.

I’m in the Exist.io trial period right now, and some of the developer responses here are making me think very seriously about whether I really want to continue using the service.

Sleep As Android doesn’t discriminate between time in bed and time asleep because it only measures time asleep. Time spent in bed but not asleep after tracking has been turned on can be corrected by the user - which anyone sufficiently committed to tracking their sleep that they use a manual tool every night and morning is also likely to do. Funnily enough, users also have an interest in the quality of their data.

Regarding the accuracy of the tracking, I’ve recently started using a worn tracker in addition to Sleep As Android on my smartphone handset and have been surprised and impressed to find that the Sleep As Android tracking is really very similar to the quality of data I’m now getting from something – supposedly superior – strapped to my wrist. The pattern of deep and light sleep is the same. The wearable tends to detect sleep a few minutes after Sleep As Android (as one might expect), but it also continues logging my morning dozing as sleep when it isn’t - and when Sleep As Android knows I am already awake because I’m using my phone. So the sleep durations reported work out to be the same. Based on what I’m seeing, it’s simply not accurate to describe Sleep As Android data as inferior in any way.

More importantly, you talk a lot about the “quality” of the data. Surely the standard for the quality of data in a paid data repository/analysis service is set by the user who is paying for it. If it’s good enough for the user, what does it matter what anyone else thinks? The only reason to have some kind of “absolute” data quality standard is if you’re combining multiple users’ data to draw out some broader results you then wish to sell as a product in its own right. Are you? The idea that you’re acting as some kind of guardian of high quality data – that people are going to check in with your obscure service to find out whether or not they should rely on someone else’s product – is frankly laughable. What you sell is a service to analyse users’ data - a service the users pay for. But now you think you get to tell them what other products they should or shouldn’t use, and whether their choices meet your high(er) standards?

That’s pretty arrogant, and suggests some troubling things about how you view the data that is being entrusted to you. And I for one am not interested in handing over vast quantities of highly personal data about my whole life to someone who thinks that way.

Hi V W,

Sleep as Android data is available via Google Fit, so no need to stress! Connect the SaA to Fit and you can get it into Exist and use the sleep tracking data you prefer.

We don’t sell user data, which we mention specifically in the privacy policy.

Syncing Sleep as Android to Fit doesn’t require any extra connector services, and targeting Fit allows us to do less work integrating the individual services. It’s the Android equivalent of Apple Health — it’s much faster for us to integrate more data types from one service than multiple types across multiple services, which means we can provide more data for users overall. With just me writing integrations, these sorts of compromises need to be made. And Fit is a pretty safe bet. It’s not going to go away or stop accepting third-party data tomorrow.

Votes are always valid of course, but Sleep as Android has far fewer votes than the most popular services listed here. Given I only have the time to integrate a single-digit amount of new services each year, it’s a double whammy of low-demand and wasted effort, given the data is already able to be synced to Exist via Google Fit. As we do not have attributes for light or deep sleep, there would be no benefit in terms of data to integrating it directly, nothing new would be added.

Also, one of the reasons we have an API is so people can scratch their own itch without relying on us — rather than just saying “sorry, no”, we’ve made it possible to get around our priorities and make the integration you want to exist. You’re very welcome to write your own connector that grabs SaA data and sends it to Exist, if you want the data to come directly from SaA.

I am locking comments as further discussion on these same points is not productive.