Documentation‎ > ‎

H. Smartwatch integration API

Url Redirector Modified

If there is a 3rd party smart watch you'd like to have integrated, it does have some usable API and it is not integrated yet, you have 2 options:
1) Write us about the watch, and we'll evaluate how useful and feasible would it be to integrate the watch with our application. if we are convinced it is feasible and many users would benefit from it, we'll do the integration ourselves.
2) You can try to integrate the watch yourself. You can even make your own paid add-on to sleep for other users if you want, we have no objections against this!

This section gives you necessary information about the integration hooks in our application.

Any newly integrated devices will likely need some device specific communication channel. You cannot write this as a part of our application. Instead, you should write a separate android application that will do 2 things. First, it will communicate with the watch of your interest. Second, it will communicate via standard android intent with Sleep As Android application. On this page you can find all the important intents you need to listen to and you can send.

When a phone needs to connect to your watch (start of tracking, alarm, ..) it first checks whether the watch is connected. It will issue the following intent:

The intent is issued periodically every few seconds either till a positive reply is issued or timeout has passed. You should listen to this intent and reply with the following intent when the watch is connected and ready to be used:

After this exchange the phone is ready to use the smartwatch for further actions.

Watch can automatically establish the connection with the phone application by sending some sleep movement data, see later. When this is done, the tracking on phone is automatically started and the connection between the watch and phone is prepared to receive further updates.

There is a fixed set of commands send from the phone to the watch you need to implement. You do not need to implement all of them, if you do not need all the features.

Start movement tracking

Stop movement tracking

Pause tracking
  TIMESTAMP (long): Timestamp in milliseconds that tells the watch till when the pause should last. It can be in the future, which means pause is still active, or in the past, which means pause should be terminated.

When the pause is received, the watch should note the pause end-time. Till then, no tracking needs to be performed, but values of 0.0 should still be sent. It is advisable to show to a user the tracking is paused and indication of remaining pause time. User should be also given an option to extend or terminate the pause.

If the pause expires naturally on phone, i.e. its time runs out, there is no notification to the watch about pause being over! Only if user prematurely finishes the pause, watch is notified (by sending SET_PAUSE with timestamp 0).

Suspend tracking
 SUSPENDED (bool): Whether the tracking is suspended or not.

This is a complementary intent to SET_PAUSE. If you do not intend to show any pause indication or allow user to control pausing, you can just listen on SET_SUSPENDED. It is set to true when pause starts and set to false when the pause is over.

Set batch size
(long): Desired batch size

This command is used to request an a size of batch of events send from watch to the phone. If you do not obey the requested batch size, some data may get ignored or you may end up with holes in your graph. You should keep on your end record of the latest requested batch size. See more details about handling of batch sizes in "Sending the data" watch messages.

Start alarm
 DELAY (int): Desired delay in millisecond after how long should the alarm start.

Send when an alarm should ring. The delay parameter is controlled by a watch gradual vibration configuration. It tells the watch, when a user would like the vibrations to start on the watch.

Stop alarm

Set alarm
 HOUR (int): Hour of day, when the next alarm will ring.
 MINUTE (int): Minute of an hour, when the next alarm will ring.
 TIMESTAMP (long): Timesatmp (in ms), when the next alarm will ring.

The first 2 params are more for presentation - useful especially for devices with lack of support for timezones. The third parameter is an actual timestamp when the alarm will ring. It can be used to ensure an alarm rings on the watch even if it is not connected to the phone (the watch can for example trigger the alarm themselves when the timestamp is reached). If the connection with phone is alive, the phone will sent the START_ALARM intent to notify the watch the alarm is ringing.

Show notification
 TITLE (string): Title of the notification to be shown.
 TEXT (string): Text of the notification.

This intent is used to show a generic notification on the watch. It is not required for tracking or alarm to work.

 REPEAT (int): How many times should the hint signal be repeated.

Used by watch to send a non-textual notification to user, typically implemented as a short vibration. In case of vibration, the REPEAT parameter tells the watch how many times show it vibrate. This command is send for example by lucid dreaming or anti-snoring features.

In this section we list a set of intents, that can be send to our application. Not all of them need to be implemented.

Send movement data
 MAX_DATA (float array): Array containing latest MAX received values. Data should come in order in which they were received.
 MIN_DATA (float array): Array containing latest MIN received values. Data should come in order in which they were received.
 AVG_DATA (float array): Array containing latest AVG received values. Data should come in order in which they were received.

Sleep As android expects to receive data aggregated per 10 seconds intervals. The values to be aggregated should be changes in raw accelerometer data expressed in m/s2. For each sampled value sum up acceleration change along all axis to get a single value. You should aggregate the per-sample data in 3 different ways - maximum, minimum, and average acceleration value seen in 10 seconds interval. For efficiency, we suggest you do the aggregation on the watch and send only aggregated values to the phone.

You should keep aggregating data as they come and when you have enough aggregated values (as many as requested batch size) send the to the application. If the batch is send too late, it may confuse the collection algorithm and values can be either ignored or a graph may already have an empty space filled.

Values should be send also in case the tracking is paused! You can send just -0.01 for each of the aggregate that fits to a time tracking was paused.

Example aggregation:
Let's assume your device samples once every 5 seconds (for simplicity only - real devices sample a few times per second). Assume these values from accelerometer:
Time 0s - X: 9.81, Y: 0.0, Z: 0.0
Time 5s - X: 9.81, Y: 0.1, Z: 0.0
Time 10s - X: 9.81, Y: 0.2, Z: 0.0
Time 15s - X: 10.81, Y: 0.0, Z: 0.3

The values would transform to this:
Time 0s - we do not have any past values, so cannot compute diff -> ignore this.
Time 5s - 0.1
Time 10s - 0.1
Time 15s - 1.05

Finally, these has to be aggregated to 10 second batches. We have 20 secs of data, so they end up in 2 batches. The first aggregate has only one value as we had to ignore the first value, so the final values are:

Aggregate 1 - MIN: 0.1, MAX: 0.1, AVG: 0.1
Aggregate 2- MIN: 0.1, MAX: 1.05 AVG: 5.03

The batches have to be send in this order.

Pause from watch

Adds 5 minutes to current pause time.

Resume from watch

Terminate current pause.

Snooze from watch

Snooze current alarm.

Dismiss from watch
Dismiss current alarm. If there is a captcha enabled for current alarm, it will be displayed on the phone and has to be solved there. After the captcha is solved, the phone will send the STOP_ALARM action.