Some brief notes on the REST endpoints used by this library.
Initial authentication to the smartbox REST API is protected by HTTP Basic Auth, in addition to the user's username and password which are then used to obtain an access token. In order not to undermine the security layer it provides, and also because it might change over time or vary between implementations, the token is not provided here and system owners need to find it themselves.
POST: needs basic auth token provided in the Authorization
header. See code
for access token and refresh protocol.
The endpoints below need the access token obtained from the token endpoint (see code), which lasts for four hours before needing to be refreshed.
GET: list devices
GET: list devices with extra grouping info
POST: TODO untested
GET: Appears to be all device data, including most of the information obtainable via specific endpoints below.
POST: TODO untested
GET: device geolocation data
POST: TODO untested
GET: device connection status
POST: TODO untested
GET: device away status
POST: TODO untested
GET: device discovery status
POST: TODO untested
GET: heater power limit info
POST: TODO untested
GET: device date and time info
POST: TODO untested
Note: node type apparently can be htr
, thm
or acm
(only htr tested).
GET: lists nodes
GET: Appears to be all node data, including most of the information obtainable via specific endpoints below.
POST: TODO untested
GET: get node status
POST: update node status. Only fields that are changing need to be supplied,
but units
must be provided with any temperature fields.
GET: get node programme
POST: TODO untested
GET: get node type
POST: TODO untested
GET: get node version info (firmware version etc)
POST: TODO untested
GET: get node setup
POST: update node setup. Apparently all fields need to be provided even if unchanged.
GET: TODO: untested
POST: TODO: untested
Get version info
This uses the socket.io protocol.
Briefly:
- The socket session is per device
- The access token and device ID must be supplied as query params
- On successful connection, the client should emit a
dev_data
event. The corresponding response from the server is similar to the dev_data REST endpoint above - The server will send periodic
update
events containing device and node status updates - The client should send a
ping
message every 20s (in addition to the protocol level ping/pong). Have not tested that this is strictly necessary.
Similar to the node status API endpoints above, one per node.
Message content is the same structure as the away_status
device API, or the
corresponding field in the dev_data
message or REST endpoint.