一部のみ日本語訳を付けました（工藤：2020.12.17)

DataPort API（日本語）

Overview

DataPort 装置はクライアント(PC, tablet,　phones) と REST APIを使って通信する. DataPort の主な役割は指定した周波数で一つ以上の Boditrak センサーマットの値を読み込み、
読み込んだ値をバッファに貯めることである。マットにつながれた装置は時間的に余裕のあるときにそのデータに
関する読み込み要求を送ることができる。必ずしも、記録と同じ周期で読み込みをする必要はない。
例えば、100Hzで記録するように決めておき、一方でクライアントは一秒毎に100回分の読みこみをすることができる。

追加のプラグインがあり、それらを使うとDataportにアプリケーション用の機能を与えられる。現在、二つのプラグインを提供している。
一つはゴルフアプリに使われるような圧力中心を与えるもので、もう一つは医療用のベッド用のアプリなどで、データの長期安定的な記録・解析を与えるものである。
サードパーティは自分でプラグインを作ることができるが、この文章には方法は記してない。

便宜を考えて、この装置は基本的な設定や検査のための組込みウェブアプリを持つ。

/api

クライアントはRESTful APIにより、設定およびマットからの読み込みを行える。
そのAPIは通常のウェブブラウザ―から見ることができる。 http://ip_address/apiをブラウザーに入れることで、
次のような応答を得られる。

{
"device":{ "class":"Boditrak DataPort", "name":"DataPort-0559dc", "address":"192.168.2.21" },
"sensors":[ { "name":"UT5009-8031", "columns":16, "rows":16, "width":430, "height":430, "minimum":0, "maximum":100, "units":"mmHg" } ],
"frames":[ { "id":797, "time":"2015-05-07 15:49:14.620", "readings":[ [ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,5,2,17,5,3,3,0,0,0,0,0,0,0,2,15,29,36,12,23,35,100,35,13,8,0,0,0,0,6,4,22,100,55,16,27,100,100,70,34,28,9,0,0,0,10,9,42,100,100,21,28,100,100,100,43,36,8,0,0,0,7,9,15,25,19,11,26,40,41,100,24,17,2,0,0,0,7,12,16,14,14,4,3,12,11,11,31,10,19,0,0,0,9,13,14,9,7,1,1,6,8,13,32,12,11,0,0,0,13,6,5,3,2,0,2,6,7,6,1,0,0,0,0,0,8,8,6,2,2,0,0,4,2,4,4,3,0,0,0,0,3,11,11,3,2,0,0,3,3,5,10,3,0,0,0,0,0,0,5,5,1,0,0,2,5,9,12,1,0,0,0,0 ] ] } ],
"frequency":3600,
"sensorsRequired":0,
"filters":{ "spot":false, "smooth":false, "noise":false },
"power":{ "state":"charging", "level":40 },
"wifi":{ "ssid":"MyWifiNetwork", "mode":"indirect", "list":[ "Neighbours Network", "Starbucks" ] },
"firmware":{ "version":"0.02.008", "upgrade":"unknown", "source":"stable" }
}

上の出力の個々の属性値はそれぞれに要求することができる。例えば、http://＜ip_address＞/api/device　と打つことで次の
ような出力が得られる:

"device":{ "class":"Boditrak DataPort", "name":"DataPort-0559dc", "address":"192.168.2.21" }

文字列名や番号を指定することで要求をさらに個別に特定化できる。。例えば、
http://＜ip_address＞/api/device/name とすることで以下のような出力を得る:

"DataPort-0559dc"

大部分の性質は読み込み専用である。設定できる性質には、frequency, sensorsRequired, filters　の各要素, wifi
の性質（listは除く), and firmware/install　等がある。性質の値を得るにはHTTP GETを、設定するには
HTTP PUTを使うこと。もし、値を設定する際にはデータがJSONでエンコードされている必要がある：
PUTデータのフォ－マットは対応するGETにより得られるデータのそれと一致する必要がある。

/api/device

このdeviceオブジェクトはDataPort装置に関する基礎的な情報を与える。
これはネットワーク上のDataPort装置を発見するために作られた。
クライアントはGET api/deviceをすべてのIPに発行して応答を処理する。address が応答した装置のIPを示す。
続く要求はそのIPへと直接送られる。デモンストレーションは
http://www.boditrak.com/software/sumo/find
でみることができる。

このオブジェクト(class, name, address)の属性値のそれぞれは個別に要求できる.

Request	Response
`GET /api/device HTTP/1.1`	`HTTP/1.1 200 OK { "class":"Boditrak DataPort", "name":"DataPort?-0559dc", "address":"192.168.2.21" }`
`GET /api/device/class HTTP/1.1`	`HTTP/1.1 200 OK "Boditrak DataPort"`
`GET /api/device/name HTTP/1.1`	`HTTP/1.1 200 OK "DataPort-0559dc"`
`GET /api/device/address HTTP/1.1`	`HTTP/1.1 200 OK "192.168.2.21"`

/api/sensors

このオブジェクトはオブジェクトの配列であり、ここのオブジェクトはDataPort が今スキャンしているセンサーを示している。
例え、DataPortにつながっているのが一つのマットであっても、一つのセンサーオブジェクトではなくその配列であることに
注意が必要である。

Request	Response
`GET /api/sensors HTTP/1.1`	`HTTP/1.1 200 OK [ { "name":"UT5009-8031", "columns":16, "rows":16, "width":430, "height":430, "minimum":0, "maximum":100, "units":"mmHg" } ]`

/api/frames

このオブジェクトは記録されたフレームの配列である。一つのフレームは次のものからなる、疑似的な一意の番号、
（そのフレームの開始時刻）タイムスタンプ、各センサーの値の配列。
api/frames　を要求することで一つの項目、つまり、最後の記録フレームを出力する。

フィールド’after’を質問に加えることで指定したフレーム以降に記録されたすべてのフレームを受け取れる。
この特徴はクライアントに「高い周波数でDataPortにスキャンさせ、低い周波数を除いて持ってくる」ことを許す。
これはよく使われることで、多くのアプリケーションに見られる、高周波の情報を読み取りたいものの表示は人が知覚できる
程度の周期でいい、という要求に答えるものである。
クライアントは高周波数走査をDataPortに任せ、DataPortに処理の余裕があるとき（例えば、表示のために画面をリフレッシュするとき）
に読み取り結果をダウンロードする。
.

この使用法の場合、クライアントはapi/framesにGET要求することで最後のフレームを得るだろう。
その応答はこのようなものかもしれない:

[ { "id":797, "time":"2015-05-07 15:49:14.620", "readings":[ [ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,5,2,17,5,3,3,0,0,0,0,0,0,0,2,15,29,36,12,23,35,100,35,13,8,0,0,0,0,6,4,22,100,55,16,27,100,100,70,34,28,9,0,0,0,10,9,42,100,100,21,28,100,100,100,43,36,8,0,0,0,7,9,15,25,19,11,26,40,41,100,24,17,2,0,0,0,7,12,16,14,14,4,3,12,11,11,31,10,19,0,0,0,9,13,14,9,7,1,1,6,8,13,32,12,11,0,0,0,13,6,5,3,2,0,2,6,7,6,1,0,0,0,0,0,8,8,6,2,2,0,0,4,2,4,4,3,0,0,0,0,3,11,11,3,2,0,0,3,3,5,10,3,0,0,0,0,0,0,5,5,1,0,0,2,5,9,12,1,0,0,0,0 ] ] } ]

そして、少ししてから、クライアントはapi/frames?after=797へのGET要求により、フレームNo.797からのすべての
フレームを要求するだろう。その応答はこのようなものかもしれない:

[
{ "id":798, "time":"2015-05-07 15:49:14.720", "readings":[ [ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,5,2,17,5,3,3,0,0,0,0,0,0,0,2,15,29,36,12,23,35,100,35,13,8,0,0,0,0,6,4,22,100,55,16,27,100,100,70,34,28,9,0,0,0,10,9,42,100,100,21,28,100,100,100,43,36,8,0,0,0,7,9,15,25,19,11,26,40,41,100,24,17,2,0,0,0,7,12,16,14,14,4,3,12,11,11,31,10,19,0,0,0,9,13,14,9,7,1,1,6,8,13,32,12,11,0,0,0,13,6,5,3,2,0,2,6,7,6,1,0,0,0,0,0,8,8,6,2,2,0,0,4,2,4,4,3,0,0,0,0,3,11,11,3,2,0,0,3,3,5,10,3,0,0,0,0,0,0,5,5,1,0,0,2,5,9,12,1,0,0,0,0 ] ] },
{ "id":799, "time":"2015-05-07 15:49:14.820", "readings":[ [ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,5,2,17,5,3,3,0,0,0,0,0,0,0,2,15,29,36,12,23,35,100,35,13,8,0,0,0,0,6,4,22,100,55,16,27,100,100,70,34,28,9,0,0,0,10,9,42,100,100,21,28,100,100,100,43,36,8,0,0,0,7,9,15,25,19,11,26,40,41,100,24,17,2,0,0,0,7,12,16,14,14,4,3,12,11,11,31,10,19,0,0,0,9,13,14,9,7,1,1,6,8,13,32,12,11,0,0,0,13,6,5,3,2,0,2,6,7,6,1,0,0,0,0,0,8,8,6,2,2,0,0,4,2,4,4,3,0,0,0,0,3,11,11,3,2,0,0,3,3,5,10,3,0,0,0,0,0,0,5,5,1,0,0,2,5,9,12,1,0,0,0,0 ] ] },
{ "id":800, "time":"2015-05-07 15:49:14.920", "readings":[ [ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,5,2,17,5,3,3,0,0,0,0,0,0,0,2,15,29,36,12,23,35,100,35,13,8,0,0,0,0,6,4,22,100,55,16,27,100,100,70,34,28,9,0,0,0,10,9,42,100,100,21,28,100,100,100,43,36,8,0,0,0,7,9,15,25,19,11,26,40,41,100,24,17,2,0,0,0,7,12,16,14,14,4,3,12,11,11,31,10,19,0,0,0,9,13,14,9,7,1,1,6,8,13,32,12,11,0,0,0,13,6,5,3,2,0,2,6,7,6,1,0,0,0,0,0,8,8,6,2,2,0,0,4,2,4,4,3,0,0,0,0,3,11,11,3,2,0,0,3,3,5,10,3,0,0,0,0,0,0,5,5,1,0,0,2,5,9,12,1,0,0,0,0 ] ] },
{ "id":801, "time":"2015-05-07 15:49:15.020", "readings":[ [ 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,5,2,17,5,3,3,0,0,0,0,0,0,0,2,15,29,36,12,23,35,100,35,13,8,0,0,0,0,6,4,22,100,55,16,27,100,100,70,34,28,9,0,0,0,10,9,42,100,100,21,28,100,100,100,43,36,8,0,0,0,7,9,15,25,19,11,26,40,41,100,24,17,2,0,0,0,7,12,16,14,14,4,3,12,11,11,31,10,19,0,0,0,9,13,14,9,7,1,1,6,8,13,32,12,11,0,0,0,13,6,5,3,2,0,2,6,7,6,1,0,0,0,0,0,8,8,6,2,2,0,0,4,2,4,4,3,0,0,0,0,3,11,11,3,2,0,0,3,3,5,10,3,0,0,0,0,0,0,5,5,1,0,0,2,5,9,12,1,0,0,0,0 ] ] }
]

Request Response

Request	Response
`GET /api/frames HTTP/1.1`	`HTTP/1.1 200 OK [ { "id":797, "time":"2015-05-07 15:49:14.620", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } ]`
`GET /api/frames?after=797 HTTP/1.1`	`HTTP/1.1 200 OK [{ "id":798, "time":"2015-05-07 15:49:14.720", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] }, { "id":799, "time":"2015-05-07 15:49:14.820", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] }, { "id":800, "time":"2015-05-07 15:49:14.920", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] }, { "id":801, "time":"2015-05-07 15:49:15.020", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } ]`

GET /api/frames HTTP/1.1

HTTP/1.1 200 OK

[ { "id":797, "time":"2015-05-07 15:49:14.620", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } ]

GET /api/frames?after=797 HTTP/1.1

HTTP/1.1 200 OK

[{ "id":798, "time":"2015-05-07 15:49:14.720", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] },
{ "id":799, "time":"2015-05-07 15:49:14.820", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] },
{ "id":800, "time":"2015-05-07 15:49:14.920", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] },
{ "id":801, "time":"2015-05-07 15:49:15.020", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } ]

/api/frequency

これはDataPortが記録する周波数である。この値は時間あたりの走査数である。値を0にすることで
DataPortは可能な最も速い周期で走査する。

Request	Response
`GET /api/frequency HTTP/1.1`	`HTTP/1.1 200 OK 3600`
`PUT /api/frequency HTTP/1.1 60`	`HTTP/1.1 204 No content`

/api/sensorsRequired

DataPortがつなげる必要のあるマットの最小数。
Specifies the minimum number of sensor mats that need to be connected
to the DataPort before the DataPort will start scanning the sensors.
For single sensor systems this value is irrelevant.

When first starting up, the DataPort will look for all mats that are
connected to it and, if the number of mats is greater than or equal to
the sensorsRequired value, it will proceed to scan those mats. If the
number of mats is less than sensorsRequired then the DataPort will
periodically check for connected mats and start scanning as soon as it
detects a sufficient number of sensors. A sensorsRequired value of 0 is
equivalent to a sensorsRequired value of 1 (ie the DataPort will start
scanning when at least one mat is connected). To force the DataPort to
retest the number of mats that are connected, set the sensorsRequired
value.

Request	Response
`GET /api/sensorsRequired HTTP/1.1`	`HTTP/1.1 200 OK 0`
`PUT /api/sensorsRequired HTTP/1.1 3`	`HTTP/1.1 204 No content`

/api/filters

DataPortはいくつかのフィルターを使ってマットから読み込み値を処理できる。
このオブジェクトは使えるフィルターのリストを持ち、どれが読み込んだ値に適用されるかを示している。

Request	Response
`GET /api/filters HTTP/1.1`	`HTTP/1.1 200 OK { "spot":false, "smooth":false, "noise":false }`

/api/filters/spot

真のとき、スポットフィルターは読み込み値に適用される。このフィルターは
周りのセンサー値よりかなり大きいセンサー値を置き換える。多くのアプリケーションで、
一つのセンサー値が周囲よりかなり大きい場合、それは誤りである可能性が高い。
このフィルターはその値を周囲の平均値で置き換える。

Request	Response
`GET /api/filters/spot HTTP/1.1`	`HTTP/1.1 200 OK false`
`PUT /api/filters/spot HTTP/1.1 true`	`HTTP/1.1 204 No content`

/api/filters/smooth

真のとき、平滑化フィルターは読み込み値に適用される。このフィルターは
個々のセンサー値をその8近傍の重み付き平均値で置き換える。

Request	Response
`GET /api/filters/smooth HTTP/1.1`	`HTTP/1.1 200 OK false`
`PUT /api/filters/smooth HTTP/1.1 true`	`HTTP/1.1 204 No content`

/api/filters/noise

真のとき、ノイズフィルターは読み込み値に適用される。このフィルターは
時間において極端に変化するセンサー値の変化を和らげる　急激な値の変化
は環境や組織的な雑音によるものかもしれない。
.

Request	Response
`GET /api/filters/noise HTTP/1.1`	`HTTP/1.1 200 OK false`
`PUT /api/filters/noise HTTP/1.1 true`	`HTTP/1.1 204 No content`

/api/power

The power object contains information about the battery and it’s charge status.

Request	Response
`GET /api/power HTTP/1.1`	`HTTP/1.1 200 OK { "state":"charging", "level":40 }`

/api/power/state

Indicates whether the battery is ‘charged’, ‘charging’, ‘discharging’, or ‘low’.

Request	Response
`GET /api/power/state HTTP/1.1`	`HTTP/1.1 200 OK "charging"`

/api/power/level

Indicates the amount of charge relative to the battery’s capacity
(expressed as a percent). This value is a crude approximation and can
jump in large increments. Future versions of the firmware will provide a
more accurate indicator of charge levels.

Request	Response
`GET /api/power/level HTTP/1.1`	`HTTP/1.1 200 OK 40`

/api/time

The time value is a string representation of the DataPort’s system clock.

Request	Response
`GET /api/time HTTP/1.1`	`HTTP/1.1 200 OK "2015-12-31 18:41:10.850"`
`PUT /api/time HTTP/1.1 "2015-12-31 18:45:00.000"`	`HTTP/1.1 204 No content`

/api/wifi

This object represents the wifi configuration. The DataPort operates
in one of two modes, ‘direct’ and ‘indirect’. In ‘direct’ the DataPort
acts as a wireless access point. A device can connect to it just like it
would connect to a typical wireless router. In ‘indirect’ mode the
DataPort connects to a wireless router. The router it connects to is
determined by the ssid property.

The wifi object has a write-only property called ‘password’ that is
not included in response to a GET |Request. The DataPort uses the
‘password’ to connect to the network specified by ‘ssid’.

If the DataPort is in ‘indirect’ mode, it must maintain a connection
to the router. If the DataPort loses it’s connection with the router
and, after 30 seconds is unable to re-establish the connection, then it
will revert to ‘direct’ mode.

Request Response

Request	Response
`GET /api/wifi HTTP/1.1`	`HTTP/1.1 200 OK { "ssid":"MyWifiNetwork?", "mode":"indirect", "list":[ "Neighbours Network", "Starbucks" ] }`
`PUT /api/wifi HTTP/1.1 { "ssid":"MyOtherNetwork", "password":"secret" }`	`HTTP/1.1 204 No content`

GET /api/wifi HTTP/1.1

HTTP/1.1 200 OK

{ "ssid":"MyWifiNetwork?", "mode":"indirect", "list":[ "Neighbours Network", "Starbucks" ] }

PUT /api/wifi HTTP/1.1

{ "ssid":"MyOtherNetwork", "password":"secret" }

HTTP/1.1 204 No content

/api/wifi/mode

This property can be one of two values ‘direct’ or ‘indirect’. If
mode’s value is ‘direct’ it means the device is acting as a wireless
Access Point in which case clients should connect to the wireless
network with the SSID ‘DataPort?-XXXXXX’ (where XXXXXX is a string of 6
characters unique to each DataPort) and direct all queries to the IP
address 10.0.0.1. If mode’s value is ‘indirect’ it means the device is
connected to (or trying to connect to) the local wireless network
specified by the ssid property.

Request	Response
`GET /api/wifi/mode HTTP/1.1`	`HTTP/1.1 200 OK "indirect"`
`PUT /api/wifi/mode HTTP/1.1 "direct"`	`HTTP/1.1 204 No content`

/api/wifi/ssid

This property contains the SSID of the wifi network that DataPort
will connect to when the mode is ‘indirect’. When DataPort is in
indirect mode the client needs to connect to the same network and direct
it’s queries to the IP address of the DataPort device. That IP address
is determined by the wireless router that the device has connected to.
It can be discovered by sending api/device queries to all IP addresses
on the network. See the device section above for details.

Request	Response
`GET /api/wifi/ssid HTTP/1.1`	`HTTP/1.1 200 OK "MyWifiNetwork"`
`PUT /api/wifi/ssid HTTP/1.1 "MyOtherNetwork"`	`HTTP/1.1 204 No content`

/api/firmware

This object contains information about the DataPort firmware and offers a means to upgrade the firmware.

Request	Response
`GET /api/firmware HTTP/1.1`	`HTTP/1.1 200 OK { "version":"0.02.008" }`

/api/firmware/version

This is simply a string that indicates the version of DataPort software.

Request	Response
`GET /api/firmware/version HTTP/1.1`	`HTTP/1.1 200 OK "0.02.008"`

/api/firmware/upgrade

This is a string that indicates the status of the upgrade process. It
will return either “unknown”, “uptodate”, “ready”, “downloading”,
“downloaded”, “installing”, “installed”, or “restarting”. When the
status is “unknown”, “ready”, “downloaded”, or “installed” PUT this
property to “next” in order to advance through the upgrade process. The
meaning of each state is as follows:

unknown: the firmware version may or may not be up-to-date. “next”
will have the dataport check with the upgrade server to see if there is a
newer version of firmware. It will then move to the “ready” or
“uptodate” state
ready: the dataport has recently checked with the upgrade server and
there is a newer version of firmware available. “next” will have the
dataport switch to the “downloading” state.
uptodate: the dataport has recently checked with the upgrade server and the dataport’s firmware is up-to-date.
downloading: the dataport is in the process of downloading the firmware.
downloaded: the dataport has downloaded the latest firmware and is
ready to install it. “next” will have the dataport switch to the
installing state.
installing: the dataport is in the process of installing the new firmware.
installed: the dataport has successfully installed the firmware and
is ready to restart the dataport service. “next” will have the dataport
switch to the restarting state.
restarting: the dataport is about to restart the firmware. Shortly
after entering this state the connection will drop. When the firmware
restarts the upgrade state will be “unknown”.

If any one of these steps fail, the upgrade state will return to “unknown”.

Request	Response
`GET /api/firmware/upgrade HTTP/1.1`	`HTTP/1.1 200 OK "unknown"`
`PUT /api/firmware/upgrade HTTP/1.1 "next"`	`HTTP/1.1 204 No content`

/api/firmware/package

PUTting to this URL pushes a firmware package onto the datport. The
package would be typically downloaded from an upgrade server (often from
http://boditrak.com/software/dataport/upgrade/packages) and then the
received package pushed to the datport with this command. Once the
dataport has received the package, /api/firmware/upgrade switches to the
“downloaded” state. PUT “next” to /api/firmware/upgrade to walk the
dataport through the rest of the upgrade process.

Request	Response
`PUT /api/firmware/package HTTP/1.1 the package's binary data as received from the upgrade server`	`HTTP/1.1 204 No content`

/api/firmware/source

This property contains a string that indicates which firmware the
datport tries to synchronize with when walking through the upgrade
process. A value of “stable” indicates that the stable, well tested
version of firmware should be used. A value of “unstable” indicates the
dataport should be using the absolute latest version of firmware. The
latest version of firmware is often untested and may contain significant
defects including the inability to receive and install further
upgrades.

Request	Response
`GET /api/firmware/source HTTP/1.1`	`HTTP/1.1 200 OK "stable"`
`PUT /api/firmware/source HTTP/1.1 "unstable"`	`HTTP/1.1 204 No content`

/api/sse

Provides a stream of server-sent events. There are only two event
types sent, the ‘sensors’ event and the ‘newframe’ event. The ‘sensors’
event is sent when the connected sensors has changed. The data for the
‘sensors’ event is an array of sensor objects and is the same as
returned by an api/sensors GET request. The ‘newframe’ event is sent
whenever a new frame is created. The data attached to the ‘newframe’
event is a frame object (the same as an element of the ‘frames’ array).
The DataPort will continue to send ‘sensors’ and ‘newframe’ events as
long as the connection remains open.

Request Response

Request	Response
`GET /api/sse HTTP/1.1`	HTTP/1.1 200 OK event: sensors data: [ { "name":"UT5009-8031", "columns":16, "rows":16, "width":430, "height":430, "minimum":0, "maximum":100, "units":"mmHg" } ] event: newframe data: { "id":797, "time":"2015-05-07 15:49:14.620", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } event: newframe data: { "id":798, "time":"2015-05-07 15:49:14.720", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } event: newframe data: { "id":799, "time":"2015-05-07 15:49:14.820", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } event: newframe data: { "id":800, "time":"2015-05-07 15:49:14.920", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } event: newframe data: { "id":801, "time":"2015-05-07 15:49:15.020", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] } . . .

GET /api/sse HTTP/1.1

HTTP/1.1 200 OK

event: sensors
data: [ { "name":"UT5009-8031", "columns":16, "rows":16, "width":430, "height":430, "minimum":0, "maximum":100, "units":"mmHg" } ]

event: newframe
data: { "id":797, "time":"2015-05-07 15:49:14.620", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] }

event: newframe
data: { "id":798, "time":"2015-05-07 15:49:14.720", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] }

event: newframe
data: { "id":799, "time":"2015-05-07 15:49:14.820", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] }

event: newframe
data: { "id":800, "time":"2015-05-07 15:49:14.920", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] }

event: newframe
data: { "id":801, "time":"2015-05-07 15:49:15.020", "readings":[ [ 0,0,0, ... ,0,0,0 ] ] }
.
.
.

Plugins

The DataPort features can be expanded with plugins. Plugins add
features that are common to specification class of applications.
Currently there are two DataPort plugins. The ‘shift’ plugin adds
features specific to sports related applications and the ‘monitor’
plugin adds features for applications that require long term event
monitoring (often in medical applications). Plugins are added to the
DataPort by Boditrak based on the target application. Each plug adds an
object to the API. So, for example, if the ‘shift’ plugin is installed
on the DataPort then the response to a |GET /api requesst will include a
‘shift’ object.

/api/shift

/api/shift/frames

This array is much like the base DataPort frames array. The
difference is the properties contained in each frame object. In addition
to ‘id’, ‘time’, and ‘readings’ the shift/frames frame objects includes
a few extra objects and values that are useful in sports applications.
The additional properties are as follows:

impact: this value is true for the first frame scanned after ball impact has been detected.
buttons: this value indicates which mat buttons are pressed; 0 indicates no
pressed buttons, 1 indicates that button 1 is pressed, 2 indicates that
button 2 is pressed, and 3 indicates that both buttons are pressed.
cop: this object contains information about the center-of-pressure’s
position (in mm), relative to the trailing heel corner of the mat and
velocity (in mm/s). Both position and velocity have an x and y
component. The positive x direction is (for a right-handed athlete) from
heel to toe. The positive y direction is from the trailing foot to the
lead foot.
steady: this object contains information about the COP and maximum pressure
the last time the athlete was standing still. The x and y values are the
coordinates of the COP (in mm) and the maximum value is the maximum
pressure applied to the mat at the last steady moment. If the athlete
steps off the mat the steady x,y values reset to the mat’s center and
the maximum is 100. The orthogonal axis for the ‘splits’ values
intersect at the steady x and y values. Often the maximum value is used
to scale a pressure heatmap in an applications UI.
splits: this object defines what portion of the athletes total force on the
mat lies in each of 4 quadrants. The axis of the quadrants intersect at
the steady x, y coordinates. The splits are expressed in percent and are
named according to an athlete whose left foot is their lead foot. That
is, the trailFoot value is the percentage of the total force that is on
the athlete’s trail foot (the split for their leadFoot is (100 –
trailFoot)). The leadHeel value is the

Request Response

Request	Response
`GET /api/shift/frames HTTP/1.1`	`HTTP/1.1 200 OK [ { "id":52, "time":"2015-12-31 20:23:41.615", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] } ]`

GET /api/shift/frames HTTP/1.1

HTTP/1.1 200 OK

[ { "id":52, "time":"2015-12-31 20:23:41.615", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] } ]

/api/shift/rebalance

This value is used to correct sensitivity differences between
different sections of the sensor pad. When enabled, readings taken from
the sensor pad are processed through a ‘rebalance’ filter that raises
readings from insensitive sections and lowers readings from
overly-sensitive sections.

A GET request for this value will return ‘true’ if the sensor pad has
a rebalance filter; ‘false’ otherwise. To remove a rebalance filter,
make a PUT request with the request’s content set to ‘false’.

To write a rebalance filter to the mat, make a PUT request with the request’s data set to an array of 2 or 4 or 6 values.

The array’s values are the sum of all sensors when standing on
different sections of the mat. For an array of 2 values, the first value
is the sum when standing on the lead-foot half of the mat, and the
second value is the sum when standing on the trail-foot half of the mat.
For an array of 4 values, the values are in this order: lead-heel,
lead-toe, trail-heel, trail-toe. For an array of 6 values, the values
are in this order: lead-heel, lead-toe, center-heel, center-toe,
trail-heel, trail-toe.

Request	Response
`GET /api/shift/rebalance HTTP/1.1`	`HTTP/1.1 200 OK true`
`PUT /api/shift/rebalance HTTP/1.1 [ 2233,3565,2747,4679 ]`	`HTTP/1.1 204 No content`

/api/shift/microphone

An object that represents the DataPort’s microphone. The DataPort
uses a microphone to detect ball impact. Impact detection is not yet
implemented in the hardware DataPort; it’s only available in the Windows
PC software DataPort.

Request	Response
`GET /api/shift/microphone HTTP/1.1`	`HTTP/1.1 200 OK { "id": 0, "sensitivity": 2 }`

/api/shift/microphone/id

If multiple microphones are connected to the DataPort then this value
indicates which microphone to use for impact detection. If this value
is 0 then the default microphone is used.

Request	Response
`GET /api/shift/microphone/id HTTP/1.1`	`HTTP/1.1 200 OK 0`
`PUT /api/shift/microphone/id HTTP/1.1 1`	`HTTP/1.1 204 No content`

/api/shift/microphone/sensitivity

The sensitivity determines what volume of sound is considered to
indicate ball impact. The values can range between 0 and 10. A
sensitivity value of 0 requires a very loud ball impact in order to be
detected. A sensitivity value of 10 will detect ball impact with a
slightest sound.

Request	Response
`GET /api/shift/microphone/sensitivity HTTP/1.1`	`HTTP/1.1 200 OK 2`
`PUT /api/shift/microphone/sensitivity HTTP/1.1 3`	`HTTP/1.1 204 No content`

/api/shift/buttonLayout

Indicates where the mat buttons are located on the mat. Possible
values are ‘none’, ‘toe-corners’, ‘toe-center’, ‘heel-corners’,
‘heel-center’.

Request	Response
`GET /api/shift/buttonLayout HTTP/1.1`	`HTTP/1.1 200 OK "toe-corners"`
`PUT /api/shift/buttonLayout HTTP/1.1 "toe-center"`	`HTTP/1.1 204 No content`

/api/shift/threshold

The minimum pressure reading value that will be included in the
center-of-pressure (COP) calculations. Pressure readings below this
value are excluded from the COP calculations.

Request	Response
`GET /api/shift/threshold HTTP/1.1`	`HTTP/1.1 200 OK 5`
`PUT /api/shift/threshold HTTP/1.1 3`	`HTTP/1.1 204 No content`

/api/shift/sse

Provides a stream of server-sent events. The only two event types are
the ‘sensor’ event and the ‘newframe’ event. The ‘sensor’ event is sent
when the connected sensor has changed. The data attached to the
‘sensor’ event is a simplified sensor object (the same object returned
by a ‘shift/sensor’ GET request). The ‘newframe’ event is sent whenever a
new frame is created. The data attached to the ‘newframe’ event is a
frame object (the same as an element of the ‘shift/frames’ array). A
‘newframe’ event is sent immediately after the DataPort scans it’s
sensor mats. The DataPort will continue to send ‘sensor’ and ‘newframe’
events as long as the connection remains open.

Request Response

Request	Response
`GET /api/shift/sse HTTP/1.1`	HTTP/1.1 200 OK event: sensor data: { "name":"BT7510-8125", "columns":16, "rows":25, "width":455, "height":710, "maximum":100 } event: newframe data: { "id":52, "time":"2015-12-31 20:23:41.615", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] } event: newframe data: { "id":53, "time":"2015-12-31 20:23:41.632", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0 ] } event: newframe data: { "id":54, "time":"2015-12-31 20:23:41.651", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] } event: newframe data: { "id":55, "time":"2015-12-31 20:23:41.668", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] } . . .

GET /api/shift/sse HTTP/1.1

HTTP/1.1 200 OK

event: sensor
data: { "name":"BT7510-8125", "columns":16, "rows":25, "width":455, "height":710, "maximum":100 }

event: newframe
data: { "id":52, "time":"2015-12-31 20:23:41.615", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] }

event: newframe
data: { "id":53, "time":"2015-12-31 20:23:41.632", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0 ] }

event: newframe
data: { "id":54, "time":"2015-12-31 20:23:41.651", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] }

event: newframe
data: { "id":55, "time":"2015-12-31 20:23:41.668", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] }
.
.
.

/api/monitor

This plugin is typically used in hospital beds. It records surface
pressure readings over long periods (tens of days) and keeps a running
tally of the risk of a pressure ulcer for each cell in the sensor. It
also keeps track of when a patient was last attended and can be used to
check if a patient is in bed and not close to the edge. It also provides
information about the state of the device itself; including storage
space and sensor connectivity.

Request Response

Request	Response
`GET /api/monitor HTTP/1.1`	`HTTP/1.1 200 OK { "risk":{ "threshold":20, "accelerate":10, "maximum":300, "level":0, "countdown":10000, "ok":true }, "attended":{ "interval":7200, "countdown":-4606, "ok":false }, "body":{ "weight":77, "present":false, "ok":false }, "sensors":{ "minimum":1, "ok":true }, "storage":{ "frequency":6, "used":9, "countdown":652986, "ok":true }, "frames":[ { "id":11169, "time":"2016-01-19 00:45:46.424", "readings":[ [ 0,0,0,...,0,0,0 ] ], "risks":[ [ 0,0,0,...,0,0,0 ] ] } ] }`

GET /api/monitor HTTP/1.1

HTTP/1.1 200 OK

{ "risk":{ "threshold":20, "accelerate":10, "maximum":300, "level":0, "countdown":10000, "ok":true }, "attended":{ "interval":7200, "countdown":-4606, "ok":false }, "body":{ "weight":77, "present":false, "ok":false }, "sensors":{ "minimum":1, "ok":true }, "storage":{ "frequency":6, "used":9, "countdown":652986, "ok":true }, "frames":[ { "id":11169, "time":"2016-01-19 00:45:46.424", "readings":[ [ 0,0,0,...,0,0,0 ] ], "risks":[ [ 0,0,0,...,0,0,0 ] ] } ] }

/api/monitor/frames

The recorded frames as an array of objects. The frames are much like
/api/frames but include a risks array with risk values for each cell in
the sensor. The pressure readings in these frames may have been altered
by the weight correction feature. The set of frames returned by a GET
request can be controlled by several optional parameters. They include
the following:

before: specifies a frame id; the response will consist of all frames recorded before the specified frame
after: specifies a frame id; the response will consist of all frames recorded after the specified frame
id: specifies a frame id; the response will consist of the frame with the matching id
exclude: use ‘readings’ to exclude readings from the returned
frames; use ‘risks’ to exclude risks from the returned frames; use
‘readings+risks’ to exclude both readings and risks

If both ‘before’ and ‘after’ are specified then the response will
consist of all frames recorded between the two ids. If neither ‘id’,
‘before’, or ‘after’ are specified then the response will contain the
last recorded frame. The response will include no more than 300 frames
unless ‘before’ and ‘after’ are specified and the number of frames
within that range is greater than 300.

In order to retrieve a large number of recorded frames it is
recommended to query for frames in groups of 300 or less. One way to do
this is to query for /api/monitor/frames?id=0 to get the first frame;
then query for /api/monitor/frames?after=0 to get the 300 frames after
frame 0; then query for /api/monitor/frames?after=300 to get the 300
frames after frame 300; repeat until you’ve retrieve all the frames
needed.

Use HTTP DELETE to delete all the recorded frames.

Request Response

Request	Response
`GET /api/monitor/frames HTTP/1.1`	`HTTP/1.1 200 OK [ { "id":1, "time":"2016-01-01 01:15:05.858", "readings":[ [ 0,0,0,...,0,0,0 ] ], "risks":[ [ 0,0,0,...,0,0,0 ] ] } ]`
`DELETE /api/monitor/frames HTTP/1.1`	`HTTP/1.1 204 No content`

GET /api/monitor/frames HTTP/1.1

HTTP/1.1 200 OK

[ { "id":1, "time":"2016-01-01 01:15:05.858", "readings":[ [ 0,0,0,...,0,0,0 ] ], "risks":[ [ 0,0,0,...,0,0,0 ] ] } ]

DELETE /api/monitor/frames HTTP/1.1

HTTP/1.1 204 No content

/api/monitor/attended

This object describes the details of the DataPort’s attendance timer
(aka turn timer). The attendance timer simply keeps track of the last
time the patient was attended to (and/or turned).

Request	Response
`GET /api/monitor/attended HTTP/1.1`	`HTTP/1.1 200 OK { "interval":7200, "countdown":7190, "ok":true }`

/api/monitor/attended/interval

The number of seconds that the countdown value is set to when the
attended timer is reset (by PUTting monitor/attended/ok to true).

Request \| \|Response
`GET /api/monitor/attended/interval HTTP/1.1`	`HTTP/1.1 200 OK 3600`
`PUT /api/monitor/attended/interval HTTP/1.1 7200`	`HTTP/1.1 204 No content`

/api/monitor/attended/countdown

The number of seconds until the ok value will be set to false.

Request	Response
`GET /api/monitor/attended/countdown HTTP/1.1`	`HTTP/1.1 200 OK 3624`

/api/monitor/attended/ok

This value is false when the countdown value is less than 1 (ie timer
has run out); it’s true otherwise. This value can be PUT to true which
will cause the countdown value to be set to the interval value
(resetting the timer).

Request	Response
`GET /api/monitor/attended/ok HTTP/1.1`	`HTTP/1.1 200 OK false`
`PUT /api/monitor/attended/ok HTTP/1.1 true`	`HTTP/1.1 204 No content`

/api/monitor/storage

This object describes the details of the DataPort’s storage facility. The storage is used to record frame data.

Request	Response
`GET /api/monitor/storage HTTP/1.1`	`HTTP/1.1 200 OK { "frequency":6, "used":9, "countdown":652986, "ok":true }`

/api/monitor/storage/frequency

The rate at which frames will be stored (in frames per hour). Storage
is limited to 120000 frames so an application should select a frequency
value that won’t reach this number of frames before having the frames
offloaded and deleted from the DataPort storage.

Request	Response
`GET /api/monitor/storage/frequency HTTP/1.1`	`HTTP/1.1 200 OK 6`
`PUT /api/monitor/storage/frequency HTTP/1.1 60`	`HTTP/1.1 204 No content`

/api/monitor/storage/used

The amount of storage used relative to the maximum storage; expressed as a percent.

Request	Response
`GET /api/monitor/storage/used HTTP/1.1`	`HTTP/1.1 200 OK 9`

/api/monitor/storage/countdown

The number of seconds before the storage will be completely used.

Request	Response
`GET /api/monitor/storage/countdown HTTP/1.1`	`HTTP/1.1 200 OK 652986`

/api/monitor/storage/ok

A value of ‘false’ indicates that the storage is completely full; otherwise it’s ‘true’.

Request	Response
`GET /api/monitor/storage/ok HTTP/1.1`	`HTTP/1.1 200 OK true`

/api/monitor/risk

This object describes the details of the DataPort’s risk monitoring
feature. Risk accumulates as a function of pressure and time.

Request	Response
`GET /api/monitor/risk HTTP/1.1`	`HTTP/1.1 200 OK { "threshold":20, "accelerate":10, "maximum":300, "level":0, "countdown":10000, "ok":true }`

/api/monitor/risk/threshold

The pressure value (in mmHg) above which the risk of a pressure ulcer
is considered to be rising. If the pressure reading from a sensor is
above this threshold the risk for that particular sensor will increase
over time. If the pressure reading from a sensor is below this threshold
the risk for that particular sensor will decrease over time.

Request	Response
`GET /api/monitor/risk/threshold HTTP/1.1`	`HTTP/1.1 200 OK 20`
`PUT /api/monitor/risk/threshold HTTP/1.1 10`	`HTTP/1.1 204 No content`

/api/monitor/risk/accelerate

Accelerates the rate at which the risk values accumulate. Normally
this value is 1 but to demonstrate how risk accumulates this value can
be set to a value greater than 1 (typically between 10 and 100). This
value should only be set to something other than 1 when demonstrating
the feature. It must be 1 under normal operation.

Request	Response
`GET /api/monitor/risk/accelerate HTTP/1.1`	`HTTP/1.1 200 OK 1`
`PUT /api/monitor/risk/accelerate HTTP/1.1 \|HTTP/1. 10`	`1 204 No content`

/api/monitor/risk/maximum

The maximum safe level of risk (in mmHg*hours). According to Reswick-Rogers this value should be 300 but it can be changed.

Request	Response
`GET /api/monitor/risk/maximum HTTP/1.1 \| HTTP/1.1`	`200 OK 300`
`PUT /api/monitor/risk/maximum HTTP/1.1 \|HTTP/1.1 2 250`	`04 No content`

/api/monitor/risk/level

The current level of risk (in mmHg*hours).

Request	Response
`GET /api/monitor/risk/level HTTP/1.1`	`HTTP/1.1 200 OK 0`

/api/monitor/risk/countdown

The number of seconds until the risk level is expected to reach the
risk maximum. This value doesn’t necessarily decrement once per second;
it can vary up and down depending on the load on the sensor array. If
the value is 10000 it means, under the current load, it will a very long
time, if ever, to reach the risk maximum.

Request	Response
`GET /api/monitor/risk/countdown HTTP/1.1`	`\|HTTP/1.1 200 OK 10000`

/api/monitor/risk/reset

Set this value to true to set all risks values to zero. This value is write-only.

Request	Response
`PUT /api/monitor/risk/reset HTTP/1.1 true`	`HTTP/1.1 204 No content`

/api/monitor/risk/ok

This value is ‘false’ when the risk level is above the risk maximum; otherwise it’s ‘true’.

Request	Response
`GET /api/monitor/risk/ok HTTP/1.1`	`HTTP/1.1 200 OK true`

/api/monitor/body

This object describes a few details about the body on the mattress.

Request	Response
`GET /api/monitor/body HTTP/1.1`	`HTTP/1.1 200 OK { "weight":77, "present":false, "ok":false }`

/api/monitor/body/weight

The weight (in kg) of the person who’s laying on the mattress. This
value is used to scale the sensor readings up/down appropriately so that
the total of all the forces on all the sensors in the array(s) add up
to the person’s weight. If this value is 0 then the monitor plugin will
not scale the readings.

Request	Response
`GET /api/monitor/body/weight HTTP/1.1`	`HTTP/1.1 200 OK 0`
`PUT /api/monitor/body/weight HTTP/1.1 75`	`HTTP/1.1 204 No content`

/api/monitor/body/present

This value is ‘false’ when it appears that no one is on the mattress; ‘true’ otherwise.

Request	Response
`GET /api/monitor/body/present HTTP/1.1`	`HTTP/1.1 200 OK true`

/api/monitor/body/ok

This value is ‘false’ when it appears that no one is on the mattress or, if there is, they’re near the edge; ‘true’ otherwise.

Request	Response
`GET /api/monitor/body/ok HTTP/1.1`	`HTTP/1.1 200 OK true`

/api/monitor/sensors

This object simply indicates how many sensors are expected to be
connected to the DataPort and indicates whether the appropraite number
of sensors is connected.

Request	Response
`GET /api/monitor/sensors HTTP/1.1`	`HTTP/1.1 200 OK { "minimum":1, "ok":true }`

/api/monitor/sensors/minimum

The minimum number of sensors that should be connected to the DataPort.

Request	Response
`GET /api/monitor/sensors/minimum HTTP/1.1`	`HTTP/1.1 200 OK 1`
`PUT /api/monitor/sensors/minimum HTTP/1.1 \|HTTP/1. 2`	`1 204 No content`

/api/monitor/sensors/ok

This value is ‘false’ if the number of connected sensors is less than the minimum; ‘true’ otherwise.

Request	Response
`GET /api/monitor/sensors/ok HTTP/1.1`	`HTTP/1.1 200 OK true`

/api/monitor/sse

Provides a stream of server-sent events. The event sent are
‘newframe’, ‘risk’, ‘attended’, ‘body’, ‘sensors’, and ‘storage’. The
data attached to the ‘newframe’ event is a frame object (the same format
as an element of the ‘monitor/frames’ array). A ‘newframe’ event is
sent immediately after the DataPort scans it’s sensor mats. It isn’t
just sent when the frame is stored. The monitor plugin will continue to
send ‘newframe’ events as long as the connection remains open. The
‘risk’ event is sent when the monitor/risk object changes; it’s data is a
risk object. The ‘attended’ event is sent when the monitor/attended
object changes; it’s data is an attended object. The ‘body’ event is
sent when the monitor/body object changes; it’s data is a body object.
The ‘sensors’ event is sent when the monitor/sensors object changes;
it’s data is a sensors object. The ‘storage’ event is sent when the
monitor/storage object changes; it’s data is a storage object.

Request Response

GET /api/shift/sse HTTP/1.1

HTTP/1.1 200 OK

event: risk
data: { "threshold":20, "accelerate":10, "maximum":300, "level":0, "countdown":10000, "ok":true }

event: attended
data: { "interval":7200, "countdown":-4606, "ok":false }

event: body
data: { "weight":77, "present":false, "ok":false }

event: sensors
data: { "minimum":1, "ok":true }

event: storage
data: { "frequency":6, "used":9, "countdown":652986, "ok":true }

event: newframe
data: { "id":55, "time":"2015-12-31 20:23:41.668", "impact":false, "buttons":0, "cop":{ "position":{ "x":228, "y":355 }, "velocity":{ "x":0, "y":0 } }, "steady":{ "x":228, "y":355, "maximum":100 }, "splits":{ "leadHeel": 50, "trailHeel":50, "trailFoot":50 }, "readings":[ 0,0,0, ... ,0,0,0 ] }
.
.
.

MENU

BodiTrakのAPI

DataPort API（日本語）

Overview

/api

/api/device

/api/sensors

/api/frames

/api/frequency

/api/sensorsRequired

/api/filters

/api/filters/spot

/api/filters/smooth

/api/filters/noise

/api/power

/api/power/state

/api/power/level

/api/time

/api/wifi

/api/wifi/mode

/api/wifi/ssid

/api/firmware

/api/firmware/version

/api/firmware/upgrade

/api/firmware/package

/api/firmware/source

/api/sse

Plugins

/api/shift

/api/shift/frames

/api/shift/rebalance

/api/shift/microphone

/api/shift/microphone/id

/api/shift/microphone/sensitivity

/api/shift/buttonLayout

/api/shift/threshold

/api/shift/sse

/api/monitor

/api/monitor/frames

/api/monitor/attended

/api/monitor/attended/interval

/api/monitor/attended/countdown

/api/monitor/attended/ok

/api/monitor/storage

/api/monitor/storage/frequency

/api/monitor/storage/used

/api/monitor/storage/countdown

/api/monitor/storage/ok

/api/monitor/risk

/api/monitor/risk/threshold

/api/monitor/risk/accelerate

/api/monitor/risk/maximum

/api/monitor/risk/level

/api/monitor/risk/countdown

/api/monitor/risk/reset

/api/monitor/risk/ok

/api/monitor/body

/api/monitor/body/weight

/api/monitor/body/present

/api/monitor/body/ok

/api/monitor/sensors

/api/monitor/sensors/minimum

/api/monitor/sensors/ok

/api/monitor/sse