1 Reply Latest reply on Jan 15, 2018 3:39 PM by spandey RSS
    spandey Newbie

    deploy EMS (v 5.3) to connect Thinworx Remote things in Windows Environment.

    I was trying to deploy EMS (v 5.3) to connect Thinworx Remote things in Windows Environment.

    Remotething, Mashup and App key have been generated on thingworx environment and

    After configuring all the config files, we tried to run wsems , luaScriptResource. Unfortunately files is not executing.

    I am sharing the configured files kindly let us know why we are not able to execute these files.


    below is the config.lua file--


    -- Logging





    -- Set the log level for the script resource.

    -- Available levels are FORCE, ERROR, WARN, INFO, DEBUG, and TRACE.

    -- Default value is WARN. When running as a service it is important

    -- to set this to ERROR, WARN, or INFO.


    scripts.log_level = "TRACE"

    scripts.script_resource_port = 8006





    -- Edge Thing Configuration





    -- Here we configure an Edge Thing to run in the scripting environment.

    -- The 'file' and 'template' settings are required for all Edge Things.

    -- Other parameters can be specified to change various behaviors:


    --  * scanRate: Controls how frequently, in milliseconds, properties are

    --    evaluated and possibly pushed to the server. Milliseconds. Defaults to

    --    60000 ms.

    --  * taskRate: How frequently the tasks specified in the Thing's template

    --    should be executed. Defaults to 15000 ms.

    --  * scanRateResolution: How long the main thread of execution for this Thing

    --    pauses between iterations. Each iteration checks the scan and task rates

    --    to determine if properties should be evaluated or tasks should be

    --    executed.  Must be less than the scan and task rates. Defaults to 500 ms.

    --  * register: Set to false if you do not want this Edge Thing to register

    --    with the EMS. Defaults to true. In most cases this should be true.

    --  * keepAliveRate: How frequently the Thing should renew its registration

    --    with the MicroServer. If the MicroServer is restarted this value controls

    --    the max amount of time that may pass before the Thing is re-registered.

    --    It also controls how frequently the EMS will perform a keepalive check

    --    on the script resource. If it finds that the script resource is not

    --    available the registered thing will be unbound and appear offline at

    --    the platform. Defaults to 60000 ms.

    --  * requestTimeout: The timeout used for HTTP requests from the EMS to the

    --    script resource.

    --  * maxConcurrentPropertyUpdates: The max number of properties that will be

    --    included in a single property update call to the server. Defaults to 100.

    --    This can be decreased if the overall size of the batch property pushes

    --    is larger than the EMS supports.

    --  * getPropertySubscriptionsOnReconnect: If the Thing is not able to connect

    --    to the MicroServer, on the next successful connection it will re-request

    --    its property subscription information if this setting is set to true.

    --    Useful if the script resource is running on a separate machine than the

    --    MicroServer.

    --  * identifier: Register with the EMS and Platform using this identifier.

    --  * useShapes: Turn on/off the use of DataShapes for property definitions.

    --    Defaults to true.




    scripts.keepAliveRate = 90000

    scripts.SampleRemoteThingTemplate = {

        file = "thing.lua",

        template = "SampleThingTemplate",

        updateRate = 50000





    -- Example integration script





    -- See etc/custom/scripts/sample.lua for implementation details.




    below is a thing which i create-




    -- An example template, showing how to define properties, services,

    -- and tasks.




    -- ------------------------------------------------------------------------------------------------

    -- 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 "yourshape"



    -- ------------------------------------------------------------------------------------------------

    -- This line is required in all user defined templates. 'template.example'

    -- should be replaced with the name of template, for example: 'template.mydevice'.


    require "thingworx.shapes.propsubscribe"

    module ("templates.SampleThingTemplate", thingworx.template.extend)



    -- ------------------------------------------------------------------------------------------------

    -- DataShapes describe the structure of an InfoTable. DataShapes that are declared can be used

    -- as the input or out for services, or for generating strongly typed data structures. Each

    -- DataShape is defined using a series or tables, each table representing the definition of

    -- a field within the DataShape. These fields must have a 'name' and a 'baseType'. They may

    -- also include a 'description' and an 'ordinal', as well as an 'aspects' table that can provide

    -- additional information, such as a defaultValue or a dataShape, if the field's baseType is an

    -- InfoTable.







    -- ------------------------------------------------------------------------------------------------

    -- Properties are defined using Lua tables. The table format is as follows:

    --     baseType: The ThingWorx base type for the property. Required.

    --     dataChangeType: ALWAYS, VALUE, ON, OFF or NEVER. Provides a default value for the

    --                     Data Change Type field of the property definition on the server, if the

    --                     property is initially created using ThingWorx's Manage Bindings function.

    --     dataChangeThreshold: Provides a default value for the Data Change Threshold field of the

    --                          property definition on the server, if the property is initially

    --                          created using ThingWorx's Manage Bindings function.

    --     pushType: ALWYAS, VALUE, or NEVER. Each property in the properties table can be

    --                     monitored, and on change its value can be pushed to the server. A

    --                     pushType of ALWAYS or VALUE should be used if the property is to

    --                     be pushed. Defaults to NEVER.

    --     pushThreshold: For properties with a baseType of NUMBER and a pushType of VALUE, this

    --                    attribute indicated how much a property must change by in order for it

    --                    to be pushed to the server.

    --     handler: The name of the handler to use for property reads/writes. The current set of

    --              handler options are 'script', 'inmemory', 'http', 'https', or 'generator. The

    --              default handler is 'inmemory'. The 'script', 'http', and 'https' handlers will

    --              use the key field to determine the endpoint to execute their reads/writes on.

    --     key: A key that the handler can use to look up or set the property's value. In the case

    --          of a script, this is a URL path. For http or https handlers, this field should contain

    --          a URL, not including the protocol. Not required for handers that are inmemory or nil.

    --     value: The default value for the property. This will be updated as the property's value

    --            changes during execution. Defaults to 0.

    --     time: The last time, in milliseconds since the epoch, that the property was updated.

    --           When Things are created from this template, this value will be automatically set to

    --           the current time, unless a default is provided in the property definition.

    --     quality: The quality of the property's value. A default should be provided if a default

    --              value is defined. Otherwise it will default to GOOD for properties with no

    --              handler, and UNKNOWN for properties with a handler.

    --     scanRate: How frequently this property should be inspected for a change event.

    --               Specified in milliseconds. The global default is 5000.

    --     cacheTime: Used to initialize a property's cache time value at the server. This value

    --                defaults to -1 for property's with a dataChangeType of NEVER, and 0 for

    --                property's with a dataChangeType of ALWAYS or VALUE. If a different value

    --                is specified it will be used by the server as the initial value and is only

    --                applied when using the server's browse functionality to bind the property.


    -- Note: Custom handlers can specify other property attributes. When a handler is utilized to

    --       read or write a property, the entire property table is passed to the handler.


    properties.SampleStr  =  { baseType="STRING",   pushType="VALUE",  value="Sample" }

    properties.SampleInt1  =  { baseType="INTEGER",   pushType="VALUE",   value=1 }

    properties.SampleInt2  =  { baseType="INTEGER",   pushType="VALUE",   value=1 }

    properties.SampleBln  =  { baseType="BOOLEAN",   pushType="VALUE",  value=true }

    properties.isConnected  =  { baseType="BOOLEAN", pushType="ALWAYS", value=true}





    -- ------------------------------------------------------------------------------------------------

    -- Service definitions provide metadata about the defined services. This metadata is used when

    -- browsing services from the ThingWorx server. The name of the service definition must match

    -- the name of the service it is defining. Each service definition can contain the following

    -- fields, each with their own set of definition parameters:


    --    input: Describes an input parameter to the service. At runtime, each input parameter can

    --           be looked up inside of the 'data' table passed into the service. The valid input

    --           fields are: name, baseType, description

    --    output: A description of the output produced by the service. Valid fields are: baseType

    --            and description.

    --    description: A description of the service




    -- ------------------------------------------------------------------------------------------------

    -- Services are defined as Lua functions. These can be executed remotely from the server and must

    -- provide a valid response, via their return statement. The signature for the functions must be:

    --   me: A table that refers to the Thing.

    --   headers: A table of HTTP headers.

    --   query: The query paramters from the HTTP request.

    --   data: A Lua table containing the parameters to the service call.


    -- A service must return the following values (in this order):

    --   * A HTTP return code (200 for success)

    --   * The response date, in the form of a JSON string. This can be created from a Lua table using

    --     json.encode, or tw_utils.encodeData().






    services.ServiceCallFromServer = function(me, headers, query, data)

      if not data.stringData then

        return 400, "You must provide the 'stringData' parameter"


      if not data.integerData then

        return 400, "You must provide the 'integerData' parameter"


        if not data.booleanData then

        return 400, "You must provide the 'integerData' parameter"


      return 200


    -- ------------------------------------------------------------------------------------------------

    -- Tasks are Lua functions that are executed periodically by the ThingWorx Lua framework. They

    -- can be used to execute background tasks, monitor resources, and fire events.