Raritan EMX JSON-RPC API
|
Standard Python 2 or Python 3 installations already contain all necessary packages.
All Raritan 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:
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 file Well-Known-URIs.txt which comes along with the IDL files.
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 occured. 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:
Creates a new agent.
Parameters:
If both, username/password and token are omitted, 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:
This 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:
It is possible to upload and update the device firmware with the Python JSON-RPC. A file can be uploaded as binary through the firmware upload method. The example uses a file within the current working directory.
Example:
It is possible to upload and install own certificates. The Certificate upload needs two files:
Example:
It is possible to download the installed certificates.
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 | |
---|---|
0 | Operation was succesfull. |
1 | An internal error occured. |
2 | A parameter error occured. |
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. It 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 occured. | 2 | A parameter error occured. | 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:
For switching the modes, use the parameters full or backup from the uplaod function.
Example:
It is possible to download the bulk configuration.
Example:
The bulk configuration download support different modes, these modes are:
For switching the modes, use the parameters full or backup from the uplaod function.
Example:
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:
Example:
It is possible to upload the pmc configuration. The pmc configuration upload need one file:
Example:
There is a helper function, that will discover Raritan power products inside of the current subnet and will return a list of ip strings. For this feature there must be the zeroconf python package installed (pip install zeronfonf). This package is only available for python version 3.6 and up.
Example: