WeeRT is a realtime extension for WeeWX, open-source software for your weather station. It consists of three, independent parts:
- The WeeRT uploader. This is a WeeWX service, which arranges for your data to be uploaded from WeeWX to the WeeRT server.
- The WeeRT server, a real-time logging and display server, written in Javascript and running on Node, using the Express framework. This server listens for real-time data updates from WeeWX, then archives them in an InfluxDB database. It also acts as a webserver for the WeeRT client.
- The WeeRT browser client, written in Javascript using React and Redux. It runs in a browser and interacts with the WeeRT server.
The following diagram illustrates the relationships between the three different pieces:
This utility is still EXPERIMENTAL, and will require some skill to install and administer.
In order to use WeeRT, there are three separate install and build procedures:
- Install the WeeRT server.
- Install the WeeRT uploader on WeeWX. This will post LOOP packets to the WeeRT server.
- Build the WeeRT client, which will run on a browser.
Instructions follow.
-
Due to a limitation in WeeRT, the timezone of your server must be the same as your hardware. Hopefully, this limitation can be lifted in the future. To change the timezone on Debian based operating systems:
$ sudo dpkg-reconfigure tzdata
-
Install InfluxDB. WeeRT was tested with version 1.8.10. In particular, InfluxDB Version 2.x will not work! The following works on Ubuntu.
sudo apt install influxdb
-
If necessary, start it by whatever means is needed for your operating system. This works on Ubuntu 22.04:
$ systemctl start influxdb
-
Download and install node. WeeRT was tested with version 18.10.0, also known as LTS/Gallium. Later versions should work fine.
-
Download WeeRT from the git repository
$ git clone https://github.com/tkeffer/weert-js.git
-
Enter the WeeRT sub-directory, and install the server dependencies
$ cd weert-js $ npm install -
Start the WeeRT server
$ npm run start Listening on port 3000
-
To run the test suites, in another shell download and install
jasmineglobally$ npm install -g jasmine
-
Run the suites
$ npm run test
The job of the uploader is to post LOOP packets to the WeeRT server (installed above).
-
Make sure you are running WeeWX V3.8 or later. Earlier versions do not support the POST method used by the uploader.
-
Put the
weert.pymodule (located in theweewx_extensionssubdirectory) in the WeeWXusersubdirectory. -
Add the following to
weewx.conf:[StdRestful] ... [[WeeRT]] host = localhost port = 3000 user = weert password = weert ... [Engine] [[Services]] ... restful_services = ..., user.weert.WeeRT
-
Run
weewxd
-
Install, then build the client libraries.
cd client npm install npm run build -
After making sure the WeeRT server is still running, open up a client at http://localhost:3000.
- The WeeRT server runs on Node using the Express framework.
- The server offers a RESTful API (described below) for storing, retrieving, and deleting data measurements.
- Data are stored in an InfluxDB server.
- Realtime updates are done through a publish - subscribe interface using Socket.io.
- The client asks for the necessary data through the API, then subscribes to any updates.
- The client view is managed by React.
- The client data state is managed by Redux.
- Realtime plots are done using Recharts, a charting library, which uses React to create DOM elements. As of 15-Feb-2018 it is still in beta, but seems reasonably stable.
When new LOOP packets come into WeeRT through the POST interface, they are published using Socket.io (an implementation of WebSockets). Interested clients can subscribe to these publications.
Every 5 minutes (configurable), the WeeRT server subsamples the raw, loop, data,
converting it into evenly spaced records. See file config/ss_policies.js for the subsampling
policies. By default, it is run every 5 minutes, uses measurement 'wxpackets' for its source,
and measurement 'wxrecords' as its destination.
The retention time of the LOOP packets is set by a configuration file, but the default is 24 hours. After that, they are discarded.
If you wish to query the database directly using the influx command-line client, you must attach the retention policy name. For example, to see all packets a typical session might look like (user inputs are in bold):
$ influx -username weert -password weertL Connected to http://localhost:8086 version 1.8.10 InfluxDB shell version: 1.8.10 > use weert; > select * from h24.wxpackets limit 5; name: wxpackets time altimeter_pressure console_voltage dewpoint_temperature extra1_temperature gauge_pressure heatindex_temperature in_humidity_percent in_temperature out_humidity_percent out_temperature platform radiation_radiation rain_rain sealevel_pressure stream unit_system uv_uv wind_dir wind_speed windchill_temperature x_wind_speed y_wind_speed ---- ------------------ --------------- -------------------- ------------------ -------------- --------------------- ------------------- -------------- -------------------- --------------- -------- ------------------- --------- ----------------- ------ ----------- ----- -------- ---------- --------------------- ------------ ------------ 1665142885000000000 30.225527640402586 4.81 46.7763303997396 30 29.467510004692507 49.339 52 69.7 87 50.5 default_platform 0 0 30.207 default_stream 1 0 0 50.5 1665142887000000000 30.226523472560547 4.81 46.7763303997396 30 29.468485523943166 49.339 51 69.7 87 50.5 default_platform 0 0 30.208 default_stream 1 0 0 50.5 1665142889000000000 30.226523472560547 4.81 46.7763303997396 30 29.468485523943166 49.339 51 69.7 87 50.5 default_platform 0 0 30.208 default_stream 1 0 0 50.5 1665142891000000000 30.226523472560547 4.81 46.7763303997396 30 29.468485523943166 49.339 51 69.7 87 50.5 default_platform 0 0 30.208 default_stream 1 0 0 50.5 1665142893000000000 30.226523472560547 4.81 46.7763303997396 30 29.468485523943166 49.339 51 69.7 87 50.5 default_platform 0 0 30.208 default_stream 1 0 0 50.5
Note how the query asked for measurement h24.wxpackets, where h24 is the default retention policy
used by WeeRT.
WeeRT can make voluminous entries into your system log. The WeeWX uploader will make an entry every LOOP packet, as does the InfluxDB database. This can mean thousands of entries per hour.
The number of uploader entries can be drastically reduced by
using option log_success:
[StdRestful]
...
[[WeeRT]]
...
log_success = falseConsult the InfluxDB configuration documentation for how to control its logging policies.
WeeRT uses a different system to name observation types than WeeWX.
For example, for outside temperature, WeeWX uses outTemp, while
WeeRT uses out_temperature. The general pattern is that the last
part of the observation name, temperature in this example, denotes
the unit group. In WeeWX the unit group must be looked up in a table;
in WeeRT it can be inferred from the name.
Which brings us to the next topic...
Internally, the WeeRT server makes no assumptions about units.
The client is unit-agnostic, except for the WindCompass, which assumes US Customary.
The server requires authentication for any mutating actions, that is,
any POSTs or DELETEs. The default configuration (file
server/config/config.js) includes a user weert with password
weert. These should, obviously, be changed.
The configuration for the WeeWX uploader in weewx.conf should be
changed to match the chosen username and password.
It is strongly recommended that you read the "key concepts" section of the InfluxDB documentation. In particular, be sure to understand the concepts of measurements, tags, and fields. These terms are used throughout WeeRT.
WeeRT stores incoming real-time packets into measurement
wxpackets. These are then aggregated and subsampled regularly
(typically, every 5 minutes) into another measurement, wxrecords.
Data in wxpackets use a 24 hour retention policy --- they are purged
if older than 24 hours. Data in wxrecords are retained
indefinitely.
InfluxDB does not use a schema. Nevertheless, data is organized in a
structured, organized way. Both wxpackets and wxrecords use
identical structures.
WeeRT uses two InfluxDB tags: platform and stream. The former,
platform, is intended to represent a physical presence, such as a
house, car, or piece of industrial machinery. The latter, stream,
represents a data stream within the platform, such as a specific
weather station, or sensor. Like any InfluxDB tags, platform and
stream are indexed. The default platform is default_platform;
the default stream is default_stream.
The observation values, such as out_temperature, are stored as
InfluxDB fields. They are not indexed. Because InfluxDB does not
use a schema, new data types can be introduced into the data stream at
any time and they will be stored in the database.
The observation time is stored as field time in the database.
There are several different ways of representing packet data in the WeeRT / Influx ecosystem. It's useful to be aware of the differences.
-
A weewx-style packet. This is the simple, flat data structure that weewx uses. It holds time (in integer seconds), field data, and the unit system used by the data, but no information about platforms or streams. It looks like:
{ "dateTime" : 1507432417, "outTemp" : 20.5, "outHumidity" : 65.0, "usUnits" : 16 } -
What we are calling a deep packet. This is a structured packet that the Node client library node-influx expects (as do the InfluxDB client libraries for most other languages). It is useful because the InfluxDB "measurement" and "tags" are explicitly represented. Time is in field
timeand it is in milliseconds. It looks something like this:{ "timestamp" : 1507432417000, "measurement" : "wxpackets", "tags" : {"platform" : "Red barn", "stream" : "Accurite"}, "fields" : {"out_temperature" : 20.5, "out_humidity_percent" : 65.0, "unit_system" : 16} } -
What we are calling a flattened packet. This is what is returned from the
queryfunction of node-influx. Unfortunately, it is slightly different from a deep packet. The tag members have been flattened in with the field data, and the time is now in fieldtime:{ "time" : 1507432417000, "measurement" : "wxpackets", "platform" : "Red barn", "stream" : "Accurite", "out_temperature" : 20.5, "out_humidity_percent" : 65.0, "unit_system" : 16 } -
The InfluxDB line protocol. This protocol is designed for on-the-wire efficiency. It is not explicitly used within WeeRT. It looks something like this:
wxpackets,platform="Red barn",stream="Accurite" out_temperature=20.5,out_humidity_percent=65.0,unit_system=16 1507432417000000000
WeeRT tries to consistently traffic in "deep packets," and does any conversions that might be necessary. Both incoming and outgoing data use this format.
All mutating calls (POSTs and DELETEs) must be authorized through
an Authorization header. It should include
the word Basic, followed by the base64 encoding of the username and password
with a colon in between. In Python, this looks like:
import urllib2, base64
...
request = urllib2.Request(url)
base64string = base64.b64encode('%s:%s' % ('johndoe', 'mysecretpassword'))
request.add_header("Authorization", "Basic %s" % base64string)Using curl, this can be done by adding the -u option, which is done in
the mutating examples below.
Return all packets from a series that satisfy a search query.
GET /api/v1/measurements/:measurement/packets
Parameters
| Name | Type | Description |
|---|---|---|
platform |
string | Include only packets from platform platform. |
stream |
string | Include only packets from stream stream. |
start |
integer | All packets greater than this timestamp in milliseconds will be included in the results. Default: first available packet. |
stop |
integer | All packets less than or equal to this timestamp in milliseconds will be included in the results. Default: last available packet. |
limit |
integer | Limit the number of returned packets to this value. Default: no limit. |
direction |
string | The direction of the sort. Can be either asc or desc. Default: asc. |
group |
string | Group by time (e.g. '1h''). This will perform a server-defined aggregation for each observation type. |
Response code
| Status | Meaning |
|---|---|
| 200 | Success |
| 400 | Malformed query |
Examples
Ask for all the packets in the measurement examples. This is the entire example database.
$ curl -i --silent -X GET 'http://localhost:3000/api/v1/measurements/examples/packets'
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 1199
ETag: W/"4af-L0UIsq5sC4PTfrENfRMN2W/ZRN4"
Vary: Accept-Encoding
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
[
{
"fields": {
"out_temperature": 55.2,
"sealevel_pressure": 29.812,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "accurite"
},
"timestamp": 1506713140000
},
{
"fields": {
"out_temperature": 61.2,
"sealevel_pressure": 29.881,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "loft"
},
"timestamp": 1506713140000
},
{
"fields": {
"out_temperature": 55.3,
"sealevel_pressure": 29.839,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "accurite"
},
"timestamp": 1506713200000
},
{
"fields": {
"out_temperature": 61.3,
"sealevel_pressure": 29.901,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "loft"
},
"timestamp": 1506713200000
},
{
"fields": {
"out_temperature": 55.5,
"sealevel_pressure": 29.84,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "accurite"
},
"timestamp": 1506713260000
},
{
"fields": {
"out_temperature": 61.6,
"sealevel_pressure": 29.908,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "loft"
},
"timestamp": 1506713260000
},
{
"fields": {
"out_temperature": 55.6,
"sealevel_pressure": 29.838,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "accurite"
},
"timestamp": 1506713320000
},
{
"fields": {
"out_temperature": 61.6,
"sealevel_pressure": 29.91,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "loft"
},
"timestamp": 1506713320000
}
]
Query again, but this time ask for only those packets on stream loft, and limit it
to 2 packets:
$ curl -i --silent -X GET 'http://localhost:3000/api/v1/measurements/examples/packets?stream=loft&limit=2'
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 297
ETag: W/"129-idTpnNGWyDv2HF/iWVXjfjypa6c"
Vary: Accept-Encoding
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
[
{
"fields": {
"out_temperature": 61.2,
"sealevel_pressure": 29.881,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "loft"
},
"timestamp": 1506713140000
},
{
"fields": {
"out_temperature": 61.3,
"sealevel_pressure": 29.901,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "loft"
},
"timestamp": 1506713200000
}
]
Query, constraining by time and stream name, returning results in reverse order:
$ curl -i -X GET 'http://localhost:3000/api/v1/measurements/examples/packets?start=1506713140000&stop=1506713260000&stream=loft&direction=desc'
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 297
ETag: W/"129-7ngYWuleRY7fPIgWhooZwkCBK0w"
Vary: Accept-Encoding
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
[
{
"fields": {
"out_temperature": 61.6,
"sealevel_pressure": 29.908,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "loft"
},
"timestamp": 1506713260000
},
{
"fields": {
"out_temperature": 61.3,
"sealevel_pressure": 29.901,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "loft"
},
"timestamp": 1506713200000
}
]
Return packets with a specific timestamp.
GET /api/v1/measurements/:measurement/packets/:timestamp
Parameters
| Name | Type | Description |
|---|---|---|
platform |
string | Include only packets on the platform platform. |
stream |
string | Include only packets on the stream stream. |
Response code
| Status | Meaning |
|---|---|
| 200 | Success |
| 400 | Malformed query |
| 404 | Measurement does not exist |
Example
Get all packets at timestamp 1506713200000 on the stream accurite.
$ curl -i -X GET 'http://localhost:3000/api/v1/measurements/examples/packets/1506713200000?stream=accurite'
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 153
ETag: W/"99-J5xEyWItQGPLhwz5OEdZrKYl/HU"
Vary: Accept-Encoding
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
[
{
"fields": {
"out_temperature": 55.3,
"sealevel_pressure": 29.839,
"unit_system": 1
},
"tags": {
"platform": "barn",
"stream": "accurite"
},
"timestamp": 1506713200000
}
]
Post a new packet.
POST /api/v1/measurements/:measurement/packets
Header
The HTTP request must include an Authorization header.
JSON input
A deep packet must be included in the body of the request.
The packet need not include a value for measurement, but, if included,
it must match the value given in the URL.
The packet must include a value for timestamp in milliseconds.
Any fields with a null value will be ignored and not inserted into the
database.
Response code
| Status | Meaning |
|---|---|
| 201 | Created |
| 400 | Malformed post |
| 415 | Invalid or missing Content-type |
If successful, the server will return a response code of 201, with the
response Location field set to the URL of the newly created resource (packet).
Example
Add a new packet for the platform barn and stream accurite.
$ curl -u weert:weert -i --silent -X POST -H Content-type:application/json -d \
> '{"timestamp" : 1506713320000, \
> "tags" : {"platform":"barn", "stream":"accurite"}, \
> "fields" : {"unit_system":1, "out_temperature":56.1, "sealevel_pressure": 29.881}} ' \
> http://localhost:3000/api/v1/measurements/examples/packets
HTTP/1.1 201 Created
X-Powered-By: Express
Location: http://localhost:3000/api/v1/measurements/examples/packets/1506713320000
Content-Type: text/plain; charset=utf-8
Content-Length: 7
ETag: W/"7-rM9AyJuqT6iOan/xHh+AW+7K/T8"
Vary: Accept-Encoding
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
CreatedNote how the URL of the new resource is returned in the header Location.
Delete packets with a specific timestamp.
DELETE /api/v1/measurements/:measurement/packets/:timestamp
Header
The HTTP request must include an Authorization header.
Parameters
| Name | Type | Description |
|---|---|---|
platform |
string | Delete only packets on the platform platform. |
stream |
string | Delete only packets on the stream stream. |
Response code
| Status | Meaning |
|---|---|
| 204 | Success |
The same response code (204) is returned irregardless of whether or not any packet fitting the criteria actually existed in the database.
Example
Delete all packets with timestamp 1506713320000.
$ curl -u weert:weert -i --silent -X DELETE http://localhost:3000/api/v1/measurements/examples/packets/1506713320000
HTTP/1.1 204 No Content
X-Powered-By: Express
ETag: W/"a-bAsFyilMr4Ra1hIU5PyoyFRunpI"
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
Query the database for information about an InfluxDB measurement.
GET /api/v1/measurements/:measurement
Response code
| Status | Meaning |
|---|---|
| 200 | Success |
| 404 | Measurement not found |
If successful, the server will return an array whose elements are the series
in measurement measurement.
Examples
Get information about the measurement examples.
$ curl -i --silent -X GET 'http://localhost:3000/api/v1/measurements/examples'
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 77
ETag: W/"4d-1amwyw0DG1fpJrxME60jbdepTSc"
Vary: Accept-Encoding
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
[
{
"platform": "barn",
"stream": "accurite"
},
{
"platform": "barn",
"stream": "loft"
}
]
Do the example again, but using a bogus measurement name. It returns a 404 "Not Found" status code.
$ curl -i --silent -X GET http://localhost:3000/api/v1/measurements/foo
HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Type: text/plain; charset=utf-8
Content-Length: 9
ETag: W/"9-0gXL1ngzMqISxa6S1zx3F4wtLyg"
Vary: Accept-Encoding
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
Not FoundReturn general statistics about a measurement
GET /api/v1/measurements/:measurement/stats
Parameters
| Name | Type | Description |
|---|---|---|
platform |
string | Include only data from platform platform. Default is to include all platforms. |
stream |
string | Include only data from stream stream. Default is to include all streams. |
span |
string | Return statistics for the given time span. Choices are day,week, month or year. Required. |
now |
integer | This variable is a time in nanoseconds somewhere in that span. Default is the present time. |
Response code
| Status | Meaning |
|---|---|
| 200 | Success |
| 400 | Malformed query |
Example
Get the statistics for the day surrounding the sample data. Note that only a handful of the returned values are non-null. This is because statistics, unlike other queries, require a schema to specify not only which types are to be returned, but also which aggregations are to be run against those types.
For the sample data, most of these types were not inserted into the database. Hence, their statistics are null.
See file server/config/stats_policies.js for the schema.
$ curl -i --silent -X GET 'http://localhost:3000/api/v1/measurements/examples/stats?span=day&now=1506713200000'
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 1828
ETag: W/"724-nvlqRtRGm24tJxyFf+cb85k9IBI"
Vary: Accept-Encoding
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
{
"altimeter_pressure": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"dewpoint_temperature": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"extra1_humidity_percent": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"extra1_temperature": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"gauge_pressure": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"heatindex_temperature": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"in_humidity_percent": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"in_temperature": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"out_humidity_percent": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"out_temperature": {
"max": {
"timestamp": 1506713260000,
"value": 61.6
},
"min": {
"timestamp": 1506713140000,
"value": 55.2
}
},
"radiation_radiation": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"rain_rain": {
"sum": {
"value": null
}
},
"sealevel_pressure": {
"max": {
"timestamp": 1506713260000,
"value": 29.908
},
"min": {
"timestamp": 1506713140000,
"value": 29.812
}
},
"unit_system": {
"max": {
"timestamp": 1506713140000,
"value": 1
},
"min": {
"timestamp": 1506713140000,
"value": 1
}
},
"uv_uv": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"wind_speed": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"windchill_temperature": {
"max": {
"timestamp": null,
"value": null
},
"min": {
"timestamp": null,
"value": null
}
},
"windgust_speed": {
"max": {
"timestamp": null,
"value": null
}
},
"x_wind_speed": {
"count": {
"value": null
},
"sum": {
"value": null
}
},
"y_wind_speed": {
"count": {
"value": null
},
"sum": {
"value": null
}
}
}
Delete a measurement from the InfluxDB database.
DELETE ap/v1/measurements/:measurement
Header
The HTTP request must include an Authorization header.
Return status
| Status | Meaning |
|---|---|
| 204 | Success / NO CONTENT |
Examples
Delete the measurement examples. All packets within the measurement will be deleted.
$ curl -u weert:weert -i --silent -X DELETE 'http://localhost:3000/api/v1/measurements/examples'
HTTP/1.1 204 No Content
X-Powered-By: Express
ETag: W/"a-bAsFyilMr4Ra1hIU5PyoyFRunpI"
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
Do the example again, but using a bogus measurement name. It should return the same status code, 204.
$ curl -u weert:weert -i --silent -X DELETE 'http://localhost:3000/api/v1/measurements/foo'
HTTP/1.1 204 No Content
X-Powered-By: Express
ETag: W/"a-bAsFyilMr4Ra1hIU5PyoyFRunpI"
Date: Sat, 10 Mar 2018 22:53:29 GMT
Connection: keep-alive
Return information about the WeeRT server
GET /api/v1/about
Parameters
None
Response code
| Status | Meaning |
|---|---|
| 200 | Success |
If successful, the server will return a JSON structure holding information about the uptime of the operating system, uptime of the WeeRT process, the Node version number, and the WeeRT server version number.
Example
$ curl -i --silent -X GET 'http://localhost:3000/api/v1/about
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 95
ETag: W/"5f-Cn3HkGQZH+3Km80XJvOFk8Ndpqc"
Vary: Accept-Encoding
Date: Sat, 29 Jun 2019 22:06:14 GMT
Connection: keep-alive
{"server_uptime":365124,"weert_uptime":413.837,"node_version":"v10.15.2","weert_version":"0.6.0"}Copyright (c) 2015-2019 Tom Keffer tkeffer@gmail.com
See the file LICENSE for your full rights.