IoT & Connectivity Tips

This video concludes Module 3: Data Profiling of the ThingWorx Analytics Training videos. It shows you a few examples of questions that should be asked of a subject-matter expert (SME) to better understand the information contained in a dataset. Using answers to these questions, you will  use a tool such as Microsoft Excel to modify a given dataset, and prepare it for future exercises in this course.

Here's a short list of vocabulary terms used throughout the ThingWorx documentation.   A Term Definition alert A declarative way to create an event in ThingWorx that is triggered when a defined value or limit is reached or exceeded. All properties in a Thing shape, Thing template, or Thing can have one or more alert conditions defined. Alert types are specific to the data type of the property; the following base types can be used for alerts: Boolean, Datetime, Infotable, Integer, Location, Number, and String. alert history A comprehensive table that records all information when an alert is triggered. The data is stored until it is removed manually. alert processing subsystem Subsystem that manages the alert history stream. See Subsystem. alert summary Compiles data from the last reset of the server to the current state. You can view, acknowledge, and sort (by acknowledged or unacknowledged) alerts on the Alert Summary page. AlwaysOn Proprietary binary protocol for communication between edge devices and the ThingWorx Platform. application key Security tokens used for authentication in ThingWorx when not using a standard credentials method of authentication. They are associated with a given user and have all of the permissions granted to the user with which they are associated. Application Keys are typically used to assign permission control to remotely-connected edge-devices. Application keys are also known as: appKeys. application log A collection of all of the messages that the ThingWorx application generates while operating. Based on your settings (such as WARN and DEBUG), this log can display system messages. authenticator An entity that allows you to implement user authentication, such as single sign-on or certificates, outside of ThingWorx.   B Term Definition base type Type of data such as DATETIME, HYPERLINK, INFOTABLE, and NUMBER. binding In order for your application to display data collected from your devices, you need to bind a Widget to a Data Source. See mashup binding. blog A type of Widget that mimics the functionality of a 'web log' to provide online journal functionality. Posts may be made both by users and the ThingWorx Platform.   C Term Definition ClientConfigurator A class common to all of the object-oriented Edge SDKs that handles configuration (URI, port, support for proxying, tunneling, file transfer, etc.) of the ConnectedThingClient. It is used by the edge device to control its behavior and connect to the ThingWorx Platform. communication log A record of all communication activity with the ThingWorx platform. These communications can be between the following:a connection server and the platform, WebSocket devices and a Connection Server, WebSocket devices and the platform. Composer Modeling and design environment in ThingWorx where you create the back-end of your IoT application. ThingWorx Composer runs as an HTML5 web application. Composer log Records all activity performed in the Composer and its interaction with the platform layer. configuration log Contains all of the messages that the ThingWorx application generates for create, modify, and delete functions in the ThingWorx Platform. For example, if a Thing or Mashup is created, modified, or deleted, that information is recorded. ConnectedThingClient A class common to all of the object-oriented Edge SDKs that handles communication between Edge and the ThingWorx Platform. connection server A server application that allows the connection of remote devices and handles all message routing to and from the devices.   D Term Definition dashboard A dynamic Mashup constructed from a grouping of Gadgets. A Dashboard may be modified during runtime so that certain Gadgets are displayed, while others are hidden. data Row entries in data tables, streams, value streams, blogs, wikis, and properties. data shape A type of ThingWorx entity made up of field definitions and related metadata that represents the data in your model. Each field in a data shape has a data type. ThingWorx has a defined set of base types, including: Boolean, Datetime, Hyperlink, Image, Infotable, Integer, Number, and String. data table A storage table that has a primary key and optional indexed fields; similar to a standard relational database table. A data table has the following predefined fields: Timestamp, Tag, Source, SourceType, and Location. A Data Table can be connected to external databases in order to import/export records. data tag Mechanism to label data to assist in grouping, filtering, and finding it. A ThingWorx tag is defined by the combination of a ThingWorx vocabulary and a specific vocabulary term; shown as Vocabulary:VocabularyTerm. Tags can be used to create a relationship between many different ThingWorx entities. directory services authentication A system, such as an LDAP service, that provides the ability to securely login through other applications outside of the ThingWorx Platform.   E Term Definition Edge MicroServer (EMS) Allows edge devices or data stores to connect to the ThingWorx Core through either the Internet or a firewall using the AlwaysOn™ binary protocol. See WebSocket-based Edge MicroServer (WS EMS). entity Highest-level objects created and maintained in ThingWorx. For example, Things, Thing Shapes, and Thing Templates. event Represents a change in state or value of a property. Interrupts the ThingWorx Core can subscribe to for purposes of receiving notifications when something happens. event processing subsystem Subsystem that manages event processing for external subscriptions (Things subscribing to other Things) throughout ThingWorx. See Subsystem. export import subsystem Subsystem that manages data export and import file sizes. In a system where many users have import/export permissions, these settings can help to alleviate importing/exporting large amounts of data at the same time. See Subsystem. extension A collection of entities, resources, and widgets used to extend the functionality of the ThingWorx Platform. This collection is packaged into a zip file, which can be uploaded to any ThingWorx Platform and used to serve a specific function.   F Term Definition federation A concept to enable sharing a large solution workload among ThingWorx servers by using local data Things (streams, value streams, data tables, wikis, or blogs) that publish to remote data Things (remote streams, remote value streams, remote data tables, remote wikis, or remote blogs). federation subsystem Subsystem that manages the federation of Things among ThingWorx servers. See Subsystem. field definition Defines a field of a data shape. A field definition defines the base type, name of the field, and whether the field is a primary key. file transfer subsystem Subsystem that maintains file transfer settings between remote Things, file repositories, and federated servers. See Subsystem.   G Term Definition gadget Reusable self-contained mashups that make up dashboards; can display historical or current data. Gadgets contain predefined parameters and additional metadata, which handles the sizing requirements of a dashboard.   I Term Definition infotable The aggregate base type within ThingWorx. InfoTables have a DataShapeDefinition that describes the names, base types, and additional information about each field within the table.   L Term Definition localization table Provides the ability to display run time labels in different languages or in userdefined terminology. You can configure localization tables with tokens, which can be assigned to the labels in the Mashup Builder. Each localization table in ThingWorx represents a different language. logging subsystem Subsystem that manages various logs, such as Application, Script, and Communications. See Subsystem. logs The various monitoring tools that record the activity in your ThingWorx model. The available logs are the application log, communication log, Composer log, configuration log, security log, and script log. Lua Script Resource A utility that is used to run Lua scripts and implement remote Things at the edge device level.   M Term Definition mashup A graphical visualization of the model and data. Mashups have the ability to produce enriched results from the combination of presentation and data aggregation, making the application more useful and effective. mashup binding The process of identifying the data source for widgets to display in the Mashup Builder. mashup builder The tool used to create and configure Mashups. master Visualization entity that provides consistent framing of a mashup's contents. A master is commonly used for items that display throughout the mashup, such as logos, menus, and titles. media Locally-stored media artifacts necessary for your ThingWorx application implementation. In most cases, these include images and icons used for entities such as menus, style definitions, and mashups. menu A hierarchical navigation structure consisting of links to mashups or URLs that is represented by a widget in a mashup. message store subsystem Subsystem that processes outbound queued messages for various remote Things, including federated servers. See Subsystem. model binding The process of attaching properties to entities in a model. There are two types of property bindings: local and remote. Services and events are remote only. model tag Mechanism to label ThingWorx entities to assist in grouping, filtering, and finding ThingWorx data and searching and discovering entities efficiently. A ThingWorx tag is defined by the combination of a ThingWorx vocabulary and a ThingWorx vocabulary term. model The collection of ThingWorx entities created to represent your process, solution, and/or application.   N Term Definition network Defines the relationships between Things and allows you to define a "Thing hierarchy" (parent, child).   O Term Definition organization A hierarchical structure used to allow/deny visibility, access, and functionality to resources within ThingWorx. Users and User Groups are used to populate Organizations.   P Term Definition persistence provider A type of database which stores all collected ThingWorx information. The default database for ThingWorx is Neo4j. Other persistence providers can be created or configured within the platform. A configured instance of a persistence provider package can be utilized in run time data entities (streams, value streams, data tables, blogs, and wikis) to tailor the specifics of their persistence (such as location, run time characteristics, and tuning). platform subsystem Subsystem that provides overall Platform monitoring and configuration. See Subsystem. Project Used to logically group a collection of entities. property Represents a behavior of the actual Thing or process that you are modeling. Can also be thought of as a parameter or variable.   R Term Definition remote Thing A device or data source that is geographically separated from the ThingWorx Platform and is accessed over the network (Intranet/Internet/WAN/LAN). That device is represented as a remote Thing on the Platform. resource Platform-provided services to aid in implementing your applications. RESTAPI Representational state transfer (REST) application program interface (API). The ThingWorx API can be accessed at: host:port>/ Thingworx////characteristic>?. run time data Data represented by streams, value streams, data tables, blogs, wikis, and properties.   S Term Definition script log Contains all of the messages that the ThingWorx application generates while executing JavaScript services. You can use the logger.warn function to write information to the script log from the services you are running. Generally, ThingWorx will only publish errors to this log that are incurred while running a service. security Granular security model available within the ThingWorx Platform. There are two sets of permissions, one for design time and one for run time. The design time permissions are for managing who is allowed to modify the model (create, read, update, and delete entities), while the run time permissions determine who can access data, execute services, and trigger events on a Thing (which includes Data Tables, Streams, and Users). For each permission, you can explicitly permit a User or Group to be able to do something (like edit a Thing) or explicitly deny a Group the ability to do something (e.g. the Users Group is not allowed to edit a Thing). You can apply permissions at the Group level and at the User level. An explicit denial of a privilege always overrides a privilege grant. SecurityClaim A class common to all of the object-oriented Edge SDKs used by a ClientConfigurator to store authentication information for a ConnectedThingClient. security log Contains all of the messages that the ThingWorx application generates regarding users. Depending on the log level, it can include login and page requests information. service A function which a Thing can perform. A service can be defined at the Thing Shape, Thing Template, or Thing level. state definition A collection of style definitions that are applied using data-based rules in a mashup. Evaluating the data to specific ranges or values allows you to perform data-based formatting, such as changing the background color of cells in a grid widget. stream A storage table that is optimized for time-series data. Writes to a stream are done asynchronously. Querying a Stream returns the entire record. style definition A collection of HTML styling elements that can be applied to a widget. All colors, text, and line formats are managed and rendered in the mashup environment using style definition entities. subscription An action that executes when an event occurs. subsystem Configurable ThingWorx Platform functionality that can be adjusted for specific Platform performance requirements. See Subsystem. system user A default user in ThingWorx that manages internal service permissions but allows external API layer permissions to be set for each user.   T Term Definition tag Used to label ThingWorx entities and data to assist with grouping, filtering, and locating ThingWorx entities and data. A ThingWorx tag is defined by the combination of a ThingWorx vocabulary and a ThingWorx vocabulary term. Vocabularies and vocabulary terms are customizable. Thing The digital representation of physical assets and/or processes that have properties and business logic. All ThingWorx Things are based on Thing Templates. Thing Shape An abstract definition that represents the behavior of a concrete Thing or Things. Defines properties, services, events, and subscriptions for Things that implement the Thing shape. Typically, the Thing Shape is implemented by a Thing Template, which is then the basis of actual Things. Thing Template Provides base functionality with properties, services, events, and subscriptions that Thing instances use in their execution. ThingWorx Things are derived from Thing Templates. ThingWorx SDK Software development kit available in several languages, including C, Java, .NET, and iOS. The terms edge application or client application may be used when referring to a custom application built on an SDK. The term edge component may be used to describe a solution that includes multiple edge components (EMS, SDKs, ADO service, OPC service, etc.) tunnel subsystem Subsystem that handles tunneling between remote Things. See Subsystem.     Click here for ThingWorx Glossary U - W

Introduction ThingWorx 10.1 takes a major step toward intelligent interoperability by introducing the Model Context Protocol (MCP) in Public Preview. As industries accelerate their use of AI-assisted operations, MCP provides a standardized way for AI agents to securely connect with real-world industrial data and perform actions across systems.   Our key goal is enabling agent-driven automation along with intelligent interoperability. MCP allows AI models and agents to interact with external systems such as ERP, MES, CRM, and analytics platforms in a structured and secure way. It removes the need for custom connectors and integrations, enabling developers to use a single, open standard to bridge AI and operational data. In essence, MCP allows AI to work natively with ThingWorx services and data models.   ThingWorx and MCP   Low-Code Enablement for Agentic Automation ThingWorx now embeds an MCP Server directly into the platform. This means that your existing ThingWorx services can be instantly made “AI-ready” without the need for external deployments. Through a simple low-code interface called MCPServices, users can define, manage, and expose three core MCP entities — Tools, Resources, and Prompts — that form the building blocks of contextual AI workflows.   MCP Services   Tools represent actions or functions AI can call (such as retrieving machine KPIs), Resources represent contextual data the AI can reference, and Prompts are reusable templates that guide AI on how to interact with them. This model creates a foundation for secure, context-aware automation that can be reused across multiple agents and applications. Secure by Design, Open by Standard MCP in ThingWorx follows industry-standard security protocols by introducing OAuth-protected metadata endpoints, compliant with RFC 9728. These endpoints let clients authenticate and discover the resources they’re authorized to use — ensuring data access remains secure while supporting open interoperability.   This aligns with ThingWorx’s broader goal: creating an ecosystem where AI agents can safely access contextualized industrial data across systems. Whether connecting to SAP, Salesforce, or another MCP-compatible server, your ThingWorx instance can now participate in a larger agentic ecosystem. Seamless Interoperability and Scalability All MCP configurations — tools, resources, and prompts — are stored within ThingWorx’s persistence layer, ensuring that your MCP setup scales with your enterprise environment. Agents can connect to multiple ThingWorx servers deployed globally, retrieve contextual data from each, and feed it into AI-driven workflows that span factories, regions, or entire business units.   This design lays the groundwork for domain-specific large language models (DSLMS) and enterprise AI assistants that understand and act on operational data directly from ThingWorx. Feature Summary For instance, you may have ThingWorx Server 1 supporting factory sites in the USA, another in Germany, and a third in Mexico. These local ThingWorx deployments, powered by MCP capabilities, can expose rich contextualized data for agentic automation.   MCP clients could then be used to perform enterprise-wide KPI calculations to benchmark performance across factory sites over standard metrics such as OEE.   As local systems (ERP, MES, or factory systems) adopt MCP, ThingWorx MCP clients can directly access their data, enabling seamless integration without building custom REST connectors — saving significant development effort in API integration and data mapping.     MCP Usage with TWX - Concept     Capability Description Embedded MCP Server Native support inside ThingWorx – no extra setup required. MCPServices Resource Low-code interface to manage Tools, Resources, and Prompts. OAuth Security RFC 9728-compliant protected metadata for secure AI access. Persistence Layer Stores MCP configurations across databases for scalability. AI Integration Enables context-aware, agentic automation via MCP Tools.   Feature Benefits Overall, MCP support with ThingWorx delivers several key benefits: Standardized, secure, and discoverable data access via the ThingWorx MCP Server, making operations AI-ready. Dynamic population of MCP tools without the need for custom code. Ability for AI agent developers to create tailored agents that use selective ThingWorx services enriched with context for higher accuracy. Seamless alignment with agentic AI architectures for automated workflows. Direct interoperability with enterprise systems already supporting MCP servers, allowing AI agents to connect and retrieve data easily. Upgrade to ThingWorx 10.1 to try MCP The introduction of MCP marks the start of AI-native industrial automation in ThingWorx. By adopting 10.1, you gain early access to a framework that will power the next generation of connected, intelligent systems — helping your business stay ahead as AI integration accelerates across industries.   We encourage feedback from users who have tried the MCP preview — what capabilities would you like to see next, and how can we improve interoperability and automation through ThingWorx   If you’re new to ThingWorx release phases, read about Public Preview and other stages here Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx 10.1, and as always, in case of issues, feel free to reach out to <support.ptc.com>  

    Select the right database to use with your ThingWorx installation.   Guide Concept   When you develop an application with ThingWorx, you must save the configuration data that defines the data model and the user interface. You also need to store the dynamic data that is generated by devices at runtime (such as temperature or location).   ThingWorx uses the term Persistence Provider to refer to any type of service that saves application data, usually it is a database.   When your application moves into production you must choose and configure a Persistence Provider that meets your requirements.     You'll learn how to   Pros and cons of different databases that can be used as persistence providers for ThingWorx The database best suited to certain applications Where to find detailed information about the Persistence Providers   NOTE: The estimated time to complete this guide is 30 minutes       Step 1: Persistence Provider Options   There are many factors that will influence your decision for which Persistence Provider to use with your ThingWorx instance. On this page we compare and contrast different methods and provide examples for where each one is a natural fit.    Persistence Provider             Typical Use H2 Bundled with ThingWorx server for proof-of-concept trials PostgreSQL Standard production database for use up to 15,000 Property writes per second InfluxDB High volume data ingestion (>25,000 property writes per second) into one database Microsoft SQL Server SQL database available from Microsoft in a dozen different editions Azure SQL Server SQL database managed by Microsoft in Azure   When ThingWorx is installed with default configurations, it uses the embedded H2 database as its Persistence Provider. This configuration is suitable for evaluations and proof-of-concept applications with a limited number of Things. Before an application is used in production, you must provision a more capable persistence provider. The available options for Persistence Provider are summarized below.   H2   Pros                            Cons                     Typical Use Case                                DBA Skills       Required Cost No Database set-up required Not for use in production Start testing ThingWorx with no additional configuration None No additional cost   H2 is an open source, full-featured relational database that is embedded in the ThingWorx Foundation server. No additional database set-up is required before developing a proof-of-concept application with ThingWorx. Using H2 should provide satisfactory performance for applications with less than 1000 Things.   WARNING: Due to the inability to back-up and recover the database, H2 should never be used in production.   PostgreSQL    Pros                    Cons                        Typical Use Case                     DBA Skills               Required Cost Widely used database Requires some configuration Workhorse database appropriate for many applications Basic SQL skills No additional cost   PostgreSQL is the default choice for ThingWorx cloud hosting servers. It complies with many database standards and is open source with no extra license fee required. It can be configured for high availability to minimize the chance of down-time or data loss. It has been tested up to 15,000 property writes per second and depending on other factors may give satisfactory performance up to 25,000 writes per second.   Learn more about using PostgreSQL:   Using PostgreSQL as the Persistence Provider ThingWorx PostgreSQL Administrator's Guide   InfluxDB   Pros                      Cons                            Typical Use Case            DBA Skills Required           License Cost Handle high volume data ingestion InfluxDB is not supported as a Property provider Application requiring >25,000 Property writes/second Professional services likely required Multi-node requires license fee   If your system intensively deals with time series data and your implementation heavily depends on Value Streams or Streams for persistence/retrieval of data, we recommend using InfluxDB as the Persistence Provider in ThingWorx. InfluxDB is a high-performance data store written specifically for time series data and is a good choice when high volume data ingestion of more than 25,000 property writes per second must be saved into one database.   Learn more about InfluxDB:   Using InfluxDB as the Persistence Provider   Microsoft SQL Server   Pros                     Cons                       Typical Use Case                    DBA Skills                      Required Cost Available in multiple editions Only runs on Windows Data stored in Microsoft SQL Server Configure settings License fee required   More than a dozen different versions of Microsoft SQL Server are used by customers for workloads ranging from small single-machine applications to large enterprise applications. Connecting ThingWorx to an existing Microsoft SQL Server can make that data readily available to use in ThingWorx Mashups.   Learn more about using Microsoft SQL Server:   Using Microsoft SQL Server as the Persistence Provider Getting Started with MS SQL and ThingWorx   Azure SQL Server   Pros                                    Cons                        Typical Use Case              DBA Skills         Required Cost Cloud deployment and scaling No on-premise option Data stored in Microsoft SQL Server Configure settings Subscription required   Fully managed database service operated and updated by Microsoft Learn more about using Microsoft SQL Server:   Using Azure SQL Database as the Persistence Provider   Step 2: Next Steps   Congratulations! You've successfully completed the Compare Persistence Providers guide. At this point, you can make an educated decision regarding which Persistence Provider is best suited for your ThingWorx application development environment.   Learn More   We recommend the following resources to continue your learning experience:    Capability    Guide Connect ThingWorx Application Development Reference Build Get Started with ThingWorx for IoT Experience Create Your Application UI   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource        Link Community Developer Community Forum Support Microsoft SQL Technical Support Support Persistence Provider Help Center

    Step 5: Verify Connectivity    The EMS is now attempting to talk to the ThingWorx platform.   However, ThingWorx does not have detailed information about the Edge device that is attempting to connect to it, so it will show up in the Unbound category.   Open ThingWorx Composer.     On the left, click Monitoring.     Click STATUS > Remote Things.     Click Unbound.     Confirm that you see the EdgeThing listed in the Unbound section. NOTE: The name EdgeThing comes from the config.lua script. EdgeThing is simply the name that is in that script, hence the name that you see in ThingWorx. To change the name of the device, you could stop both wsems.exe and luaScriptResource.exe, edit config.lua to use a different Thing name other than EdgeThing, and then restart both of the WSEMS programs. At that point, the Thing showing up in Remote Things -> Unbound would be whatever name you changed to in config.lua.   Create a Remote Thing   Now that the EMS is communicating with Foundation, let's create a Remote Thing to which Foundation can tie said connection.   In ThingWorx Composer, click Browse > MODELING > Things, + New.     In the Name field, enter EdgeThing. Note that the name must match the spelling and capitalization of the Thing's name that you entered in the EMS's config.lua for it to auto-connect.  If Project is not already set, search for and select PTCDefaultProject. In the Base Thing Template field, search for and select RemoteThingWithTunnelsAndFileTransfer.   At the top, Click Save. Note the status-indication pop-up indicating that EdgeThing is now connected.   Use Services to Explore EMS Files   Now that your Remote Thing is Saved and Connected, we can use some of the built-in Services to explore the EMS folders and files which we previously created for testing purposes.   At the top of EdgeThing, click Services.   Under the Execute column, click the Play Symbol for BrowseDirectory.   In the top-left path field, type / and click the bottom-right Execute button. Note the other and tw folders which we previously created for testing.     In the top-left path field, type /tw and click the bottom-right Execute button. Note the tw_test_01.txt file which we previously created for testing.     As the tw_test_01.txt file (and its parent folder) were items which we custom-created for this guide, you should now be 100% convinced that connectivity between Foundation and the EMS is dynamically working.   If so desired, you could explore into other folders (or even add additional files to these folders), run the BrowseDirectory Service again, and confirm that Foundation is now aware of the EMS and actively communicating.     Step 6: Next Steps   Congratulation! You've completed the Install the Edge MicroServer (EMS) guide.   In this guide, you learned how to:   Install the EMS Configure the EMS Connect the EMS to ThingWorx Foundation   The next guide in the Medical Device Service learning path is Setup a Raspberry Pi as an IoT Device.    The next guide in the Vehicle Predictive Pre-Failure Detection with ThingWorx Platform learning path is Use the EMS to Create an Engine Simulator.   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Connect Connect Industrial Devices and Systems   Additional Resources   If you have questions, issues, or need additional information, refer to the:   Resource Link Community Developer Community Forum

Starting with ThingWorx Manufacturing Apps 8.1, a Connection Info box was added to Controls Advisor that will display the Configuration settings needed in KEPServerEX. In Controls Advisor, select the server instance you are connecting with, then select the Key icon Be sure the information displayed here matches the settings you have in place in your KEPServerEX Project Properties in the ThingWorx property group.    

Applicable Releases: ThingWorx Platform 8.0 to 8.5; ThingWorx Navigate 1.5.0 to 8.5.0   Description:   Definition and concepts of Single Sign On (SSO), terminologies, components and architecture, as well as configuration prerequisites and high level steps to configure using PingFederation with Windchill and Navigate and main troubleshooting techniques    

  Step 8: Tasks If you are using the built-in Tasker to drive data collection or other types of repetitive or periodic activities, create a function for the task. Task functions are registered with the Tasker and then called at the rate specified after they are registered. The Tasker is a very simple, cooperative multitasker, so these functions should not take long to return and most certainly must not go into an infinite loop. The signature for a task function is found in [C SDK HOME DIR]/src/utils/twTasker.h. The function is passed a DATETIME value with the current time and a void pointer that is passed into the Tasker when the task is registered. After creating this function, it will need to be registered using the twApi_CreateTask function after the connection is created. Below shows an example of creating this function, registering this function, and how this function can be used. #define DATA_COLLECTION_RATE_MSEC 2000 void dataCollectionTask(DATETIME now, void * params) { /* TW_LOG(TW_TRACE,"dataCollectionTask: Executing"); */ properties.TotalFlow = rand()/(RAND_MAX/10.0); properties.Pressure = 18 + rand()/(RAND_MAX/5.0); properties.Location.latitude = properties.Location.latitude + ((double)(rand() - RAND_MAX))/RAND_MAX/5; properties.Location.longitude = properties.Location.longitude + ((double)(rand() - RAND_MAX))/RAND_MAX/5; properties.Temperature = 400 + rand()/(RAND_MAX/40); /* Check for a fault. Only do something if we haven't already */ if (properties.Temperature > properties.TemperatureLimit && properties.FaultStatus == FALSE) { twInfoTable * faultData = 0; char msg[140]; properties.FaultStatus = TRUE; properties.InletValve = TRUE; sprintf(msg,"%s Temperature %2f exceeds threshold of %2f", thingName, properties.Temperature, properties.TemperatureLimit); faultData = twInfoTable_CreateFromString("message", msg, TRUE); twApi_FireEvent(TW_THING, thingName, "SteamSensorFault", faultData, -1, TRUE); twInfoTable_Delete(faultData); } /* Update the properties on the server */ sendPropertyUpdate(); } … twApi_CreateTask(DATA_COLLECTION_RATE_MSEC, dataCollectionTask); … while(1) { char in = 0; #ifndef ENABLE_TASKER DATETIME now = twGetSystemTime(TRUE); twApi_TaskerFunction(now, NULL); twMessageHandler_msgHandlerTask(now, NULL); if (twTimeGreaterThan(now, nextDataCollectionTime)) { dataCollectionTask(now, NULL); nextDataCollectionTime = twAddMilliseconds(now, DATA_COLLECTION_RATE_MSEC); } #else in = getch(); if (in == 'q') break; else printf("\n"); #endif twSleepMsec(5); }   Step 9: File Transfer Example To handle file transfers, a virtual directory is created in the SteamSensor1 entity and in the [C SDK HOME DIR]/examples/FileTransferExample application directory. The source code used for this example is found in [C SDK HOME DIR]/examples/FileTransferExample/src/main.c. Inside of the [C SDK HOME DIR]/examples/FileTransferExample folder, create the folder structure shown below: /transfer/ /transfer/incoming/ /transfer/outgoing/ Inside of the /transfer/outgoing/ directory, create and open a file with the name outgoing.txt. Once the outgoing.txt document is open, add the following text, save, and close the file: Hello. This is a file coming from the client application. Navigate to the [C SDK HOME DIR]/examples/FileTransferExample/src/main.c code and update the lines below with the appropriate information for your IP, port, and the “admin_key” Application Key’s keyId value in the ThingWorx Composer: /* Server Details */ #define TW_HOST "127.0.0.1" #define TW_PORT 80 #define TW_APP_KEY "ce22e9e4-2834-419c-9656-ef9f844c784c" To support file transfers in your client application, you must use the twFileManager_AddVirtualDir function in order to create the virtual directories in the entity with such a capability. It will also define the directories available for file operations. A virtual directory maps a unique name to an absolute path of a directory in the file system. All subdirectories of the specified directory are exposed to the server. You can define multiple virtual directories. The directories do not need to be contiguous.   Staging Directory As an optional, but recommended step, you should set the directory that the application should use for staging when performing file transfers. This can be seen in the line below and should be done before initializing the FileManager. The default directory of the FileManager is most likely owned by root and will require a change to either the location of the staging directory and the ownership of the staging directory, or running the application as a User with the correct permissions. twcfg.file_xfer_staging_dir = "staging"; The example provided uses the TW_SHARE_DIRECTORY macro to create two virtual directories that will act as the root directories in the virtual file system of this application are added. The client is then started as follows with the necessary TW_ADD_FILE_TRANSFER_SHAPE function being called: TW_ADD_FILE_TRANSFER_SHAPE(); TW_SHARE_DIRECTORY("in", "/transfer/incoming/"); TW_SHARE_DIRECTORY("out", "/transfer/outgoing/"); The creations of the payloads used to create the remote directories on the platform have been moved to a helper function below to make the design cleaner: int setupSystemRepo(const char * remoteInPath, const char * remoteOutPath, const char * remoteFile); After our remote directories and files have been setup, it is time to perform the file transfers. Normally, this would mean invoking the Copy service for a Subsystem, but two functions have been created to make this process easier: int twFileManager_GetFile(const char * sourceRepo, const char * sourcePath, const char * sourceFile, const char * targetRepo, const char * targetPath, const char * targetFile, uint32_t timeout, char asynch, char ** tid) int twFileManager_SendFile(const char * sourceRepo, const char * sourcePath, const char * sourceFile, const char * targetRepo, const char * targetPath, const char * targetFile, uint32_t timeout, char asynch, char ** tid) The table below displays an example of the first set of parameters:   Parameter     Example                              Description sourceRepo SystemRepository The name of FileRepository or RemoteThing to transfer the file FROM. sourcePath outgoing The path specifying the location of the source file. sourceFile The name of the source file.   targetRepo SteamSensor1 The name of FileRepository or RemoteThing to transfer the file TO. targetPath incoming The path specifying the destination location of the file. targetFile incoming.txt The name of the file at the target. This name can differ from the sourceName. timeout 15,000 The amount of time (in seconds) to wait for a synchronous transfer to complete before cancelling the transfer. async false If false, the service call will block for timeout seconds or until the transfer completes. tid incoming0123 The unique TID associated with the file.   The C SDK also provides the ability to create a FileCallback function that the FileManager will call that function when any file transfer events occur. You can provide a wildcard filter so that only file transfer Events of files that match the filter call the callback function. In addition, callbacks can be set up as “one-shots” such that the callback is unregistered automatically after it is invoked the first time.   NOTE: An optional file transfer callback is registered in the code and provided. You will see the output from the function as files are sent and received.   After running this application, you will notice a new file in the transfer/incoming folder after refreshing. This is the file that we created in the ThingWorx Composer file system for the SystemRepository Entity and was able to copy from that location to our local project. We have also sent a file to the server’s SystemRepository. The BrowseFileSystem and GetFileListing services can be used to check for the folders and files created. twFileManager_RegisterFileCallback(fileCallbackFunc, NULL, FALSE, NULL);   Step 10: Support Other Platforms All Websocket errors indicate some general issue communicating with the ThingWorx platform. If you experience an issue connecting, refer to the table below for a list of websocket errors, their corresponding codes, and an explanation of the issue.   Code   Message                                                                       Troubleshooting 200 TW_UNKNOWN_WEBSOCKET_ERROR An unknown error occurred on the websocket. 201 TW_ERROR_INITIALIZING_WEBSOCKET An error occurred while initializing the websocket. Check your websocket configuration parameters for validity. 202 TW_TIMEOUT_INITIALIZING_WEBSOCKET A timeout occurred while initializing the websocket. Check the status of the connection to ThingWorx. 203 TW_WEBSOCKET_NOT_CONNECTED The websocket is not connected to ThingWorx. The requested operation cannot be performed. 204 TW_ERROR_PARSING_WEBSOCKET_DATA An error occurred while parsing websocket data. The parser could not break down the data from the websocket. 205 TW_ERROR_READING_FROM_WEBSOCKET An error occurred while reading data from the websocket. Retry the read operation. If necessary, resend the data. 206 TW_WEBSOCKET_FRAME_TOO_LARGE The SDK is attempting to send a websocket frame that is too large. The Maximum Frame Size is set when calling twAPI_Initialize and should always be set to the Message Chunk Size (twcfg.message_chunk_size). 207 TW_INVALID_WEBSOCKET_FRAME_TYPE The type of the frame coming in over the websocket is invalid. 208 TW_WEBSOCKET_MSG_TOO_LARGE The application is attempting to send a message that has been broken up in to chunks that are too large to fit in a frame. You should not see this error. 209 TW_ERROR_WRITING_TO_WEBSOCKET An error occurred while writing to the Web socket. 210 TW_INVALID_ACCEPT_KEY The Accept key sent earlier from ThingWorx is not valid.   Next Steps Congratulations! You've successfully completed the C SDK Tutorial, and learned how to utilize the resources provided in the Edge SDK to create your own application.   This is the last guide in the Connect and Configure Industrial Devices and Systems Learning Path.  If you wish to return to the Learning Path, click the link.   Additional Resources If you have questions, issues, or need additional information, refer to:  Resource Link Community Developer Community Forum Support C Edge SDK Help Center

Learn how to create a web application to monitor and control an Allen-Bradley PLC.   GUIDE CONCEPT   This guide will create a ThingWorx Foundation Mashup GUI to monitor and control an Allen-Bradley PLC connected via ThingWorx Kepware Server.   YOU'LL LEARN HOW TO   Create a Mashup Add Widgets Access backend data via Mashup Data Services Tie data to Widgets Create a simple web application that monitors and controls a PLC   NOTE:  The estimated time to complete all parts of this guide is 30 minutes.     Step 1: Learning Path Overview   Assuming you are using this guide as part of the Rockwell Automation Learning Path, then you have now completed each of the following installations:   Connected Components Workbench ThingWorx Kepware Server ThingWorx Foundation (for Windows)   You've also connected an Allen-Bradely PLC to Connected Components Workbench and then to ThingWorx Kepware Server.   You have propagated that information further from ThingWorx Kepware Server into Foundation.   In this final step, we'll create a simple Mashup to visualize the interface from Foundation to ThingWorx Kepware Server to the PLC.   NOTE: Both Rockwell Automation's Connected Components Workbench and ThingWorx Kepware Server are time-limited trials. If significant time has passed while persuing this Learning Path, you may need to reinitialize them. Consult the Troubleshooting step of this guide for more information.       Step 2: New Mashup   A Mashup is a Graphical User Interface (GUI) to interact with your application.   In this step, you will create a new, blank Mashup. You will later populate it with Widgets (graphical elements) and tie those elements to data.   In the top-left of ThingWorx Composer, click the Browse folder icon. Click VISUALIZATION > Mashups.   Click + New.   Select Responsive, then click OK. A new Mashup tab will open.     In the Name field, enter RWLP_Mashup. If Project is not already set, click the + in the Project text box and select the PTCDefaultProject. At the top, click Save.     Step 3: Add Widgets   Widgets are drag-and-drop, stand-alone, graphical elements which you can add to your Mashup to represent certain pieces of backend data.   In this step, you will add a pair of Checkboxes to represent the PLC functionality.   At the top of the RWLP_Mashup tab, click Design. It may take a few moments for the Mashup Builder interface to load.     Click The Widgets tab, then In the Filter field on the left, enter check. Drag-and-drop a Checkbox widget onto the central Canvas area.   Drag-and-drop a second Checkbox onto the Canvas.   At the top, click Save.     Step 4: Add Data    To have the Checkbox Widgets actually interact with the PLC, you need to bind them to the backend data.   To do so, you will make use of a Mashup Data Service from the previously-created PLCcoils Thing. At the top-right, click the Data tab, then click the + symbol.   In the Add Data pop-up window, enter plc in the Entity Filter search box.   Select the PLCcoils Thing. In the Services Filter search box, search for getprop.   Click the right arrow to select GetProperties. Check the box for Execute on Load under Selected Services. This causes the Service to be automatically executed upon the Mashup being loaded. In the Services Filter search box, search for setprop. Click the right arrow to select SetProperties. Note that you should keep Execute on Load un-checked for this Service, as we do NOT want it to automatically execute on Mashup load.     Click Done, then click the > to expand both GetProperties and SetProperties.   At the top, click Save.     Click here to view Part 2 of this guide.

Composer Enhancement: -Improved workflow support NG Composer challenging to navigate -> Usability challenges with editing and viewing data Feature: -Tab style editing support -Horizontal tabs -New Grids with Resizing -Resizing in Entity Grids -Schedule Editor Problem: Need modernization of platform visualization toolset -> -New Webcomponent widgets -Responsive layout now GA -Theming now GA -Key messaging -New ability to build responsive modern web applications   Theming and Theme editor -Centralized style management -Easily apply to all Mashups of an applications -Bindable, can be changed dynamically -Set Colors Typography, Lines, Borders, States -Set globally or by group of elements (buttons, grids, inputs) -Mashup Preview can be set   New Widgets in 8.5 -Breadcrumb -Dynamic panel -Icon -Image -List Shuttle -Property Display -Slider -Value Display -Advanced Grid now part of platform Functions: -Confirmation -Event Router -Logout  -Navigation -Status Message   Responsive Layout -New responsive layout editor, based on Flex -Content lays out according to rules, adapts to the screen size and settings -Static and size range support   Migration When you open a mashup containing legacy widgets for which there are web component replacements available OR You open a mashup containing legacy layouts, a banner appears at the top of the design page Clicking Yes will migrate to new widgets and new flex layout -Bindings in the mashup are retained -Recommended to review widgets sizes   Layout Migration -Static layous are migrated to a responsive flex container Q: There is still no Right mouse click support?  A: We don't have a right click context menu yet, but we're looking into what can be included based on the context for a future release. Q: With flex containers, is it still possible to create a mashup with two columns, one covering 1/3 of the screen, the other 2/3 of the screen, when the size of the screen is not known upfront? A: Correct - you can set container rules to grow and shrink (in your case, set one container to use 1/3rd and the other 2/3rd) Q: Do we have the cut/paste function in the responsive containers so we're able to move content around? A: Yes, now you can move the whole container too! You can either use the cut/ copy/ paste from the toolbar, or use keyboard shortcuts (shift for cut/ move and alt for copy). Q: The old layout widget allowed setting column size as percentage, rather than absolute size. How can that be done in containers? A: With containers, it uses the standard flex-grow and flex-shrink css properties. We have Grow Ratio and Shrink Ratio properties available, and you can set the values there. Q: How are we addressing the expand/collapse functions we used to have in the headers/footers/righ&left side bar? A: Each container  will have an option to Expand/ Collapse. Based on where the container is located (left/ right or top/ bottom), it will expand accordingly - so left/ right sidebar or header/ footer. Q: Does it show which widgets are undergoing the changes from legacy to new? A: The legacy widgets are grouped in the 'Legacy' widget category, and are indicated with an icon noting it's a legacy widget. Q: What about migrating from widget from extension (ie advanced grid) ? Those will be replaced also? A: Correct - when you move to 8.5, you won't have to import the extension any longer. If you have any Mashups with the Advanced Grid in place, it'll pick it up. Q: Can we add CSS to the themes? A: Yes, you can add. The Custom CSS tab is available for Themes specifically too. Q: Bindings of containers won't be saved - does that mean that if we use contained mashup with mashup parameters, all bindings will be lost? A: The bindings within the container should not change; the Mashup parameters will be exposed so that you can bind in/ out. The bindings should be retained - when you migrate from the old layout to the new, any bindings you have should not be lost/ broken.

This script finds an existing Expression Rule and applies it to an asset (via asset includes). Parameters: model - model name serial - serial number exprRuleName - name of the Expression Rule import static com.axeda.sdk.v2.dsl.Bridges.* import net.sf.json.JSONObject import com.axeda.drm.sdk.scripto.Request import com.axeda.services.v2.Asset import com.axeda.services.v2.AssetReference import com.axeda.services.v2.AssetCollection import com.axeda.services.v2.AssetCriteria import com.axeda.services.v2.ExpressionRule import com.axeda.services.v2.ExpressionRuleCriteria /* * ApplyExpRuleToAsset.groovy * * Finds an existing Expression Rule and includes an asset into it. * * @param model        -   (REQ):Str model of the asset. * @param serial        -   (REQ):Str serial number of the asset. * @param exprRuleName        -   (REQ):Str name of the Expression Rule. * * @author Sara Streeter <sstreeter@axeda.com> */ def response = [:] def root = [:] try {    AssetCriteria assetCriteria = new AssetCriteria()    assetCriteria.modelNumber = Request.parameters.model    assetCriteria.serialNumber = Request.parameters.serial    def findAssetResult = assetBridge.find(assetCriteria)    def asset = findAssetResult.assets[0]    ExpressionRuleCriteria expressionRuleCriteria = new ExpressionRuleCriteria()    expressionRuleCriteria.name = Request.parameters.exprRuleName    def expressionRuleFindResult = expressionRuleBridge.find(expressionRuleCriteria)    def expressionRule = expressionRuleFindResult.expressionRules[0]   def expAssets =  expressionRule.includedAssets.add(asset)   expressionRuleBridge.update(expressionRule)   response = [        "expressionRule":expressionRule.name,       "includedAsset": asset.serialNumber        ] } catch (Exception e) {      response = [             faultcode: 'Groovy Exception',             faultstring: e.message     ]; } return ["Content-Type": "application/json","Content":JSONObject.fromObject(response).toString(2)]

  Discover how ThingWorx advance tree grids and grids can be implemented in a compelling Mashup design.   Guide Concept   This project will introduce how to create complex user interfaces that are built by using Mashup grids and JavaScript services.   Following the steps in this guide, you will build a web application with advanced data displays. We will teach you how to create a professional user interface that effectively conveys information to users.   You'll learn how to   Create dynamic tree grids to display hierarchy. Create dynamic grids to display growing data number of data points.   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes       Step 1: What Are Dynamic Grids   In the Mashup Builder, we utilize Functions to create added capabilities in our Mashups. Whether we are navigating to another Mashup or triggering events based on some action. Functions are your best friends when creating more advanced Mashups.   Function  Description   Auto Refresh  Refreshes data automatically for widgets in a mashup.  Confirmation  Displays a confirmation dialog box.  Events Router  Routes multiple input sources to one output of the same type.  Expression  Evaluates JavaScript expressions.  Logout  Ends the current user session and redirects to a mashup or a Web page.  Navigation  Navigates from one mashup to another.  Status Message  Displays information, error, or warning messages in a mashup.  Validator  Validates data from input parameters by using JavaScript expressions.   In the next sections, we will cover some of these Functions and showcase how to add them to your Mashups.     Step 2: Create A Dynamic Grid   Let's start things off by creating a simple Expression Function. This Expression will show or hide a label based on whether a checkbox is checked or not. This simple expression can be expanded to your use case.   It is VERY important to note that in an Expression Function (and also found in Services and Validation Functions) the output of the Function will be the result variable. Let's create our Mashup, then go over what is involved in an Expression.   In the ThingWorx Composer, click the + New at the top of the screen.   Select Mashup in the dropdown.   Select the Responsive layout then hit OK.   Set the Name to  MyFunctionsMashup. For the Project, click the + button and select PTCDefaultProject.    Under Project, click the blue Set as project context option. This will stop us from having to set the Project on every Thing we create. It should now match the following.    Click Save. Click on the Design tab at the top. This Mashup will be where we create the Majority of our Functions and capabilities. Let's start adding to our Mashup.   Click the Layout tab. Scroll down and set the Orientation to Horizontal.   Click on the Widgets tab. Type in the Filter text box for Checkbox.   Drag and drop a Checkbox Widget to the Mashup Canvas. This Checkbox will dictate whether what we show for the coming Labels and Textbox. Type in the Filter text box for Button. This Button will dictate the event that triggers our Functions. Drag and drop a Button Widget to the Mashup Canvas.   Type in the Filter text box for Label. Drag and drop TWO (2) Label Widgets to the Mashup Canvas. We will only show one Label at a time and I'll show you how.   Type in the Filter text box for Text Field. Drag and drop a Text Field Widget to the Mashup Canvas.       We have the Widgets we need to show our Expression example. Let's start with connecting the Widgets to Functions.   Click the + button in the Functions section in the bottom right.    In the New Function popup, select Expression. Set the Name of the new Expression to isCheckboxChecked.   Click Next. In the new screen, click Add Parameter. Set the Name to this new parameter as checked. Set the Base Type as BOOLEAN.   Switch the Data Change Type to ALWAYS. Switch Output Base Type to BOOLEAN.   Add the following code to the Expression area.  if(checked) { result = true; } else { result = false; }   11. Click Done.   You've now created your first expression. This expression is an example of how easy it can be done. Let's add three three additional Expressions to have some fun.   Repeat steps 1-11 in the last section for TWO (2) new Expressions. Name these Expressions setFirstLabelVisbility and setSecondLabelVisbility. You should now have three total. Repeat steps 1-8 in the last section for ONE (1) new Expression. Name this Expression setTextFieldText. We should have a Parameter called checked. Click Add Parameter again to add a Parameter named input. This fourth Expression should match the following thus far:     Switch Output Base Type to STRING. Add the following code to the Expression area:  if(checked) {     if(input && input.indexOf("YES") >= 0) {     result = input + ", YES";     } else {         result = "YES";     } } else {     result = "NO";     } 6. Click Done.   This expression will see whether or not the Checkbox is checked, then output a string of YES or a simple NO. Let's setup our connections between Widgets and Expressions.   Ensure Expressions are visible and match the following.   Click on the Checkbox in the Mashup Canvas. Click the dropdown that appears.   Drag and drop the State Property to the checked Parameter of all FOUR (4) of the Expressions.   Your bindings should match the following after you're done with setting all four.   Expand the setFirstLabelVisibility Expression (if not already expanded).   Drag the Output to the first Label and select Visible.   Expand the setSecondLabelVisibility Expression (if not already expanded).   Drag the Output to the second Label and select Visible.   Our labels are configured. Now let's setup our Text Field Widget.    Expand the setTextFieldText Expression (if not already expanded). Drag the Output to the Text Field and select Text.   Select the Button Widget in the Mashup Canvas.  Click the dropdown for the Button Widget. Drag and drop the Clicked Event to all FOUR (4) of the Expressions.   Your Button Widget should look like the following:   Select the Text Field Widget in the Mashup Canvas Click the dropdown for the Text Field Widget. Drag and drop the Text Property to the input Parameter of the setTextFieldText Expression. Click Save. Click View Mashup. Play around and see all the work you've done.   You maybe notice that both Label Widgets show or hide at the same time. To split when they will show or hide, update the code for one of the Label visibility Expressions to the following:    if(checked) {     result = false; } else {     result = true;     }   Click here to view Part 2 of this guide.  

This video continues Module 6: Predictive Models & Model Validation of the ThingWorx Analytics Training videos. It describes the remaining machine learning algorithms used by ThingWorx Analytics to build predictive models that weren't covered in Part 1. In addition, this video describes the different kinds of ensembles you can build that utilize multiple algorithms. 

    Step 9: File Transfer    To handle file transfers, create a virtual directory in the FileTransferExample Entity and in the project directory. The source code used for this example is found in com.thingworx.sdk.examples.FileTransferExample.java.   Set Up File Transfer   Right-click the project. Click New. Scroll and select Folder. Enter transfer/incoming into the text box at the bottom. Click Finish. Repeat steps 1 and 2, but create a folder called transfer/outgoing. Right-click the transfer/outgoing folder. Click New. Scroll and select File. Create a file with the name outgoing.txt. Click Finish. Once the outgoing.txt document is open, add the following text, click Save, and close the file: Hello. This is a file coming from the client application. Navigate to the FileTransferExample.java code and update the lines below with the appropriate information for your IP, port, and the admin_key Application Key’skeyId value in Composer: config.setUri("ws://127.0.0.1:80/Thingworx/WS"); config.setAppKey("ce22e9e4-2834-419c-9656-ef9f844c784c"); NOTE: Step 7 is only used for a time constraint of this guide. Best practice is to never use an Application Key for the Administrator. Provide a User with the necessary privileges and add an Application Key to that User.   FileTransferExampleHelper Methods   To support file transfers in your client application, you must use a FileTransferVirtualThing to enable the functionality and define the directories available for file operations. A virtual directory maps a unique name to an absolute path of a directory in the file system. All subdirectories of the specified directory are exposed to the server. You can define multiple virtual directories. The directories do not need to be contiguous.   The example provided creates the FileTransferVirtualThing with two virtual directories that will act as the root directories in the virtual file system of this application are added. The client is then started as follows:   All of the creations of the payloads have been moved to a helper class (FileTransferExampleHelper.java) to make the design cleaner.   The below table provides insight into some of the helper methods created to separate roles for a cleaner solution.   Method Purpose createSystemRepositoryIncomingPath Create the payload for the call to create the “incoming” directory on the SystemRepository in the ThingWorx Platform. createSystemRepositoryOutgoingPath Create the payload for the call to create the “outgoing” directory on the SystemRepository in the ThingWorx Platform. createTransferIncomingParameters Create the payload for the call to copy a file into the incoming directory on the FileTransferExample Thing in the ThingWorx Platform and the provided client application. createTransferOutgoingParameters Create the payload for the call to copy a file from the outgoing directory in the provided client application to the SystemRepository on the ThingWorx Platform.     Service Parameters   Once the connection is made, the script will call the four services. Here, we instruct the server to move the files from one repository to another.   Parameter Example Description sourceRepo “SystemRepository” The name of a FileRepository or RemoteThingWithFileTransfer Thing to transfer the file from. sourcePath “/outgoing” The path specifying the location in the file repository of the source file. sourceFile “example.txt” The name of the source file. targetRepo FileTransferExample The name of a FileRepository or RemoteThingWithFileTransfer Thing to transfer the file to. targetPath “in” The path specifying the destination location of the file. targetFile “example.txt” The name of the file at the target location. This name can differ from the sourceName parameter. timeout 15000 The amount of time to wait for the synchronous transfer to complete (seconds) before cancelling the transfer. async false If false, the service call will block for the length specified by the “timeout” parameter or until it completes.     After running this application, you will notice a new file in the transfer/incoming folder after refreshing. This is the file that we created in the ThingWorx Composer file system for the SystemRepository Entity and was copied from that location to our local project. We have also sent a file to the server’s SystemRepository. The BrowseFileSystem and GetFileListing Services can be used to check for the folders and files created.       Step 10: Troubleshooting   All Websocket errors indicate some general issue communicating with the ThingWorx platform. If you experience an issue connecting, refer to the table below for a list of websocket errors, their corresponding codes, and an explanation of the issue.   Code Message Troubleshooting 200 TW_UNKNOWN_WEBSOCKET_ERROR An unknown error occurred on the websocket. 201 TW_ERROR_INITIALIZING_WEBSOCKET An error occurred while initializing the websocket. Check your websocket configuration parameters for validity. 202 TW_TIMEOUT_INITIALIZING_WEBSOCKET A timeout occurred while initializing the websocket. Check the status of the connection to ThingWorx. 203 TW_WEBSOCKET_NOT_CONNECTED The websocket is not connected to ThingWorx. The requested operation cannot be performed. 204 TW_ERROR_PARSING_WEBSOCKET_DATA An error occurred while parsing websocket data. The parser could not break down the data from the websocket. 205 TW_ERROR_READING_FROM_WEBSOCKET An error occurred while reading data from the websocket. Retry the read operation. If necessary, resend the data. 206 TW_WEBSOCKET_FRAME_TOO_LARGE The SDK is attempting to send a websocket frame that is too large. The Maximum Frame Size is set when calling twAPI_Initialize and should always be set to the Message Chunk Size (twcfg.message_chunk_size). 207 TW_INVALID_WEBSOCKET_FRAME_TYPE The type of the frame coming in over the websocket is invalid. 208 TW_WEBSOCKET_MSG_TOO_LARGE The application is attempting to send a message that has been broken up in to chunks that are too large to fit in a frame. You should not see this error. 209 TW_ERROR_WRITING_TO_WEBSOCKET An error occurred while writing to the Web socket. 210 TW_INVALID_ACCEPT_KEY The Accept key sent earlier from ThingWorx is not valid.       Step 11: Tunneling Example    To handle file transfers, a virtual directory is created in the TunnelExample Entity and in the project directory. The source code used for this example is in com.thingworx.sdk.examples.TunnelExample.java.   To enable tunneling, create the configurations like other steps, and then either invoke ClientConfigurator.tunnelsEnabled(true), or set the tunnelsEnabled directive in your config file.   Once it connects to the server, this client binds thingName to the matching RemoteThingWithTunnels defined on the ThingWorx Platform. Once bound, the Thing can receive tunnel requests from the Platform, and facilitate tunnels to local applications.     Step 12: Next Steps    Congratulations! You've successfully completed the Java SDK Tutorial, and learned how to utilize the resources provided in the Java SDK create your own application.   The next guide in the Connect and Configure Industrial Devices and Systems learning path is C SDK Tutorial.   Learn More   We recommend the following resources to continue your learning experience:    Capability Guide Build Design Your Data Model Build Implement Services, Events, and Subscriptions   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Java Edge SDK Help Center    

The intend of this post. This post is for the user who want to validate that, the ThingWorx Analytics Services related to Confidence Models work successfully. Underneath video walk through the steps to validate the Services via a non-supported PTC Mashup. The intend of this video is uniquely to validate that, Services related to Confidence Models works successfully.  What package files are used in the video? The Mashup entities and dataset used in the video, is attached to this post. Feel free to download the files and test on your machine. Why use Confidence Models? A confidence model is a way of adding confidence interval information to a predictive model. Statistically, for a given prediction, a confidence model provides an interval with upper and lower bounds, within which it is confident, up to a certain level, that the actual value occurs. During predictive scoring, this measure of confidence provides additional information about the accuracy of the prediction. More information about Confidence Models can be found here at PTC Help Center 

This code snippet creates then deletes a data item to illustrate CRUD technique. Parameter:  model_number import com.axeda.drm.sdk.Context import com.axeda.drm.sdk.device.ModelFinder import com.axeda.drm.sdk.device.Model import com.axeda.drm.sdk.device.DeviceFinder import com.axeda.drm.sdk.data.CurrentDataFinder import com.axeda.drm.sdk.device.Device import com.axeda.drm.sdk.data.HistoricalDataFinder import groovy.xml.MarkupBuilder import com.axeda.drm.sdk.device.DataItem import com.axeda.drm.services.device.DataItemType /* * DeleteDataItem.groovy * * Delete a data item. * * @param model_number        -   (REQ):Str name of the model. * * @author Sara Streeter <sstreeter@axeda.com> */ def response = [:] def writer = new StringWriter() def xml = new MarkupBuilder(writer) try { // getUserContext is supported as of release 6.1.5 and higher     final def CONTEXT = Context.getUserContext() // find the model     def modelFinder = new ModelFinder(CONTEXT)     modelFinder.setName(parameters.model_name)     Model model = modelFinder.findOne() // throw exception if no model found     if (!model) {         throw new Exception("No model found for ${parameters.model_name}.")     } // Add a dummy data item DataItem dataitem = new DataItem(CONTEXT, model, DataItemType.STRING, "MyDataItem"); dataitem.store(); // find the data items on the model model.dataItems.each{     logger.info(it.name)     if (it.name=="MyDataItem"){         it.delete()     } } } catch (def ex) {       xml.Response() {     Fault {           Code('Groovy Exception')           Message(ex.getMessage())           StringWriter sw = new StringWriter();           PrintWriter pw = new PrintWriter(sw);           ex.printStackTrace(pw);           Detail(sw.toString())         }       } } return ['Content-Type': 'text/xml', 'Content': writer.toString()]

Applicable Releases: ThingWorx Platform 7.0 to 8.5   Description:   Introduction to Edge connectivity in Thingworx Foundation: Edge concept and definition Available edge products Why use Edge products What is Edge Microserver and Lua Script Resource What are the SDKs What are connection servers AlwaysOn and HTTP protocols ThingTemplates to connect remote devices     The session was recorded in an old ThingWorx version, but all the concepts are still applicable

Hi all,   Here is the recording of the expert session hosted in August 25th. For full-sized viewing, click on the YouTube link in the player controls.

  Step 7: Delivery Truck Model    In the Delivery Truck application, there are three Delivery Truck Things. Each Thing has a number of Properties based on its location, speed, and its deliveries carried out. In this design, when a delivery is made or the truck is no longer moving, the property values are updated. The DeliveryTruckThing class extends the VirtualThing class and based on the DeliveryTruck Entities in the Composer. After extending VirtualThing, there are a number of steps necessary to get going. For the DeliveryTruckThing and SimpleThing classes, there are a number of methods for creating Properties, Events, Services, and Data Shapes for ease of use.   The constructor for the DeliveryTruckThing takes in the name of the Thing, the description of the Thing, and the ConnectedThingClient instance used to make the connection. It then sends these values to the VirtualThing constructor as shown below.   public DeliveryTruckThing(String name, String description, ConnectedThingClient client) { super(name, description, client); ...   We use the initializeFromAnnotations method to initialize all of the annotations that we will create in this class. This is done as follows and a necessary call for VirtualThings in the constructor:   initializeFromAnnotations();   Create Properties   You can create Properties in two ways. Using annotations is the recommended method, but there are times in which programmatically creating Properties is the best option. For example, constructing dynamic features or allowing inline functionality would call for the coding style of Property creation. The following shows the Properties that correlate to those in the DeliveryTruck Entities in the Composer. To do this within the code, you would use a PropertyDefinition instance as shown in the SimpleThing.java property1 creation.   With Annotation @SuppressWarnings("serial") @ThingworxPropertyDefinitions(properties = { @ThingworxPropertyDefinition(name="Driver", description="The name of the driver", baseType="STRING", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="DeliveriesLeft", description="The number of deliveries left", baseType="NUMBER", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="Speed", description="The speed of the truck", baseType="NUMBER", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="Location", description="The location of the truck", baseType="LOCATION", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="TotalDeliveries", description="The number of deliveries", baseType="NUMBER", aspects={"isReadOnly:false"}), @ThingworxPropertyDefinition(name="DeliveriesMade", description="The number of deliveries made", baseType="NUMBER", aspects={"isReadOnly:false"}), })   Without Annotation //Create the property definition with name, description, and baseType PropertyDefinition property1 = new PropertyDefinition(property, "Description for Property1", BaseTypes.BOOLEAN); //Create an aspect collection to hold all of the different aspects AspectCollection aspects = new AspectCollection(); //Add the dataChangeType aspect aspects.put(Aspects.ASPECT_DATACHANGETYPE, new StringPrimitive(DataChangeType.NEVER.name())); //Add the dataChangeThreshold aspect aspects.put(Aspects.ASPECT_DATACHANGETHRESHOLD, new NumberPrimitive(0.0)); //Add the cacheTime aspect aspects.put(Aspects.ASPECT_CACHETIME, new IntegerPrimitive(0)); //Add the isPersistent aspect aspects.put(Aspects.ASPECT_ISPERSISTENT, new BooleanPrimitive(false)); //Add the isReadOnly aspect aspects.put(Aspects.ASPECT_ISREADONLY, new BooleanPrimitive(false)); //Add the pushType aspect aspects.put("pushType", new StringPrimitive(DataChangeType.NEVER.name())); //Add the defaultValue aspect aspects.put(Aspects.ASPECT_DEFAULTVALUE, new BooleanPrimitive(true)); //Set the aspects of the property definition property1.setAspects(aspects); //Add the property definition to the Virtual Thing this.defineProperty(property1);   Property values can either be set with defaults using the aspects setting. Nevertheless, setting a default value will affect the Property in the ThingWorx platform after binding. It will not set a local value in the client application. In this example, we make a request to the ThingWorx Composer for the current values of the delivery truck properties using our getter methods:   //Get the current values from the ThingWorx Composer deliveriesMade = getDeliveriesMade(); deliveriesLeft = getDeliveriesLeft(); totalDeliveries = getTotalDeliveries(); driver = getDriver(); speed = getSpeed(); location = getLocation();   Create Event Definitions   As with Properties, Events can be created using annotations or code as shown in SimpleThing.java. Here we create the DeliveryStop event that is in the DeliveryTruck instances.   With Annotation @ThingworxEventDefinitions(events = { @ThingworxEventDefinition(name="DeliveryStop", description="The event of a delivery truck stopping to deliver a package.", dataShape="DeliveryTruckShape", isInvocable=true, isPropertyEvent=false) })   Without Annotation //Create the event definition with name and description EventDefinition event1 = new EventDefinition(event, "Description for Event1"); //Set the event data shape event1.setDataShapeName("SimpleDataShape"); //Set remote access event1.setLocalOnly(false); //Add the event definition to the Virtual Thing this.defineEvent(event1);   Create Remote Services   With remote Services, the implementation is handled by the Java application and can be called either within the application or remotely, by the Composer while a connection is established. The GetTruckReadings Service, a dummy Service used as an example of how to create a remote Service, populates an Info Table and returns that Info Table for whoever would like to use it. You can see how it is possible to define remote Services that can later be bound to Things in the Composer. A Service is defined using @ThingworxServiceDefinition annotation and its result is defined using @ThingworxServiceResult. These annotations take various parameters among including:   Name Description baseType Aspects In the second line, you can see the name of the result being set by the CommonPropertyNames field to keep development consistent with creating Things in the Composer.   With Annotation @ThingworxServiceDefinition(name="GetTruckReadings", description="Get Truck Readings") @ThingworxServiceResult(name=CommonPropertyNames.PROP_RESULT, description="Result", baseType="INFOTABLE", aspects={"dataShape:DeliveryTruckShape"})   Without Annotation //Create the service definition with name and description ServiceDefinition service1 = new ServiceDefinition(service, "Description for Service1"); //Create the input parameter to string parameter 'name' FieldDefinitionCollection fields = new FieldDefinitionCollection(); fields.addFieldDefinition(new FieldDefinition("name", BaseTypes.STRING)); service1.setParameters(fields); //Set remote access service1.setLocalOnly(false); //Set return type service1.setResultType(new FieldDefinition(CommonPropertyNames.PROP_RESULT, BaseTypes.STRING)); //Add the service definition to the Virtual Thing this.defineService(service1); //Service1 Definition public String Service1(String name) throws Exception { String result = "Hello " + name; return result; }     Create Data Shapes   Data Shapes must be created using code as seen in DeliveryTruckThing.java as shown below:   // Data Shape definition that is used by the delivery stop event // The event only has one field, the message FieldDefinitionCollection fields = new FieldDefinitionCollection(); fields.addFieldDefinition(new FieldDefinition(ACTIV_TIME_FIELD, BaseTypes.DATETIME)); fields.addFieldDefinition(new FieldDefinition(DRIVER_NAME_FIELD, BaseTypes.STRING)); fields.addFieldDefinition(new FieldDefinition(TRUCK_NAME_FIELD, BaseTypes.BOOLEAN)); fields.addFieldDefinition(new FieldDefinition(TOTAL_DELIVERIES_FIELD, BaseTypes.NUMBER)); fields.addFieldDefinition(new FieldDefinition(REMAIN_DELIVERIES_FIELD, BaseTypes.NUMBER)); fields.addFieldDefinition(new FieldDefinition(LOCATION_FIELD, BaseTypes.LOCATION)); defineDataShapeDefinition("DeliveryTruckShape", fields);   NOTE: It is possible to create a Data Shape, and then use it in a Service definition within your code as StringIndex property, StringMap Data Shape, and StringMapService Service in SimpleThing.java.     Scan Cycles   To complete the implementation of the VirtualThing class, we recommend you provide an override and implementation to the processScanRequest method. This method provides a universal method for all VirtualThing implementations. This method could be used or a new method could be created for this purpose. The processScanRequest method in VirtualThing.java does not have an implementation of its own. An implementation from DeliveryTruckThing.java can be seen below:   // The processScanRequest is called by the DeliveryTruckClient every scan cycle @Override public void processScanRequest() throws Exception { // Execute the code for this simulation every scan this.scanDevice(); this.updateSubscribedProperties(1000); this.updateSubscribedEvents(1000); }   Bound Properties in Cycle   The scanDevice method in DeliveryTruckThing.java performs a number of tasks from retrieving property values to firing events. To retrieve a property using binding, a request is made to the client using the name of the property. A good programming practice is to handle how these properties are accessed and set. Note that the update method for properties and events must be used after queueing an event or setting a Property value. In the example below, getter and setter methods are used for added control. The getProperty() call is used on the VirtualThing:   public Double getSpeed() { return (Double) getProperty("Speed").getValue().getValue(); } public void setSpeed() throws Exception { setProperty("Speed", this.speed); } public Location getLocation() { return (Location) getProperty("Location").getValue().getValue(); } public void setLocation() throws Exception { setProperty("Location", this.location); }     Step 8: Services and Events   Events and Services can be very useful. Events are a good way to make a Service be asynchronous. You’re able to call a Service, let it return and then your Entity can subscribe to your Event and not keep the original Service function waiting. Events are also a good way to allow the platform to respond to data when it arrives on the edge device without it having to poll the edge device for updates. The DeliveryTruck Entities in the Composer contains a remote Event. You can find a remote Service within the SimpleThing_1 entity.   Fire Event To fire an Event, create a ValueCollection instance, and load it with the necessary fields for the Data Shape of that Event. Then, send the client the request to fire the Event with the collected values, the Event, and information to find the Entity the Event belongs to as shown below in DeliveryTruckThing.java:   // Set the event information of the defined data shape for a truck stop event ValueCollection payload = new ValueCollection(); // Set values to the fields payload.put(LOCATION_FIELD, new LocationPrimitive(location)); payload.put(REMAIN_DELIVERIES_FIELD, new NumberPrimitive(deliveriesLeft)); payload.put(ACTIV_TIME_FIELD, new DatetimePrimitive(DateTime.now())); payload.put(TOTAL_DELIVERIES_FIELD, new NumberPrimitive(totalDeliveries)); payload.put(DRIVER_NAME_FIELD, new StringPrimitive(driver)); payload.put(TRUCK_NAME_FIELD, new StringPrimitive(super.getBindingName())); // This will trigger the 'DeliveryStop' of a remote thing // on the platform. super.queueEvent("DeliveryStop", new DateTime(), payload);   Execute Service   To execute a Service, you must create a ValueCollection instance, and load it with the necessary parameters of the Service. The ValueCollection is created only when Services and Events are not defined by annotations. Afterwards, you would send the client the request to execute the Service with the parameter values, the Service name, the timeout setting in milliseconds for the Service to finish executing, and information to find the Entity the Service belongs to as shown below in SimpleThingClient.java:   public String callService(String name) throws Exception{ ValueCollection payload = new ValueCollection(); payload.put("name", new StringPrimitive("Timothy")); InfoTable table = handleServiceRequest(service, payload); return table.getFirstRow().getStringValue("name"); }   TIP: The code for creating the Service and Event should be in the constructor of the extended VirtualThing (or a method called from the constructor). Also, the Service code examples will work as long as the actual Service is defined. You can see from the examples that the annotation method is much cleaner.     Click here view Part 5 of this guide.

  Use the Statistical Calculation Thing Shape to Execute Common Statistical Functions   GUIDE CONCEPT   This project will introduce the Statistical Calculation Thing Shape.   The steps in this guide outline how to utilize Descriptive Analytics in ThingWorx Analytics to perform common mathematical analyses on data sets. You will learn how to use the Statistical Calculation Thing Shape's built-in functionality to calculate the mean, median, mode, and other useful insights.     YOU'LL LEARN HOW TO   Create a Value Stream and Data Shape Create a Thing with the Statistical Calculation Thing Shape Modify a Property to record values to the Value Stream Utilize various built-in services to perform the Mean, Median, Mode, and Standard Deviation calculations   NOTE: The estimated time to complete this guide is 30 minutes.     Step 1: Introduction   Descriptive Analytics enables users to perform on-demand common statistical calculations and enable statistical monitoring. Output from these Services can then easily be added to IoT applications built with the ThingWorx platform.   For example, output generated by Descriptive Analytics can be used to build solution-specific visualizations (Mashups or Widgets), create Alerts based on logged Property values, or generate transformed data for machine learning processes.   Descriptive Analytics includes two microservers, each with its own set of statistical Services. This guide will deal specifically with the Statistical Calculation Thing Shape.   This Thing Shape will add a variety of built-in Services to any Thing or Thing Template you choose, such as calculations for Mean, Median, Mode, or Standard Deviation.   To perform these statistical calculations, a Property must have time-series data logged to a Value Stream.   In addition, the Statistical Calculation Thing Shape has been optimized to perform calculations only on particular time ranges and with a maximum entry-count. This helps minimize some of the performance hits that can occur from repeatedly accessing Value Streams.   You perform this "data grooming" via the QueryTimedValuesForProperty Service, which is also part of the Statistical Calculation Thing Shape.   In addition to the name of a Property with values logged to a Value Stream, you also provide a Start Date, End Date, and Max Item Count.   The QueryTimedValuesForProperty Service then formats the values from the Value Stream to work with for the other built-in statistical calculation Services.   Step 2: Create Prerequisites   The inputs to the built-in Services of the Statistical Calculation Thing Shape require time-series data stored in a Value Stream. Setting a Thing's Properties to be Logged will store valid time-series data on which to perform Descriptive Analytics.   Create Value Stream   Follow the steps below to create a Value Stream that you will later tie to a Thing.   On the ThingWorx Composer Browse tab, click DATA STORAGE > Value Streams, + New.   Select ValueStream and click OK.   In the Name field, enter scts_valuestream. If Project is not already set, search for and select PTCDefaultProject.   At the top, click Save.   Create Data Shape   You will need a Data Shape to format the timed_values Property we will create in the next step.   On the ThingWorx Composer Browse tab, click MODELING > Data Shapes, + New.   In the Name field, enter scts_timed_values_datashape. If Project is not already set, search for and select PTCDefaultProject.   At the top, click Field Definitions.   Click + Add. On the right slide-out, in the Name field, enter value. Change the Base Type to NUMBER.   At the top-right, click the "check with a +" icon for Done and Add. In the Name field, enter timestamp. Change the Base Type to LONG.   At the top-right, click the "check" icon for Done. At the top, click Save.       Step 3: Create Thing   Next, you will create a Thing and tie the previously-created Value Stream to it.   You will assign the Statistical Calculation Thing Shape to get a variety of built-in analytics Services to manipulate the data. You will also create a series of Properties to facilitate the new Services.   On the ThingWorx Composer Browse tab, click MODELING > Things, + New.   In the Name field, enter scts_thing. If Project is not already set, search for and select PTCDefaultProject. In the Base Thing Template field, search for and select GenericThing. In the Implemented Shapes field, search for and select StatisticalCalculationThingShape. In the Value Stream field, search for and select scts_valuestream.   At the top, click Save.   Add Properties   Next, you will add a series of Properties to scts_thing.   Perform the following steps repeatedly until all Properties have been added.   At the top, click Properties and Alerts.   Click + Add. On the right slide-out, in the Name field, enter numbers. Change the Base Type to NUMBER. Click Persistent. Click Logged.   At the top-right, click the "check with a +" icon for Done and Add. Repeat steps 3-7 until all of the properties in the table below have been added. NOTE: For the final standarddev_result Property, do NOT click Done and Add; you'll just click the check for Done instead. Property Name Base Type Data Shape Persistent  Logged start_time DATETIME N/A Checked NOT checked end_time DATETIME N/A Checked NOT checked timed_values INFOTABLE scts_timed_values_datashape Checked NOT checked mean_result NUMBER N/A Checked NOT checked median_result NUMBER N/A Checked NOT checked mode_result INFOTABLE none, i.e. leave it blank Checked NOT checked standarddev_result NUMBER N/A Checked NOT checked     At the top-right, click the "check" icon for DONE. At the top, click Save.   Step 4: Set Properties   You will now set the properties to guarantee that each calculation gives us a different answer.   Mean is the average. Median is the "middle" number from the dataset. Mode is the most common number. Standard Deviation is a measure of the "dispersion" of the dataset.   You will use the following dataset: 1, 5, 9, 5, 9, 1, 9.   The mean is 39 / 7 = 5.571...   The median is 5, as 5 is the middle of 1, 5, and 9.   Mode is 9, because 9 appears most commonly in the dataset.   Standard Deviation is 3.5989...   Perform the following steps to enter the above values into the numbers property.   Set numbers   Under the Value column and on the numbers property row, click the "pencil" icon for Set value of property.   On the right slide-out, enter 1.   At the top-right, click the "check" icon for Done. At the top, click Save.   Repeat steps 1-4 above, changing the value each time according to the table below: Value Change Count  Entered Value 2nd 5 3rd 9 4th 5 5th 9 6th 1 7th 9   You also need to set the start_time and end_time. These are dates used to define the time-period in which the Statistical Calculation Thing Shape will search for values.   For instance, you could set the calculations to run at midnight, and then use the past 24-hours as your time-period.   For this example, set dates to be 24 hours prior to the time at which you set the above values of the numbers property, through 24 hours in the future.   Set start_time   Under the Value column and on the start_time Property row, click the "pencil" icon for Set value of property.   On the right slide-out, search for and select the previous day.   At the top-right, click the "check" icon for Done. At the top, click Save.   Set end_time   Under the Value column and on the end_time property row, click the "pencil" icon for Set value of property.   On the right slide-out, search for and select the following day. At the top-right, click the "check" icon for Done. At the top, click Save.     Click here to view Part 2 of this guide.

Applicable Releases: ThingWorx Navigate 1.8.0 to 1.9.0     Description:   New improvements of the ThingWorx Navigate Installer with the following agenda: What's new Load Balancer Multiple Windchill Systems Integration Runtime NSSM How to select files to download Installer installation steps Demo Questions         Additional information How to install PTC Navigate