EMS Auto-bound Gateways

[#1]

When using the Auto-bind section of an EMS configuration it is very important to note the difference between "gateway":true and "gateway":false. Using either gateway value, when used with a valid "name" field, will result in the EMS attempting to bind the Thing with the ThingWorx platform, and will allow the EMS to respond to file transfer and tunnel services related to the auto-bound things, but this is around where the similarities end.

Non-Gateway:

• This type of auto-bound thing can be thought of as a placeholder because the EMS will still require a LuaScriptResource to be bound in order to respond to property/service/event related messages.
• There must be a corresponding Thing based on the RemoteThing template (or any RemoteThing derived template e.g. RemoteThingWithFileTransfer) on the ThingWorx server in order for the bind to succeed.
• There are many reasons to use this type of auto-bound thing, but the most common is to bind a simple thing that can facilitate file transfer and tunnel services but does not need any custom services, properties, or events that would be provided by custom lua scripts within the LuaScriptResource.

Gateway:

• An auto-bound gateway can be bound to the ThingWorx platform ephemerally if there is no Thing present to bind with on the platform. To clarify, if no Things exist with the matching Thing Name on the platform, and the EMS is attempting to bind a Gateway, a Thing will be automatically created on the platform to bind with the auto-bound gateway. This newly created ephemeral thing will only be accessible through the ThingWorx REST API, and once the EMS unbinds the gateway the ephemeral thing will be deleted
• If there is a pre-existing Thing on the ThingWorx server, then it must be based off of the EMSGateway template in order for the bind to succeed.
• The EMSGateway template, used both normally and ephemerally, will provide some gateway specific services that would otherwise be inaccessible to a normal remote thing. See EMSGateway Class Documentation for more details.

[mikem1]

Clarification on the non-gateway type.  If you have a non-gateway auto_bind entry in the EMS config, a script resource (or other application) isn't ​required.​  Your config could look like this:

"auto_bind" : [

  { "name": "MyThing" }

]

This would allow the EMS to facilitate tunnels and file transfers to MyThing, without a script resource running.

However, if you had your own application with a HTTP interface, and you'd like the platform to be able to send it property/service requests, then you could expand on your config:

"auto_bind" : [

  { "name": "MyThing",

    "host": "10.128.0.2",

    "port": 80,

    "path" : "/MyApp" }

]

If your application was running at http://10.128.0.2:80/MyApp ​then the EMS would direct any non-tunnel and non-file transfer messages to your application.  Note that your application would have to be able to consume ThingWorx formatted messages, and that they would be delivered to a ThingWorx path (e.g., /MyApp/Thingworx/Things/MyThing/Properties/temperature).