Device Manager Agent local APIs

Overview
Software running locally on a gateway can communicate with the EDGEHOG Device Manager Agent via internal local APIs. 
The Device Manager Agent exposes a Socket Server on port 5288 that supports the TR-50 M2M standard, in order to communicate and let use a subset of its services. 
The client-server communication is JSON based with two main sections: 
Authentication: specifies any authentication for the request 
Command(s): specifies any commands to be sent
Here you can find the specification of the TR-50 messages that can be used to communicate with the Device Manager Agent.
TR-50 typical Request
To use the command interface on the API, you must format the messages you send according to the TR50 protocol specification which defines a JSON object format.
Multiple commands can be sent in a single packet. Each command must have a unique command ID (the "1" and "2" below) so that the replies can be properly correlated. The "params" field is optional, and the contents depend on the particular command. If a command has no parameters, it is best to not send the parameter field at all.
1
{  
2
   "auth":{  
3
     "applicationToken":"<applicationToken>",
4
     "sessionId":”<sessionId>”
5
   },
6
    
7
   "1":{  
8
      "command":"<insert_command_here>",
9
      "params": {<command_specific_parameters_here>}
10
      }
11
   },
12
   "2":{  
13
      "command":"<insert_command_here>",
14
      "params": {<command_specific_parameters_here>}
15
      }
16
   }
17
}
Copied!
TR-50 typical Response
Each command will respond with a "success" boolean that is either true or false. If the success field is false, then the errorCodes and errorMessages fields will be available, each field is an array allowing for multiple error codes to be referenced.
1
{  
2
   "1":{  
3
      "success":true,
4
      "params": []
5
      }
6
   },
7
   "2":{  
8
      "success":false,
9
      "errorCodes": 
10
       [
11
        <errorCode1>,
12
        <errorCode2>
13
       ]
14
       "errorMessages":
15
       [
16
        "errorMessage”,
17
        "errorMessage”
18
       ]
19
      }
20
   }
21
}
Copied!
Here some bash examples of requests that can be done through the terminal.
The Authentication part of the TR-50 request is not currently handled for requests arriving from within the same gateway (software or application running on the same OS), so the request message may be sent without considering that part as in the examples below.
1
$ nc localhost 5288 
2
{ "1": { "command": "cmd.test"}}
3
​
4
$ cat > /dev/tcp/localhost/5288
5
{ "1": { "command": "cmd.test"}}
6
​
7
$ exec 3<>/dev/tcp/localhost/5288
8
$ echo "{ "1": { "command": "cmd.test"}}" >&3
9
$ cat <&3
10
​
11
$ exec 3<>/dev/tcp/localhost/5288 && echo "{ "1": { "command": "devman.info"}}" >&3 && cat <&3
Copied!
File Uploader External ACK
In a File upload request, more control over the validation of the file can be added by enabling the receipt of an ACK from external software. When the external ack is enabled in the File Model, EDGEHOG Device Manager Agent waits for an ACK message from a third-party application to confirm the successful download campaign to the Cloud.
The ACK need to be sent through TR-50, specifying in the request the absolute path of the downloaded file.
1
{  
2
   "1":{  
3
      "command":"file.ack",
4
      "params":{
5
        "success": boolean,
6
        "path": "string",
7
        "[message]": "string"
8
      }
9
   }
10
}
Copied!
Here an inline bash example:
1
$ nc localhost 5288
2
{ "1": { "command": "file.ack", "params": { "success": true, "path": "/var/lib/seco-iot/downloads/test_dir/test.bin"  }}}
Copied!

Using the Device Manager - Previous

File Uploader

Next - Cloud API

REST APIs

Last modified 1yr ago

Copy link

Contents

Overview

File Uploader External ACK