This README contains details about the sgminer RPC API
It also includes some detailed information at the end,
about using miner.php
If you start sgminer with the "--api-listen" option, it will listen on a
simple TCP/IP socket for single string API requests from the same machine
running sgminer and reply with a string and then close the socket each time
If you add the "--api-network" option, it will accept API requests from any
network attached computer.
You can only access the comands that reply with data in this mode.
By default, you cannot access any privileged command that affects the miner -
you will receive an access denied status message see --api-allow below.
You can specify IP addresses/prefixes that are only allowed to access the API
with the "--api-allow" option e.g. --api-allow W:192.168.0.1,10.0.0/24
will allow 192.168.0.1 or any address matching 10.0.0.*, but nothing else
IP addresses are automatically padded with extra '.0's as needed
Without a /prefix is the same as specifying /32
0/0 means all IP addresses.
The 'W:' on the front gives that address/subnet privileged access to commands
that modify sgminer (thus all API commands)
Without it those commands return an access denied status.
See --api-groups below to define other groups like W:
Privileged access is checked in the order the IP addresses were supplied to
"--api-allow"
The first match determines the privilege level.
Using the "--api-allow" option overides the "--api-network" option if they
are both specified
With "--api-allow", 127.0.0.1 is not by default given access unless specified
If you start sgminer also with the "--api-mcast" option, it will listen for
a multicast message and reply to it with a message containing it's API port
number, but only if the IP address of the sender is allowed API access
More groups (like the privileged group W:) can be defined using the
--api-groups command
Valid groups are only the letters A-Z (except R & W are predefined) and are
not case sensitive
The R: group is the same as not privileged access
The W: group is (as stated) privileged access (thus all API commands)
To give an IP address/subnet access to a group you use the group letter
in front of the IP address instead of W: e.g. P:192.168.0/32
An IP address/subnet can only be a member of one group
# sgminer RPC API Documentation
*Work in Progress!*
This README contains details about the sgminer RPC API and also includes some detailed information
at the end, about using [miner.php](#miner-php).
---
## API Configuration
If you start sgminer with the `--api-listen` option, it will listen on a simple TCP/IP socket for single string API requests from the same machine running sgminer and reply with a string and then close the socket each time If you add the `--api-network` option, it will accept API requests from any network attached computer.
You can only access the comands that reply with data in this mode. By default, you cannot access any privileged command that affects the miner - you will receive an access denied status message see `--api-allow` below.
You can specify IP addresses/prefixes that are only allowed to access the API with the `--api-allow` option.
```
--api-allow W:192.168.0.1,10.0.0/24
```
The example above will allow 192.168.0.1 or any address matching 10.0.0.*, but nothing else. IP addresses are automatically padded with extra '.0's as needed Without a /prefix is the same as specifying /32 0/0 means all IP addresses. The `W:` on the front gives that address/subnet privileged access to commands that modify sgminer (thus all API commands). Without it those commands return an access denied status. See `--api-groups` below to define other groups like `W:`. Privileged access is checked in the order the IP addresses were supplied to `--api-allow`. The first match determines the privilege level. Using the `--api-allow` option overides the `--api-network` option if they are both specified. With `--api-allow`, 127.0.0.1 is not by default given access unless specified.
If you start sgminer also with the `--api-mcast` option, it will listen for a multicast message and reply to it with a message containing it's API port number, but only if the IP address of the sender is allowed API access.
More groups (like the privileged group `W:`) can be defined using the `--api-groups` command. Valid groups are only the letters A-Z (except R & W are predefined) and are not case sensitive. The `R:` group is the same as not privileged access. The `W:` group is (as stated) privileged access (thus all API commands). To give an IP address/subnet access to a group you use the group letter in front of the IP address instead of `W:` e.g. `P:192.168.0/32`. An IP address/subnet can only be a member of one group
This would create a group `P` that can do all current pool commands and all non-priviliged commands - the asterisk (\*) means all non-priviledged commands. Without the asterisk (\*), the group would only have access to the pool commands.
Defining multiple groups example:
--api-groups Q:quit:restart:*,S:save
This would define 2 groups:
Q: that can 'quit' and 'restart' as well as all non-priviledged commands
S: that can only 'save' and no other commands
```
--api-groups Q:quit:restart:*,S:save
```
This would define 2 groups: `Q:`, that can `quit` and `restart` as well as all non-priviledged commands, and `S:`, that can only `save` and no other commands.
For API configuration options, see `doc/configuration.md`.
---
## API Requests
The RPC API request can be either simple text or JSON.
If the request is JSON (starts with '{'), it will reply with a JSON formatted
If the request is JSON (starts with `{`), it will reply with a JSON formatted
response, otherwise it replies with text formatted as described further below.
The JSON request format required is '{"command":"CMD","parameter":"PARAM"}'
The JSON request format required is `{"command":"CMD","parameter":"PARAM"}`
(though of course parameter is not required for all requests)
where "CMD" is from the "Request" column below and "PARAM" would be e.g.
the ASC/GPU number if required.
An example request in both formats to set GPU 0 fan to 80%:
```
gpufan|0,80
{"command":"gpufan","parameter":"0,80"}
```
The format of each reply (unless stated otherwise) is a STATUS section
followed by an optional detail section
From API version 1.7 onwards, reply strings in JSON and Text have the
necessary escaping as required to avoid ambiguity - they didn't before 1.7
For JSON the 2 characters '"' and '\' are escaped with a '\' before them
For Text the 4 characters '|' ',' '=' and '\' are escaped the same way
For JSON the 2 characters `"` and `\` are escaped with a `\` before them
For Text the 4 characters `|``,``=` and `\` are escaped the same way
Only user entered information will contain characters that require being
escaped, such as Pool URL, User and Password or the Config save filename,
when they are returned in messages or as their values by the API
For API version 1.4 and later:
The STATUS section is:
For API version 1.4 and later the STATUS section is:
The extra formatting of the result is to have a section for each command:
`CMD=summary|STATUS=....|CMD=devs|STATUS=...`
As before, if you supply bad JSON you'll just get a single 'E' STATUS section
With JSON, each result is within a section of the command name
```
{
"summary":{
"STATUS":[
{"STATUS":"S"...}
],
"SUMMARY":[...],
"id":1
},
"devs":{
"STATUS":[
{"STATUS:"S"...}
],
"DEVS":[...],
"id":1
},
"id":1
}
````
As before, if you supply bad JSON you'll just get a single `E` STATUS section
in the old format, since it doesn't switch to using the new format until it
correctly processes the JSON and can match a '+' in the command
correctly processes the JSON and can match a `+` in the command.
If you request a command multiple times, e.g. devs+devs
you'll just get it once
If you request a command multiple times, e.g. `devs+devs`, you'll just get it once.
If this results in only one command, it will still use the new layout
with just the one command
If you request a command that can't be used due to requiring parameters,
a command that isn't a report, or an invalid command, you'll get an 'E' STATUS
a command that isn't a report, or an invalid command, you'll get an `E` STATUS
for that one but it will still attempt to process all other commands supplied
Blank/missing commands are ignore e.g. +devs++
will just show 'devs' using the new layout
Blank/missing commands are ignored. `+devs++` will just show `devs` using the new
layout.
---
## API Commands
### version
Returns the version information of sgminer.
*Syntax:* `version`
For API version 1.10 and later:
*Arguments:* None
The list of requests - a (*) means it requires privileged access - and replies:
*Access*: `Non-priviledged`
Request Reply Section Details
------- ------------- -------
version VERSION Miner="sgminer " sgminer version
CGMiner=sgminer version
API=API version
*Returns:*
```
Miner="sgminer " <sgminerversion>
CGMiner=<sgminerversion>
API=<APIversion>
```
config CONFIG Some miner configuration information:
### config
Returns some miner configuration information
*Syntax:* `config`
*Arguments:* None
*Access*: `Non-priviledged`
*Returns:*
```
GPU Count=N, <-thenumberofGPUs
ASC Count=N, <-thenumberofASCs
PGA Count=N, <-thenumberofPGAs
@ -158,45 +186,114 @@ The list of requests - a (*) means it requires privileged access - and replies:
@@ -158,45 +186,114 @@ The list of requests - a (*) means it requires privileged access - and replies:
Returns each available GPU, PGA and ASC with their details. **Note** that this will not return PGAs or ASCs if PGA or ASC mining is not enabled.
*Syntax:* `devs`
*Arguments:* None
*Access*: `Non-priviledged`
*Returns:*
```
GPU=0,Accepted=NN,MHS av=NNN,...,Intensity=D|
Last Share Time=NNN, <-standandlongtimeinsec(or0ifnone)oflastacceptedshare
Last Share Pool=N, <-poolnumber(or-1ifnone)
Last Valid Work=NNN, <-standandlongtimeinsecoflastworkreturnedthatwasn'tanHW
```
### gpu
Returns the details of a single GPU in the same format and details as [devs](#devs).
*Syntax:* `gpu|<N>`
*Arguments:* `number` GPU Number
*Access*: `Non-priviledged`
*Returns:*
```
GPU=0,Accepted=NN,MHS av=NNN,...,Intensity=D|
Last Share Time=NNN, <-standandlongtimeinsec(or0ifnone)oflastacceptedshare
Last Share Pool=N, <-poolnumber(or-1ifnone)
Last Valid Work=NNN, <-standandlongtimeinsecoflastworkreturnedthatwasn'tanHW
```
### pga
Returns the details of a single PGA in the same format and details as [devs](#devs). **Note** that this is only available if PGA mining is enabled. Use [pgacount](#pgacount) or [config](#config) first to see if there are any PGA devices.
*Syntax:* `pga|<N>`
*Arguments:* `number` PGA Number
*Access*: `Non-priviledged`
*Returns:*
```
PGA=0,Accepted=NN,MHS av=NNN,...,Intensity=D|
Last Share Time=NNN, <-standandlongtimeinsec(or0ifnone)oflastacceptedshare
Last Share Pool=N, <-poolnumber(or-1ifnone)
Last Valid Work=NNN, <-standandlongtimeinsecoflastworkreturnedthatwasn'tanHW
```
### gpucount
Returns the number of GPU devices.
*Syntax:* `gpucount`
*Arguments:* None
*Access*: `Non-priviledged`
*Returns:*
```
Count=N| <-numberofGPUs
```
### pgacount
Returns the number of PGA devices.
*Syntax:* `pgacount`
*Arguments:* None
*Access*: `Non-priviledged`
*Returns:*
```
Count=N| <-numberofPGAs
```
---
```
switchpool|N (*)
none There is no reply section just the STATUS section