Legrand / Raritan / Server Technology Xerus™ PDU JSON-RPC API
|
Standard Python 2 or Python 3 installations already contain all necessary packages.
All Xerus devices enforce use of HTTPS when accessing the JSON-RPC service. By default, programs written with this client binding try to verify the authenticity of the server when connecting. This requires a valid SSL certificate to be installed on the device. When trying to connect to a device without a valid SSL certificate the client program will terminate with an error message.
It is possible to disable the SSL certificate verification by adding a "disable_certificate_verification" option to the arguments of the rpc.Agent instance:
Code:
Per default, there is no time limit for the IDL method calls configured and so the function calls might not return if the target device is not available.
If necessary, a timeout in seconds can be provided by adding a "timeout" option to the arguments of the rpc.Agent instance.
Code:
Code:
Output produced if there is no error:
Code:
Note that the URIs given to the object proxies (such as "/model/pdu/0"
) are well-known references to static (i.e. they are always there) object instances implemented by the device. All well-known references along with their interface are documented in Well-Known Resource IDs.
Additional Python examples for selected interfaces can be found on the following details pages:
All supporting and generated symbols are placed underneath common package raritan.rpc
. IDL Modules are mapped to corresponding Python package within this common package. Import of all definitions within a module can be done via (for instance):
IDL interfaces are mapped to Python classes which are defined in the __init__.py
file of their according package. The python class implements a proxy that delegates calls to its IDL defined methods to the actual object implementation across the network.
The signature of the methods is slightly altered compared to the IDL signature. All in
arguments are expected as arguments to the Python method in the same order as they appear in IDL. The return argument, if any, and all out
arguments are returned as a Python tuple in the same order they appear in IDL. That means if there is a return argument defined it will appear as first element in the tuple, otherwise the first out
argument is the first element in the tuple. If the IDL method has either only a return value or a single out argument, a single value is returned by the Python method without an embracing tuple.
IDL structures are mapped to Python classes which are, like all other definitions, defined in the __init__.py
file of their according package. The class has all elements as defined in IDL. In addition there is a constructor with a signature that initializes all elements.
The following is an example for enabling a threshold in a sensor:
An IDL enumeration is mapped to a concrete class which has an element for each enumerated value. That means access to a particular enumerated value is accomplished by naming the enumeration type and the enumerated value. Consider the following example for switching an outlet:
PowerState
is an enumerated type defined in the Outlet
interface. PS_OFF
is a specific enumerated value defined in the PowerState
enumeration.
IDL vectors are mapped to Python lists. Consider the following example for looping over the list of all outlets of a Pdu and printing out informative data:
IDL maps are mapped to Python dictionaries. Consider the following example for looping over all observed servers of the servermon.ServerMonitor
and retrieving their entry id mapped to server entry structure which contains information and status:
Execptional errors conditions may occur because of communication problems or encoding/decoding problems, or because of system errors that occur on the server while processing a request. Reporting of such error conditions is not part a regular IDL signature but part of the JSON-RPC protocol.
The Python implementation of the JSON-RPC protocol maps these error condtions to exception:
raritan.rpc.HttpException
This exception is raised in case a communication error occurred. Typical examples include an unreachable server or a failed authentication. The exception contains a descriptive text that gives more details on the error condition.
raritan.rpc.JsonRpcErrorException
This exception is raised in case an error happened on the server side while processing the request. The device might be in an unexpected state. Also there might be a version mismatch between client and server, which means the communication contract between client and server as specified by IDL is broken. The exception contains a descriptive text that gives more details on the error condition.
raritan.rpc.JsonRpcSyntaxException
This exception is raised in case demarshaling of a JSON message went wrong. This may indicate a version mismatch between client and server. The exception contains a descriptive text that gives more details on the error condition.
Consider the following example for catching a communication error:
The Bulk RPC interface allows combining multiple JSON-RPC method calls into a single bulk request that can be sent to the server and processed in a single HTTP request. The raritan.rpc.BulkRequestHelper
class provides a convenient interface to collect and execute method calls:
add_request()
method.perform_bulk()
returns a list containing one entry per queued request. Each entry can be one of the following:
None
if the called method returns void and has no out parameters.Exception
object if the request has failed and the optional raise_subreq_failure
argument is False.Example 1:
Example 2: using perform_bulk()
wrapper for steps 1–3 above
Creates a new agent.
Parameters:
proto
: Used protocol (either "https" or "http")host
: Hostname or IP address of the target PDUuser
: User name (optional)passwd
: Password (optional)token
: Authentication token (optional)debug
: Enables debug output (optional, True
/False
)disable_certificate_verification
: Disables HTTPS certificate verification (optional, True
/False
)timeout
: Request timeout (optional, in seconds)If neither username
/password
nor token
are specified, it is necessary to call either set_auth_basic()
or set_auth_token()
before the first request.
This method enables HTTP basic authentication using username and password.
Parameters:
user
: User namepassword
: passwordThis method enables HTTP authentication using a session token. A session token can be obtained by calling the newSession
method of the session.SessionManager interface.
Parameters:
token
: Session tokenThis method performs a HTTP-GET request on the given target.
Parameters:
target
: target URLThis method HTTP-POST files as multipart form data to the given target. The CGI scripts only accept files with valid formnames
. Valid formnames
are:
"key_file"
and "cert_file"
for key or certificate files (used in raritan.rpc.cert.upload)"bulk_config_file"
for bulk configuration files (used in raritan.rpc.bulkcfg.upload)"upfile"
for firmware update files (used in raritan.rpc.firmware.upload)"config_file"
for upload raw configuration files (used in raritan.rpc.rawcfg.upload)"config_file"
for upload PMC configuration files (used in raritan.rpc.pdumodel.upload_pmc_config)Parameters:
target
: target URLdatas
: list of file data dicts
, which must contain:data
: binary file datafilename
: file nameformname
: formnamemimetype
: mimetype (usually "application/octet-stream"
)Upgrading the device firmware requires uploading the binary firmware image in advance. The Python SDK offers a convenience method firmware.upload()
for this task.
Checking the image status and initiating the actual update process are done using the firmware.Firmware interface.
Example:
Note
If the PDU is configured to force https
and a firmware update file is uploaded with an agent which is configured to use http
, then the upload may fail with a broken pipe exception. This issue can be workarounded by setting the agent protocol to https
.
It is possible to upload and install own certificates. The Certificate upload needs at least one file:
After uploading the function returns a response code. Known response codes are:
Response Code | Description |
---|---|
0 | Operation was successful |
1 | An internal error occurred |
2 | A pending certificate or certificate signing request is already present. |
3 | The key is invalid. |
4 | The certificate is invalid. |
5 | The key and certificate do not match. |
any other | An internal error occurred |
It is recommended that the user verifies the pending certificate before installation.
Function signature
Example:
It is possible to download the installed certificates and keys.
Function signature:
Allowed values for the tag parameter are:
Example:
It is possible to upload a raw configuration. The raw configuration upload need one file:
After uploading a raw configuration a response code is returned. Known response codes are:
Response Code | Description |
---|---|
0 | Operation was successful |
1 | An internal error occurred |
2 | A parameter error occurred |
3 | A raw config update operation is already running |
4 | The file is too large |
5 | Invalid raw config file provided |
6 | Invalid device list file or match provided |
7 | Device list file required but missing (must be the first uploaded file) |
8 | No matching entry in device list found |
9 | Macro subsitution error |
10 | Decrypting value failed |
11 | Unknown magic line |
12 | Processing magic line fail |
Example:
It is possible to download the raw configuration.
Example:
It is possible to upload a bulk configuration. The bulk configuration upload need one file:
After uploading a bulk configuration a response code is returned. Known response codes are:
Response Code | Description | Comment |
---|---|---|
0 | Operation was successful | |
1 | An internal error occurred | |
2 | A parameter error occurred | |
3 | Invalid XML data provided | legacy / unused |
4 | The config data is incompatible (device type mismatch) | |
5 | The config data is incompatible (device model mismatch) | |
6 | The config data is incompatible (firmware version mismatch) | |
7 | The config data is incompatible (unknown data type) | legacy / unused |
8 | The config data is invalid | legacy / unused |
9 | Checksum of config data is wrong | legacy / unused |
10 | Mode mismatch (bulk config vs. full config) | legacy / unused |
11 | Restore operation already running | |
12 | File too large | |
13 | File invalid | |
14 | Checksum missing or invalid | |
15 | Unknown filters |
Example:
The bulk configuration upload support different modes, these modes are:
backup=True
)For switching the modes, use the parameter backup
from the upload function.
Example:
Further optional parameters are:
"model"
, "firmware_version"
or "firmware_version,model"
) for ignoring the model and/or firmware version[]
) for upload the configuration to specific linked devicesFunction signature:
It is possible to download the bulk configuration.
Example:
The bulk configuration download support different modes, these modes are:
backup=True
)For switching the modes, use the parameter backup
from the upload function.
Example:
Further optional parameters are:
True
) for encrypting configuration filesFalse
) download configuration as clear text[]
) for download the configuration from specific linked devicesFunction signature:
It is possible to download the diagnostic data.
Example:
It is possible to download the ETO descriptor.
Example:
It is possible to download the PMC data of either:
Example:
The method pdumodel.upload_pmc_config()
can be used to upload a BCM2 power meter or panel configuration file. The file must be exported in JSON format from one of the Excel templates provided by Raritan.
Example:
By default all power products advertise their services using the MDNS Zeroconf protocol. The helper function zeroconf.discover()
can be used to search for devices in the local subnet. It will return a list of IP addresses as strings.
Using this feature requires the zeroconf
Python library that can be installed with pip install zeroconf
. This package is only available for Python version 3.6 and later.
Example: