Specifications

AVIDdirector-M2M™ Technical Reference Guide

Appendix 5 - M2MXML TM Version 1.0 Specification

See M2MXML Documentation Included.

Appendix 6 – Sample M2MApp.ini Configuration File

The M2MApp’s initial behavior is determined by the configuration loaded via the M2MApp.ini file. This is a Java

properties file that specifies property names and their corresponding values. The Property names have the format

SYSTEM.PROPERTY to gather common properties for a particular item together and also allow similar properties

to be set for multiple devices. Standard SYSTEM names are:

§ AVIDDIRECTOR – Properties relating to the AVIDdirector-M2M device hardware. Currently just the modem

type is specified.

§ SYSTEM – M2MApp properties for the device and framework. This includes control over debug, logging and

system maintenance (Garbage collection).

§ M2MLET – Properties for the M2Mlet application. It is required that the CLASSNAME property is specified

listing the class to load for our M2Mlet. The M2Mlet may define special properties that it wishes to specify

or load. Calling app.getConfigurationItem retrieves these parameters and app.setConfigurationItem

sets the parameters in the M2MApp.ini file.

§ TTLn and HVCn – These parameters refer to the external TTL and HVC ports. The M2MXML address for

the port, its on-device behavior settings and device parameters are specified here. If the M2MXML portal

changes the on-device behavior then these values are updated so that this latest portal configuration is

loaded each time the device is initialized.

§ M2MIODEVICE – Parameters common to the M2M I/O Devices, which include the TTL, HVC, Serial2 and

EXT ports. The only parameter specified is POLLTIME that specifies the time for the polling loop of all the

devices. Each device has a POLL parameter (Y,N) that specifies if it is to be included as a polled device.

§ SL – SensorLogic portal specified properties. The UID must match the UID specified in the portal for this

device.

Radios and user written I/O classes are dynamically loaded by providing a keyword for the device (example,

BOOMER3 or GPS) followed by .CLASSNAME (example GPS.CLASSNAME) and M2MApp will load each Java class file

specified with a property ending in .CLASSNAME. If the class is an instance of

com.avidwireless.AVIDdirector.iodevice.IODevice then it is loaded and treated as a IODevice or if is an

instance of the com.avidwireless.radio.ADRadio class then it will be treated as a Radio. The difference is

IODevice can receive M2MXML messages, send M2MXML messages back to the portal, and can be added to the

main M2M_IODevice polling. A Radio class is associated with a Communicator class to handle M2MXML

messages to and from the portal. Multiple Radio classes may be loaded and M2MApp may dynamically switch

between these radios by calling app.setM2MXMLPortal(Communicator). Each IODevice and Radio may retrieve

their own properties and must handle setting the properties when specified via M2MXML: SetConfiguration

commands.

When M2MApp is initialized, it looks for the file M2MApp.ini and tries to load it. If there is a problem reading the

file, M2MApp then tries to load the file M2MApp.bak, and if that is found, it is copied to M2MApp.ini and an attempt

is made to load that file. If there is an error loading both M2MApp.ini and M2MApp.bak, then the file

M2MApp.default is read and copied to M2MApp.ini. M2MApp.default needs to contain a base set of functionality

for the device to allow it to communicate with the M2MXML portal where it can be setup again. Each time a

configuration property is set in M2MApp, the current M2MApp.ini is first copied to M2MApp.bak and then the

property is set. If there is a loss of power during this operation the device should be able to recover to a known

configuration state.

#M2MApp.ini

# Specify the device type, M2M or XE

AVIDDIRECTOR.MODEL=M2M