meta data for this page
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
doc_urecs:software_interface [2023/10/17 15:41] – [Access] vor | doc_urecs:software_interface [2024/01/10 17:18] (current) – [LoRa Message] fun | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Software interface ====== | ====== Software interface ====== | ||
- | There are several software interfaces available to monitor the status of the RECS< | + | There are several software interfaces available to monitor the status of the u.RECS system. These are the Management Web****GUI and a REST API providing XML based monitoring and management functionality. |
===== Management WebGUI ===== | ===== Management WebGUI ===== | ||
Line 12: | Line 12: | ||
|{{ : | |{{ : | ||
|{{ : | |{{ : | ||
- | |||
- | |||
==== Management ==== | ==== Management ==== | ||
Line 29: | Line 27: | ||
==== Access ==== | ==== Access ==== | ||
- | The u.RECS Management API is accessible via the IP-Address or the hostname of the u.RECS. The basic URL of the API has the format '' | + | The u.RECS Management API is accessible via the IP-Address or the hostname of the u.RECS. The basic URL of the API has the format '' |
+ | |||
+ | https://192.168.0.50/ | ||
Accessing the REST API requires HTTP Basic authentication. The password of the admin account can be changed in the Settings page. | Accessing the REST API requires HTTP Basic authentication. The password of the admin account can be changed in the Settings page. | ||
Line 35: | Line 35: | ||
==== Components ==== | ==== Components ==== | ||
- | The RECS< | + | The u.RECS Management API makes all hardware components available as XML trees. The following components are supported by the API: \\ |
^ Attribute ^ Description ^ | ^ Attribute ^ Description ^ | ||
Line 43: | Line 43: | ||
|'' | |'' | ||
- | Many resources also return lists of components. These are named according to the scheme < | + | Many resources also return lists of components. These are named according to the scheme < |
=== Node === | === Node === | ||
Line 54: | Line 54: | ||
actualNodePowerUsage=" | actualNodePowerUsage=" | ||
rcuId=" | rcuId=" | ||
- | <node maxPowerUsage=" | + | <node maxPowerUsage=" |
actualNodePowerUsage=" | actualNodePowerUsage=" | ||
rcuId=" | rcuId=" | ||
Line 64: | Line 64: | ||
^ Attribute ^ Description ^ Unit ^ Data type ^ | ^ Attribute ^ Description ^ Unit ^ Data type ^ | ||
|'' | |'' | ||
+ | |'' | ||
|'' | |'' | ||
|'' | |'' | ||
- | |'' | ||
|'' | |'' | ||
|'' | |'' | ||
|'' | |'' | ||
- | |'' | + | |'' |
+ | |'' | ||
+ | |'' | ||
|'' | |'' | ||
|'' | |'' | ||
- | |'' | ||
- | |'' | ||
- | |'' | ||
|'' | |'' | ||
- | |'' | + | |'' |
- | |'' | + | |'' |
- | |'' | + | |'' |
+ | |'' | ||
In accordance to the component node the API offers nodeList which returns multiple instances of node. | In accordance to the component node the API offers nodeList which returns multiple instances of node. | ||
Line 94: | Line 94: | ||
regulatorsTemperature=" | regulatorsTemperature=" | ||
loraJoinEui=" | loraJoinEui=" | ||
- | loraVendorID=" | + | loraVendorID=" |
firmwareVersion=" | firmwareVersion=" | ||
< | < | ||
Line 104: | Line 104: | ||
^ Attribute ^ Description ^ Unit ^ Data type ^ | ^ Attribute ^ Description ^ Unit ^ Data type ^ | ||
|'' | |'' | ||
- | |'' | + | |'' |
- | |'' | + | |'' |
- | |'' | + | |'' |
- | |'' | + | |'' |
- | |'' | + | |'' |
- | |'' | + | |'' |
- | |'' | + | |'' |
- | + | |'' | |
- | In accordance | + | |'' |
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
+ | |'' | ||
==== System ==== | ==== System ==== | ||
+ | |||
+ | The output of the ''/ | ||
Example XML: | Example XML: | ||
Line 135: | Line 157: | ||
actualNodePowerUsage=" | actualNodePowerUsage=" | ||
health=" | health=" | ||
- | <node maxPowerUsage=" | + | <node maxPowerUsage=" |
actualNodePowerUsage=" | actualNodePowerUsage=" | ||
health=" | health=" | ||
Line 153: | Line 175: | ||
|''/ | |''/ | ||
|''/ | |''/ | ||
- | |''/ | + | |''/ |
=== Management === | === Management === | ||
Line 166: | Line 188: | ||
|''/ | |''/ | ||
- | === LoRaWAN === | + | === LoRaWAN |
The LoRaWAN interface allows up and downlink connections to an application server. | The LoRaWAN interface allows up and downlink connections to an application server. | ||
- | Packets | + | Payload |
^ Attribute ^ Description ^ HTTP method ^ | ^ Attribute ^ Description ^ HTTP method ^ | ||
- | |''/ | + | |''/ |
- | |''/ | + | |''/ |
- | |''/ | + | |
- | Example | + | Example |
- | <code xml>< | + | <code xml>< |
- | <packetbody>lora packet content in base64</packetbody> | + | <payload>{custom lorawan payload}</payload> |
+ | < | ||
</ | </ | ||
- | Example | + | Example |
- | <code xml>< | + | <code xml>< |
- | <band>eu</band> | + | <payload>{custom lorawan payload}</payload> |
- | < | + | |
- | < | + | |
- | < | + | |
</ | </ | ||
- | In order to remotely manage the RECS power status via LoRaWAN, the Application Server must send the downlink command payload in following format: | + | ==== FPort ==== |
- | + | ||
- | <code xml> | + | |
- | <l masterkey=""> | + | |
- | < | + | |
- | <l> | + | |
- | </ | + | |
- | + | ||
- | The master and API keys are managed in the RECS web interface. | + | |
+ | The Frame Port (fport) separates different communication parties on the API, and functions as an identifyer for the message sender / reciever. | ||
+ | When using the REST API, you are free to choose a value between 2 - 223. | ||
+ | FPort 1 is reserved for the management controller. | ||
=== Errors === | === Errors === | ||
Information about the success or failure of management requests are returned via HTTP status codes. Please have a look at [[http:// | Information about the success or failure of management requests are returned via HTTP status codes. Please have a look at [[http:// | ||
+ | |||
+ | ==== LoRa Message ==== | ||
+ | |||
+ | The u.RECS supports upstream and downstream LoRa messages to [[https:// | ||
+ | |||
+ | All system related management communication (excluding the REST API) uses **FPort 1**. | ||
+ | |||
+ | Upstream message payload layout: | ||
+ | |||
+ | ^ Byte(s) ^ Description ^ Unit ^ Data type ^ | ||
+ | |0 | u.RECS Lora Message-Version | - | Byte | | ||
+ | |1 | Node Info Smarc/ | ||
+ | |2 | Regulators temperature: | ||
+ | |3 | Ambient temperature: | ||
+ | |4-5 | System fan 1: | RPM | Unsigned Short (0..65535) | | ||
+ | |6-7 | System fan 2: | RPM | Unsigned Short (0..65535) | | ||
+ | |8-9 | Smarc Power Usage: | ||
+ | |10-11 | Jetson Power Usage: | ||
+ | |12-13 | u.RECS Power Usage: | mW | Unsigned Short (0..65535) | | ||
+ | |14-15 | USB Power Usage: | mW | Unsigned Short (0..65535) | | ||
+ | |16-17 | mPCIe Power Usage: | mW | Unsigned Short (0..65535) | | ||
+ | |18-19 | M.2 Power Usage: | mW | Unsigned Short (0..65535) | | ||
+ | |20-21 | Ethernet Switch Power Usage: | mW | Unsigned Short (0..65535) | | ||
+ | |22-23 | PoE Eth Port 1 Power Usage: | mW | Unsigned Short (0..65535) | | ||
+ | |24-25 | PoE Eth Port 2 Power Usage: | mW | Unsigned Short (0..65535) | | ||
+ | |26 | PoE Status Port 1 | - (see below) | Byte | | ||
+ | |27 | PoE Status Port 2 | - (see below) | Byte | | ||
+ | |||
+ | The u.RECS supports basic control functions over LoRaWAN. | ||
+ | Downstream message payloads: | ||
+ | |||
+ | **Change power state for node:** | ||
+ | ^ Byte(s) ^ Description ^ Unit ^ Data type ^ | ||
+ | |0 | Lora Message-Version | - | Byte | | ||
+ | |1 | Node ID | - | Byte | | ||
+ | |2 | LoRa Command (0x01 = ON, 0x02 = OFF, 0x03 = RESET) | - | Byte | | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== PoE status decoder ==== | ||
+ | |||
+ | Here is some C-Code to decode the PoE Status: | ||
+ | |||
+ | <code c> | ||
+ | PoE Status Bytes: | ||
+ | switch (status & 0xF) { | ||
+ | case 0: ret = " | ||
+ | case 1: ret = "Short circuit"; | ||
+ | case 2: ret = " | ||
+ | case 3: ret = " | ||
+ | case 4: ret = " | ||
+ | case 5: ret = " | ||
+ | case 6: ret = "Open circuit"; | ||
+ | case 7: ret = "PSE to PSE"; break; | ||
+ | case 15: ret = " | ||
+ | } | ||
+ | |||
+ | if ((status & 0xF) == 4) { // RGOOD | ||
+ | switch ((status >> 4) & 0xF) { | ||
+ | case 0: ret += ", class unknown"; | ||
+ | case 1: ret += ", class 1"; break; | ||
+ | case 2: ret += ", class 2"; break; | ||
+ | case 3: ret += ", class 3"; break; | ||
+ | case 4: ret += ", class 4"; break; | ||
+ | case 6: ret += ", class 0"; break; | ||
+ | case 7: ret += ", overcurrent"; | ||
+ | case 8: ret += ", class 5 4P single signature"; | ||
+ | case 12: ret += ", class 4 type 1 limited"; | ||
+ | case 13: ret += ", class 5 legacy"; | ||
+ | case 15: ret += ", class mismatch"; | ||
+ | } | ||
+ | </ | ||