Remote Things
This topic explains what Remote Things are, briefly describes some of the templates available in ThingWorx Composer for Remote Things, and provides information about configuring them and their properties and services in the following sections. Click a section title to display the content; click the title again to hide the content:
About Remote Things
A Remote Thing is an edge device or data source whose location is at a distance from the location of the ThingWorx Platform. A Remote Thing accesses the platform, and can itself be accessed, over the network (Intranet/Internet/WAN/LAN). The device is represented on the platform by a Thing that is created using the RemoteThing template, or one of the derivatives of that template (for example, RemoteThingWithFileTransfer).
The default Thing templates that you can use to create things for remote devices follow:
• RemoteThing — A basic Thing that provides the ability to interact with a remote device.
• RemoteThingWithFileTransfer — A remote Thing that can also transfer files.
• RemoteThingWithTunnels — A Remote Thing that supports tunneling.
• RemoteThingWithTunnelsAndFileTransfer — A Remote Thing that supports both file transfers and tunneling.
• RemoteDatabase — A remote OLE-DB data source
• EMSGateway — Addresses the EMS as a standalone Thing. This template may be useful in situations where the EMS is running on a gateway computer and is handling communication for one or more Remote Things, which may reside on different IP addresses within a local area network
• SDKGateway — Similar to the EMSGateway template, but used when you are using an SDK implementation as a gateway.
Use the RemoteThing, RemoteThingWithFileTransfer, RemoteThingWithTunnels, and RemoteThingWithTunnelsAndFileTransfer templates for vendor-specific devices. The recommended approach is to use one of these templates to create a Thing for your vendor-specific device, and when you have added the properties, services, and events for the Thing, save it as your own template. That way, you can add more of the same devices quickly and easily by using your template as the base.
Remote Thing Configuration
The Remote Thing at the device level is implemented using the Lua Script Resource (luaScriptResource.exe). This component shares the configuration file with the WSEMS (config.lua, or per your configuration). Make a copy of the file and place it in the etc directory. The example configuration file is self-documented.
scripts.MyEdgeThing = {
file = "Thing.lua",
template = "example",
This section defines a Thing, and references a Template = example. In this case, that refers to a file named config.lua.example in the microserver\etc\custom\templates directory. This file is installed with the EMS to be used for reference. The template file is for defining properties, services, and tasks at the edge software.
Any of the Remote Thing configuration parameters can be inserted between the brackets { } defined by scripts.MyEdgeThing=.
The template setting is critical. The template file is the definition of the behavior for this edge Thing. Each edge Thing utilizing the Lua script engine requires a template file reference. The template file should be placed in the \microserver\etc\custom\templates directory. An example file is available after install.
Basic Configuration
The config.lua.example file has a section for module configuration.
The require statements pull a specified shape's functionality into the template. A shape can define properties, services, and tasks, just like a template. If the template defines a property, service, or task with the same name as one defined in a shape, then the definition in the shape will be ignored. Therefore, you must take care not to define characteristics with duplicate names. require "thingworx.shapes.myshape”
The following line is required in all user-defined templates: 'template.example' should be replaced with the name of template, for example: 'template.mydevice'. module ("templates.example", thingworx.template.extend)
Shapes
A shape file is the same in structure as a template file. The idea is to create building block files of properties, services, and tasks, and identify them as shapes, which is consistent with the server model terminology. The expected location for these shape files is the \microserver\etc\custom\shapes directory. Using the require statement essentially adds the shape file configuration to the configuration in the template