The M2M-SUPERVISOR contains a set of processes that can run on an embedded processing platform (such as the Beaglebone) that can perform the following tasks:
pm2 start processes.jsonfrom the project root to launch the m2m-supervisor
bin/m2m-supervisor -- This process combines all of the following process elements into a single instance...
bin/m2m-bridge -- This process will do the following:
Wait for Redis to be available, then...
Ensure that PPPD is running, then...
Ensure that a dedicated route exists to the gateway server private IP, then...
Discover the device's IMEI, then...
Request RSSI from the modem every minute
Collect FLOW information from the modem
Send a "heartbeat" on startup and again every hour
Listen on ports 4000 and 4001 for locally-routed messages to the gateway sent to its private and public IPs respectively
Listen for incoming "command" and "ack" messages and deposit them in Redis for the m2m-transceiver to process
bin/m2m-transceiver -- This process will do the following:
Wait for Redis to be available and for the gateway configuration (specifically IMEI) to be available, then...
Build "peripheral routers" for each configured peripheral in Redis
Check the "transmit" queue for messages to be sent to the gateway via the m2m-bridge, but only if no outstanding message is waiting for an "ack"
Check the "ack" queue for the arrival matching "ack" messages from the gateway via the m2m-bridge
Check the queue of each "peripheral router" and distribute an inbound "command" message to it for processing
bin/m2m-web-server -- This is an "ExpressJS" and "AngularJS" web application that will do the following:
Monitor the status of the overall M2M-SUPERVISOR
Allow the remote setup of General and Peripheral configuration
Support remote submission of local "shell" commands -- user caution is advised!
Private and Public IP/Port values for accessing the gateway
Private and Public "Relay" Ports for locally-routing messages to the gateway via the m2m-bridge
Primary Route to the gateway -- either "public" or "private" -- the default it "public"
Communication Type -- either "telnet" or "serial"
Telnet Address/Port values for communicating to a "telnet" peripheral
Serial Port/Baud-Rate values for communicating to a "serial" peripheral
This project is committed to maintaining full coverage for test suites of the operational code. In addition, it includes simulation tools to aid development and on-device testing:
bin/command-loader -- This tool will take a TSV file containing peripheral profile settings and a set of command definitions, including schedule periods for "read" commands.
name-- This will be an optional name of the peripheral profile; if not provided, the profile name will be the base file name.
description-- This is an optional description.
command:command-prefix-- This is an optional JSON-encoded string (e.g., "\u0001") that will be added before each command when submitted to the peripheral.
command:command-suffix-- This is an optional JSON-encoded string (e.g., "\u0003") that will be added after each command when submitted to the peripheral.
command:response-prefix-- This is a required JSON-encoded string expected to begin a serial or telnet response from the peripheral.
command:response-suffix-- This is a required JSON-encoded string expected to terminate a serial or telnet response from the peripheral.
key-- This is a required field and values must be unique in the subsequent rows.
label-- This is an optional field and if not provided, or if the values below are blank, the
keywill be used as the
read(:<command-type>)-- This is an expected field whose values are assumed to inquire data from the peripheral; an optional may be appended to distinguish different types of commands (e.g., "display" or "computer").
write(:<command-type)-- This is an optional field whose values are assumed to change data on the peripheral; an optional is also possible.
period(:<command-type)-- This is an optional field whose integer values, if provided, are assumed to indicate that the associated
read(:<command-type>)command should be submitted to the peripheral ever so-many seconds.
attr:<keyword>-- This is an optional field that may repeat with different values for to allow user-defined attributes to be associated with individual commands; the unique list of values will be available for categorizing the commands in the web application.
bin/data-tester -- This tool will take a peripheral key on the command line -- none will assume a single peripheral configured -- and, if it exists in Redis, will allow commands to be entered, displaying the response on the console.
bin/m2m-sys-check -- This tool will check to ensure that key dependencies are installed on the peripheral and will collect key information like modem data/control ports, along with vendor, model, and version.
bin/m2m-sys-config -- Assuming that it can confirm the existence of Redis, an IMEI, and a valid "control" port for the modem, this tool will configure these key Redis configuration attributes.
bin/telnet-finder -- This tool calls
ifconfig -- tested on Mac OSX and Debian -- to find IP interfaces and scans the associated subnets for hosts allowing TCP connections on the Telnet port (default: 10001).
It responds to the
--help option for more details.
bin/telnet-simulator -- This process will listen on port 10001 for command sequences as defined in the
test-server/data/telnet-simulation-data.json file and return the corresponding response.
In order to configure the m2m-transceiver to use the simulator, simply create a test peripheral configuraion using the web-server by providing "localhost" as the Telnet Address --
everything else should be left as a default.