IoT & Connectivity Tips

ThingTemplate   A ThingTemplate, at it's root is nothing but a class definition. Things are instances of a ThingTemplate which encapsulates business logic for a specific asset class.   This could be equated to that of a Class in an object-oriented programming concept. ThingTemplates provides initial state & implementation of behaviour for the Things implementing it. See ThingTemplates in Help Center & Similarities to Object-Oriented Programming for more.   ThingTemplate Use Cases   It's among the many building blocks for an IoT Solution which belong to the highest level objects created and maintained, i.e. Entities. There are several Entity Types in ThingWorx allowing users to model the physical world within the virtual realm of ThingWorx platform. There are following type of entities available within ThingWorx for modeling:   Things Thing Shapes Thing Templates Additional useful read Programming for the IoT Thing-Centric vs Traditional Query Approaches Model-View-Controller (MVC)   Ways to explore the out of the box provided ThingTemplates   All the available ThingTemplates can be listed and reviewed by navigating to the /Server via the ThingWorx REST API. List of ThingTemplates can be reviewed by using one of the following : <serverName>:<portNumber>/Thingworx/Server in a web browser and then locate and click on the ThingTemplates, or by; Typing <serverName>:<postNumber>/Thingworx/ThingTemplates in the web browser Either of the above listed options will display the following list in the web browser   List of ThingTemplates List shows all available ThingTemplates i.e. ThingTemplates that were provided OOTB and the ones that were created by the users as well. Using the column isSystemObject one can verify if the displayed ThingTemplate is provided OOTB or is custom one created by the user.   Accessing ThingTemplate Class description / details   This is covered under the JavaDocs for the ThingWorx Platform API, which can be accessed via the API Documentation   Search for ThingTemplate for following result   API Documentation: ThingTemplate While creating a custom ThingTemplate outside of ThingWorx composer, e.g. creating ThingWorx extension it is must to have following two entities in the metadata.xml file.     <Entities> <ThingTemplate> </ThingTemplate> </Entities> Note: If Eclipse Plugin is used for creating the ThingTemplate, above mentioned entries will automatically be created in the metadata.xml     Tips & tricks How to modify Base Template for a ThingTemplate for a Thing How to iterate through list of Things to identify their ThingTemplate & based on that set a particular property in those Things Add run time permissions through script to Thing Templates, Thing Shapes, etc Changing a Thing's implemented ThingTemplate after it has been created in ThingWorx Basic troubleshooting  Error "Thing [] is not running" when editing ThingTemplates in ThingWorx Troubleshooting Entity Relationship issues in ThingWorx Best Practises How to search for All entities in ThingWorx or by Thing Type How to create custom ThingTemplate when developing custom ThingWorx Extension Inheriting Permissions from a ThingTemplate      

The following is a set of custom objects that will trigger from an Expression Rule, and cause a file uploaded by a remote agent to be sent on to the Thingworx platform instance of your choice once completed.  The expression rules should be configured as so: ​Type: ​File ​IF: ​1 == 1 ​THEN: ​ExecuteCustomObject("SendUploadedFiles") SendUploadedFiles.groovy: import com.axeda.drm.sdk.data.UploadedFile import static com.axeda.sdk.v2.dsl.Bridges.* logger.info("Executing AsyncExecutor") //Spawn async thread for each upload compressedFile.getFiles().each {   UploadedFile upFile ->     // last parameter is a timeout for the execution measured in seconds (200 minutes)     customObjectBridge.initiateAsync("SendToThingWorx",                                     [                                       fileID: upFile.id,                                       hint: parameters.hint,                                       deviceID: context.device.id                                     ], 200 * 60) }     SendToThingworx.groovy: import static com.axeda.sdk.v2.dsl.Bridges.* import com.axeda.services.v2.* import com.axeda.sdk.v2.exception.* import groovyx.net.http.HTTPBuilder import static groovyx.net.http.ContentType.* import static groovyx.net.http.Method.* import com.axeda.drm.sdk.data.*  // UploadedFileFinder stuff. import com.axeda.drm.sdk.Context import com.axeda.common.sdk.id.Identifier import org.apache.commons.codec.binary.Base64 def retStr = "this is a sample groovy script. your username: ${parameters.username}\n" def context = Context.getAdminContext() def thingName = 'ExampleThing' def thingworxHost = 'sample.cloud.thingworx.com' def twxApplicationKey = '00000000-0000-0000-0000-00000000000' def fileid = parameters.fileID def finder = new UploadedFileFinder(context) finder.setId( new Identifier( fileid.toLong()) ) UploadedFile uf = finder.find() def is = new FileInputStream( uf.extractFile() ) retStr += "UF: ${uf.name} ${uf.fileSize} ${uf.actualFileName}\n" logger.info  "UF: ${uf.name} ${uf.fileSize} ${uf.actualFileName}\n" def bOut = new ByteArrayOutputStream() int b = 0 int count = 0 while ( (b = is.read()) != -1  ) {     count ++     bOut.write(b) } is?.close() byte[] bRes = bOut.toByteArray() logger.info "Length: ${bRes.length}" retStr += "Count: ${count}  Length: ${bRes.length}\n" def b64 = new Base64() def outputStr = b64.encodeBase64String(bRes) retStr += "Length of base64 string: ${outputStr.length()}\n" logger.info "Length of base64 string: ${outputStr.length()}\n" logger.info "===========================================" logger.info outputStr logger.info "===========================================" def http = new HTTPBuilder("https://${thingworxHost}") http.request(POST, JSON) {     uri.path = "/Thingworx/Things/${thingName}/Services/SaveBinary"     body  = [path: uf.name, content: outputStr ]     headers = [appKey: twxApplicationKey ,                       Accept: 'application/json',                       "content-type": "application/json"             ]     response.success = { resp ->         println "POST response status: ${resp.statusLine}"         logger.info "POST RESPONSE status: ${resp.statusLine}"     }     response.failure = { resp ->         logger.info "RequestMessage: ${resp.statusLine}"         logger.info "Request failed: ${resp.status}"     } } return retStr    

  Basic Mashup Widgets Guide Part 3   Step 5: Gauge   A Gauge is best for displaying a quickly readable approximate value. Select the Widgets tab in the uppper panel of the left dock, then enter gauge inside the Filter field in the top left. Drag-and-drop the Gauge widget onto the bottom-center container. We will now bind the Slider to the Gauge. Click the Slider Widget in the top-right Container. Click the drop-down arrow on the left side of the Slider widget. Click and drag the Value property listed in the Slider drop-down onto the Gauge widget.   Click the # Data property that is available from the Select Binding Target pop-up.   Click Save to save your Mashup. Click View Mashup then adjust the slider to the left to see the changing value shown on the widget. Many properties are available that give control over how the Gauge widget will be displayed. Many properties can be changed both statically when designing the mashup, and dynamically in response to changes in property values.   Bindable Name Type Default Direction Description Data Number None Input Value displayed by gauge indicator MinValue Number 0 Input Value used for lowest gauge display MaxValue Number 100 Input Value used for highest gauge display Legend String None Input Text Shown under Gauge ToolTipField String None Input Text shown when mouse hovers over gauge Visible Boolean True Input Widget is visible if set to true   Static Name Type Default Description DisplayName String None Name used for widget in user-facing interactions Description String None Description used for widget in user-facing interactions MinorTicks Number 4 Number of minor ticks per interval TickLength Number 8 Tick mark length MinorTickLength Number 4 Minor tick length ValueDisplayMode None/Top/Bottom/Inside None Location on gauge where numeric value is shown. LabelDigits Number 3 Number of digits for label display LabelDecimals Number 0 Number of decimals for label display ValueDigits Number 3 Number of digits for value display ValueDecimals Number 0 Number of decimals for value display LegendDisplayMode None/Top/Bottom None Location on gauge where Legend is displayed ReferenceAngle Number 225 Angle that controls the gauge orientation (degrees) Aperture Number 270 Angle that controls the gauge size (degrees) NeedleDiameter Number 10 Diameter of the gauge needle (pixels) CenterDiameter Number 20 Diameter of the gauge center (pixels) GaugeBorder Number 20 Width of the outside gauge border (pixels)     Step 6: Grid Advanced   A Grid Advanced widget is used to display data to a mashup user in a table Select the Widgets tab in the uppper panel of the left dock, then enter grid inside the Filter field in the top-left. Drag-and-drop the Grid Advanced widget onto the top-left container on your Mashup that already has the Button Widget. Add Data Source   Before you can customize the Grid display, you must first bind an Infotable to the Grid's Data property. In this example we will use the QueryImplementingThingsWithData Service to bind a group of Things created with the same Template. We have created a file with sample entities for this exercise. Download the attached demoTractors.xml. Click Import/Export in the lower left of Composer, then select Import   Click From File in the drop down, then Browse. Browse to the demoTractors.xml file and click Open. Click Import, then Close after entities are successfully imported. Click the green + button in the Data tab on the right side of the Mashup Builder window. In the Select Entity panel click Thing Templates from the drop down.   Scroll through the available Thing Templates and select the Connected Tractors Template that was imported. Enter query into the filter text box then click the arrow to the right of QueryImplementingThingsWithData. Click the Execute on Load check box, this option will execute the QueryImplementingThingsWithData Service when the Mashup is loaded.   Click Done. Click the arrow icon to expand QueryImplementingThingsWithDate, and Returned Data. Click and drag All Data onto the Grid widget.   Click Data in the Select Binding Target pop-up.   NOTE: The Grid widget now shows Property names in the column headers.  15. Click the drop down in the upper left of the Grid widget, then click Configure Grid Columns to show the Configure Grid Columns pop-up. 16. Uncheck the check box next to the property names in the left-hand panel that you don't want shown in the Grid. NOTE: You can drag and drop the property names to change the display order. You can customize Column names and formatting by making changes in this window. 17. Click Done when you are satisfied with the column formatting options. 18. Click Save to save your Mashup. 19. Click View Mashup.         In addition to properties that give control over how a Grid widget will be displayed, the scroll position of a Grid can be read in the CurrentScrollTop property and can be set with the ScrollTop property.   Bindable Name Type Default Direction Description Data Infotable None Input The data that is displayed in the Grid EditedTable Infotable None Output The data that is in the Grid after a user edit CurrentScrollTop Number 0 Output How far down (in pixels from the top of the full data list) the Grid is currently scrolled ScrollTop Number 0 Input How far down (in pixels from the top of the full data list) the Grid will be scrolled. Visible boolean true Input Widget is visible if set to true   Static Name Type Default Description DisplayName String None Name used for widget in user facing interactions Description String None Description used for widget in user facing interactions RowFormat StateDefinition None Specify a State Formatter to control display of the data in each grid row AlignHeader Boolean False When enabled, align column headers with their data MultiSelect Boolean False allow multiple items to be selected IsEditable Boolean False Allow grid value editing in Configure Grid Columns pop-up AutoSelectFirstRow Boolean False Automatically select the first row upon initial loading of data. CellTextWrapping Boolean False Enable or disable text wrapping within the grid cells. TabSequence Number 0 Tab sequence index   Widget Events Name Description DoubleClicked Fired when user double clicks on the grid   Step 7: Next Steps   Congratulations on completing the guide!   The next guide in the Customize UI and Display Options to Deploy Applications learning path is Define Your UI Style.    If you have questions, issues, or need additional information, refer to: Resource Link Experience ThingWorx Application Development Reference Community Developer Community Forum Support Button Widget Help Center Support Slider Widget Help Center Support Gauge Widget Help Center Support Advanced Grids (Themable) Help Center    

Background: The frequency with which an Agent checks its connection to the Axeda Cloud Server is called the Agent “ping rate” (also known as heartbeat). (For Axeda IDM Agents, ping rate is referred to as “poll rate”; the meaning is the same.) Pings are a very important aspect of Firewall-Friendly communication. All communication between the Agent and the Cloud Server is initiated by the Agent. In addition to indicating the Agent is still active, the Ping also gives the Cloud Server an opportunity to send commands back to the Agent on the Ping acknowledgement. The ping rate effectively defines how long users must wait before they can deliver a command or request to an Agent. Typical commands may include setting a data item, starting an Access Session, or running a script. The place where Ping rate is most noticeable to system users is when requesting a remote session. When a session request has been submitted by the user, the Cloud Server waits for the next Agent ping in order to send down the command to begin the session process. A longer ping rate means the remote session takes longer to get started. (Note that the same is true of any command initiated from the Axeda Cloud Server.) Ping traffic comprises the majority of inbound traffic to the Cloud Server. The higher the ping rate, the more resources are consumed on the Server and the greater the requirements for network bandwidth for the customer. Unnecessarily high ping rates will result in an increase in network traffic on your customer's network. By default, the ping rate for Firewall-Friendly Agents is 60 seconds, or every 1 minute. The Agent ping rate is set using Axeda Builder when configuring the project. The ping rate can also be set via an action from the Axeda Cloud Server. When set via an action, the new ping rate is in effect until the next Agent restart (at which time the Agent will go back to the default ping rate set in the project). The Axeda Cloud Server also uses Agent ping rate to determine when assets are missing. One of the model settings is to define how many missed pings (or missed pings and time) will cause a device to be marked as missing. The default setting for new models is to mark assets as missing after they’ve missed 3 consecutive pings. Recommendations: Make sure that your Agents’ ping rates are set to reasonable frequencies. The ping rate should be set based on use case and not necessarily volume. The recommended practice is to make sure the ping rate is never set less than 60 seconds. Where possible the ping rate should be set to 2 minutes or higher. In the end, it is often user expectations around starting Access sessions that drives the ping rate value. If only occasional user access is required, one recommendation is to dynamically adjust the ping rate when conditions require expedited communication with the Cloud Server. One use case is to expedite a remote session when a device is in alarm condition or when an end user needs assistance. In this case you would temporarily increase the ping rate. This can be done using an action from the Cloud Server, by downloading a software package ping rate update, or by Agent extension using the SDK. (For information about using the Agent SDK, see the Axeda® Platform Extending Axeda® Agents PDF.) You can configure alerts to indicate if an asset is missing. Axeda recommends that you configure the alert to a reasonable time given your resources and the expense of tracking every missing asset. A reasonable missing alert for your organization may be 1-2 days, meaning the Server generates the missing asset alert only after the asset has been missing for one or two days, based on its ping rate, and an asset should be marked as missing only after 15 missed pings or 30 minutes (whichever is less). The most common cause of a missing asset is not an issue with the device but rather the loss of Internet connectivity. Note: Any communication from an Agent also serves the function of a Ping. E.g., if the ping rate is set to 30 minutes and the device is sending a data value every 5 minutes, the effective Ping rate is 5 minutes. Need more information? For information about specifying Agent ping rate, see the online help in Axeda® Builder (Enterprise Server Settings). If setting the ping rate from Platform actions or verifying Agent ping rates, see the online help of the Axeda® Connected Management Applications.

Starting with the 7.4 version of Thingworx, a license.bin file locked to the specific version of Thingworx is required in order to successfully start the Thingworx webapp. If something is wrong with the licensing, Tomcat will crash and will not show any information regarding the problem in its log files. The Catalina*.log file will look like this 13-Jun-2017 04:36:43.268 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service Catalina 13-Jun-2017 04:36:43.268 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/8.5.13 13-Jun-2017 04:36:43.315 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\Thingworx.war 13-Jun-2017 04:36:56.080 INFO [localhost-startStop-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. instead of continuing on through the rest of the war files present on the server as it would if everything worked properly. 13-Jun-2017 04:37:20.001 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\Thingworx.war has finished in 36,684 ms 13-Jun-2017 04:37:20.006 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\docs 13-Jun-2017 04:37:20.113 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\docs has finished in 107 ms 13-Jun-2017 04:37:20.113 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\examples 13-Jun-2017 04:37:20.617 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\examples has finished in 504 ms 13-Jun-2017 04:37:20.618 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\host-manager 13-Jun-2017 04:37:20.661 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\host-manager has finished in 43 ms 13-Jun-2017 04:37:20.661 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\manager 13-Jun-2017 04:37:20.847 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\manager has finished in 186 ms 13-Jun-2017 04:37:20.847 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\ROOT 13-Jun-2017 04:37:20.866 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory C:\PTC\KinexForManufacturing\PTC_Servlet_Engine\webapps\ROOT has finished in 18 ms 13-Jun-2017 04:37:20.949 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["https-jsse-nio-443"] 13-Jun-2017 04:37:20.957 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-8009"] 13-Jun-2017 04:37:20.958 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 37733 ms The error will actually be in the ThingworxStorage/logs/ApplicationLog.log file - something like this: 2017-06-14 10:00:19.057-0700 [L: INFO] [O: c.t.s.ThingWorxServer] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] Subsystem LicensingSubsystem is starting 2017-06-14 10:00:19.057-0700 [L: INFO] [O: c.t.s.s.Subsystem] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] Starting Subsystem [LicensingSubsystem] 2017-06-14 10:00:19.088-0700 [L: ERROR] [O: c.t.s.s.l.LicensingSubsystem] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] ==================================================================== 2017-06-14 10:00:19.088-0700 [L: ERROR] [O: c.t.s.s.l.LicensingSubsystem] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] C:\PTC\KinexForManufacturing\ThingworxPlatform\license.bin: license file does not exist! 2017-06-14 10:00:19.088-0700 [L: ERROR] [O: c.t.s.s.l.LicensingSubsystem] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] ==================================================================== 2017-06-14 10:00:19.088-0700 [L: WARN] [O: c.t.s.ThingWorxServer] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] Shutting down the Platform. Get your license installed properly and the problem should go away.

  Whether your ThingWorx instances are deployed on premise, in the cloud or a hybrid of the two, I’d like you to imagine: You have a super cool app. You want to deploy it securely. You’re not a security expert. What do you do? How do you know how to securely deploy your app? Where do you go for security best practices? Introducing the new ThingWox Secure Deployment Hub!   The ThingWorx Secure Deployment Hub is a new section of our support site that will introduce you to the ThingWorx security landscape and direct you to security resources pertaining to the Edge, the platform and beyond.   From permissions and provisioning, to subsystems and SSO, the hub is packed with our recommendations and best practices for you to deploy your app in a secure fashion.   Happy deploying! Kaya

In this video we review the prequisite needed prior of installing ThingWorx analytics server 52.1   Updated Link for access to this video:  Installing ThingWorx Analytics Server: Part 1 - Prerequisites

Key Functional Highlights Add connectivity to National Instruments TestStand Make it easier to edit the apps Easier to find mashups and things in Composer Support for Asset sub-types Open up the tag picker to allow adding any connection types through Composer General App Improvements Enhance tag picker to improve speed of configuration Make it easier to add additional properties to assets Make app configuration more intuitive by centralizing the configuration Controls Advisor Merge the Server and Connection status fields Asset Advisor Performance improvement when displaying pages Add support for CFS/ServiceMax integration Added trial support for Service     Compatibility ThingWorx 8.2.x KEPServerEX 6.2 and later KEPServerEX V6.1 and older as well as different OPC Servers (with Kepware OPC aggregator) National Instruments TestStand 2016 SP1 and later Support upgrade from 8.0.1 and later     Documentation What’s New in ThingWorx Manufacturing Apps ThingWorx Manufacturing Apps Setup and Configuration Guide What’s New in ThingWorx Service Apps ThingWorx Service Apps Setup and Configuration Guide ThingWorx Manufacturing and Service Apps Customization Guide     Download ThingWorx Manufacturing Apps Freemium portal ThingWorx Manufacturing and Service Apps Extensions

In this video we show a simple mashup and services in order to display the ThingPredictor's real time scoring results. This video applies to ThingWorx Analytics 7.4 to 8.1   Updated Link for access to this video:  Showing ThingWorx Analytics Manager's results (ThingPredictor) in a Mashup

  The ThingWorx team would like to be one of the first to wish you a happy holiday season.   To kick it off, I’ll share the top three things we’re thankful for: Our customers—you! Thank you for all that you do. The entire team behind ThingWorx. Thank you for being such a fun team to work with! Our robust platform—recognized by Gartner as a leader in industrial IoT platforms. Launching today, 9.1 features a cornucopia of new functionality, including: Runtime support for AWS Corretto Open JDK 11, now available to help you save Oracle Java licensing costs A new Project View in Composer Pareto charts, auto refresh, pagination and chip-based data filter web components Enhancements to auditing, Thing Group UI & export to source control Asset Advisor scale improvements Operator Advisor process plan caching Azure AD integration with Solution Central to manage users ARM templates now available to allow you to easily deploy the necessary ThingWorx infrastructure on Azure Read the release notes and download 9.1 from the Software Downloads Page today!   Stay connected & happy holidays, Kaya      

1. Create a network and added all Entities that implement from a specific ThingShape in the network 2. Create a ThingShape mashup as below Note: Bind the Entity parameter to DynamicThingShapes_TracotrShape's service GetProperties input EntityName. Laso bind mashup RefreshRequested event to that service 3. Create a mashup named ContentShape, add Tree widget and ContainedMashp in it 4. Bind Service GetNetworkConnection's Selected Row(s) result and Selected RowsChanged event to ContainedMashup widget Note: Master can total replace ThingShape mashup. Suggest to use Master after ThingWorx 6.0

Video Author:                     Christophe Morfin Original Post Date:            September 13, 2016 Applicable Releases:        ThingWorx Analytics 52.1 to 8.1 ​ Description: A short introduction to ThingWorx Analytics Builder The import of the ThingWorx Analytics Builder Extension  

  Use the ThingWorx Azure IoT Hub Connector with simulated appliances.   Guide Concept   This project will introduce how to integrate ThingWorx with Azure IoT Hub. The combination of these two platforms extends the ThingWorx utilities to Azure IoT Hub edge devices and allows integration with Azure Blob Storage accounts.   Following the steps in this guide, you will install the ThingWorx Azure IoT Hub Connector and run a simulated Azure device.   We will teach you how to build powerful and scalable IoT applications by integrating ThingWorx and Azure IoT Hub.   You'll learn how to   Install, configure, and run the ThingWorx Azure IoT Hub Connector Import devices that exist in Azure into ThingWorx Connect a simulated Azure device to ThingWorx Foundation server   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 60 minutes       Step 1: Overview Diagram   The ThingWorx Azure IoT Hub Connector maintains a network connection to both an Azure IoT and a ThingWorx Foundation instance:        The ThingWorx Azure IoT Hub Connector enables remote devices that connect to the Azure IoT Hub, to connect to the ThingWorx Foundation server. The Azure IoT Connector handles message routing for the devices that communicate through the Azure IoT system. It also handles message routing from the ThingWorx Foundation server to devices via the Azure IoT Hub.   The ThingWorx Azure IoT Connector is a separate, stand-alone application that must be run on a server that can connect to both the ThingWorx server and the Azure IoT service.     Step 2: Configure Azure IoT Hub   In order to use the ThingWorx Azure IoT Connector, you must first configure an IoT Hub and a storage account in Microsoft Azure. You can provision a free tier account for these resources. In this step, we will create the Azure resources and gather the configuration information that enable you to connect to ThingWorx with the required credentials.   Log into Azure Portal   If you do not already have an Azure account you can create a free account that will work with this guide.   Create Azure IoT Hub   Follow the Microsoft documentation to create an Azure IoT Hub, accepting any defaults.   TIP: The name your IoT Hub must be globally unique and include only lowercase letters and numbers.   1. Create message routes to direct DeviceLifecycleEvents and TwinChangeEvents events to the built-in events endpoint. For a tutorial, refer to Tutorial: Use the Azure CLI and Azure portal to configure IoT Hub message routing 2. Register at least one Azure IoT Device or Azure IoT Edge Device to your Azure IoT Hub. For a tutorial, refer to Register an IoT Edge device in IoT Hub     Create Storage Account   Follow the Microsoft documentation to create an Azure Storage account.   NOTE: Select Blob storage as the account type and the Hot Access Tier.       Step 3: Import Extensions   The ThingWorx Azure IoT Hub Connector distribution bundle comes packaged with all the software you will need to connect ThingWorx and Azure. Download the Azure IoT Hub Connector from PTC Support Extract the application bundle to a directory on the system where it will run. (where v.v.v represents the release number) On Linux, this guide uses the base directory, /opt. The subdirectories and files should reside in the directory, /opt/ThingWorx-Azure-IoTHub-Connector-4.2.0. On Windows, extract the bundle so that the subdirectories and files reside in C:\ThingWorx-Azure-IoT-Hub-Connector-4.2.0 In the lower-left side of Composer, click Import/Export, then Import.  In the Import From File pop-up, under Import Option select Extension from the drop-down, then click Browse. Navigate to the /extensions directory and click on ConnectionServicesExtension-2.2.4.zip file.   Click Import in the Import From File pop-up, then click Close after file is successfully imported. Repeat the above steps for the azure-iot-hub-adapter-extension-4.2.0.4.zip file. Follow the steps to Create an Application Key and note the value, it will be used in the the next step.     Step 4: Install Azure Connector   Configure Connection Server   The Connection Server component of ThingWorx Azure IoT Connector must be configured with information specific to both your Azure IoT Hub and your ThingWorx Foundation server.   Copy the file azure-iot-sample.conf in the connector > conf directory and save the file with the name azure-iot.conf Edit the configuration file to replace the ten placeholder values for the parameters listed below with values copied from your Azure control panel. consumerPolicyName - Whether you have a new or existing hub, you need to provide the name of the consumer policy and its related Primary or Secondary key. The policy to select is typically the built-in, pre-defined policy called service. Navigate to All Resources > your hub > Settings > Shared access policies > service. If you added a custom service policy to your hub with the permission service connect select that policy.   consumerPolicyKey - Once you find the policy name, stay in the Shared access policies screen, and click the name. Copy the content of the Primary key. This key supplies the credentials to access services that are specified in the related policy. registryPolicyName - Specify a policy name that is related to the registryPolicyKey. This policy is typically a built in, predefined policy called registryReadWrite, but it is possible to use a custom policy if you add it to your hub. The shared access policy requires the registry read and registry write permissions. registryPolicyKey - The key that supplies credentials to access services in the policy specified in registryPolicyName. hubName - A name that defines the Azure IoT Hub related to this ThingWorx Connector. This Azure IoT Hub manages your things and their related messages. Hubs can be scaled via hub units at different price tiers per unit. Hubs are related to a resource group, which is related to a subscription Id and a cloud Location. TIP: To find the name associated with your Azure IoT Hub that the ThingWorx Connector will use to communicate with it, navigate to All Resources > your hub > Settings > Properties > NAME eventHubName - The Event Hub-compatible name that is used by SDKs and integrations that expect to read from Event Hubs. An Event Hub is an internal component of an Azure IoT Hub that handles device-to-cloud events for related things. In many cases, the IoT Hub name and Event Hubcompatible name are the same, so this property defaults to the Azure IoT Hub name (hubName). Navigate to All Resources > your hub > Settings > Built-in endpoints > Events > Event Hub-compatible name to find this name.   eventHubNamespace - To find the endpoint that is used by SDKs and integrations that expect to read from Event Hubs, navigate to All resources > your hub > Settings > Built-in endpoints > Events > Event Hub-compatible endpoint, and copy the host name, without the rest of the address (".servicebus.windows.net"). The ThingWorx Azure IoT Connector uses this endpoint to read messages from your hub. consumerGroup - To find a consumer group name to enable the Connector to pull data from the Azure IoT Hub, navigate to All Resources > your hub > Messaging > Endpoints > Built-in endpoints > Events > Consumer groups. To use the $Default consumer group, set this property to null. hubHostname - To find the host name for your hub, navigate to All Resources > your hub > Overview > Hostname. The host name is defined by the hubName plus a domain name that is chosen by Azure, typically azuredevices.net.   blob-storage.account-name - The blob-storage section specifies the settings for an Azure blob storage account. The storage provides containers that are used for device export of an Azure IoT Hub to ThingWorx via the Connector and can also be created by the Connector if you create AzureStorageContainerFileRepository things in ThingWorx. If you do not have one, create a Storage Account in the Azure portal. To find the name of an existing account, navigate to Settings > Access Keys > Storage account name.   blob-storage.account-key - The key to associate with the name of the blob storage account. To find the key for an existing account, navigate to Settings > Access Keys > Primary or secondary key Enter your ThingWorx Foundation server host, port, and appKey  in the transport.websockets section. transport.websockets { app-key = "6d70dfca-fe88-4d8c-83aa-686449b52cb2" platforms = "ws://45.23.12.112:80/Thingworx/WS" }   NOTE: If you are using an SSL connection to your ThingWorx Foundation server use wss in place of ws in the platform parameter. If the URL for the ThingWorx Foundation server does not include a port, use 80 for http connections and 443 for https.       Step 5: Launch IoT Hub Connector   Open a shell or a command prompt window. On a Windows machine, open the command prompt as Administrator. The AZURE_IOT_OPTS environment variable must be set before starting the Azure IoT Hub Connector. Below are sample commands using the default installation directory. On Windows: set AZURE_IOT_OPTS=-Dconfig.file=C:\ThingWorx-Azure-IoT-Connector-<version>\azure-iot-<version>-application\conf\azure-iot.conf -Dlogback.configurationFile=C:\ThingWorx-Azure-IoT-Connector-<version>\azure-iot-<version>-application\conf\logback.xml On Linux: export AZURE_IOT_OPTS="-Dconfig.file=/var/opt/ThingWorx-Azure-IoT-Connector-<version>/azure-iot-<version>-application/conf/azure-iot.conf -Dlogback.configurationFile=/var/opt/ThingWorx-Azure-IoT-Connector-<version>/azure-iot-<version>-application/conf/logback.xml" NOTE: You must run the export command each time you open a shell or command prompt window. Change directories to the bin subdirectory of the Azure IoT Hub Connector installation. Start the Azure IoT Hub Connector with the appropriate command for your operating system. On Windows: azure-iot.bat On Linux: /azureiot NOTE: On Windows you may have to shorten the installation directory name or move the bin directory closer to the root directory of your system to prevent exceeding the Windows limit on the classpath length.   The Connection Server should start with no errors or stack traces displayed. If the program ends, check the following: Java version is 1.8.0, update 92 or greater and is Java(TM) not OpenJDK. Open azure-iot.conf and confirm ThingWorx Foundation is set to the correct URL and port. Confirm the platform scheme is ws if http is used to access ThingWorx. Confirm all Azure credentials are correct for your Azure account. In ThingWorx Foundation click the Monitoring tab then click Connection Servers. You should see a server named azure-iot-cxserver-{server-uuid}, where {server-uuid} is a unique identifier that is assigned automatically to the server.       Step 6: Import Device from Azure   With the ThingWorx Azure IoT Connector, you can import into ThingWorx any existing devices that are currently provisioned to the Azure IoT Hub.   Add Device Azure IoT Hub   If you have not provisioned any devices to your Azure IoT Hub you can learn more about Azure IoT Hub device identity before following the steps below to create a test device.   In your Azure Portal, click All Resources, then select the name of your IoT Hub. Under Explorers click IoT devices, then click + Add. Enter a name for your device, then click Save. When the device name appears in the list it is ready to use.   Import Device into ThingWorx   We will manually execute a service in ThingWorx that will import Azure IoT Hub devices into ThingWorx.   In ThingWorx Composer, navigate to the ConnectionServicesHub Thing. Click Services tab and scroll to the ImportAzureIotDevices service and click the execute Arrow. NOTE: The * in the pattern field will act as a wildcard and import all devices, you can enter a string to match that will only import a subset of all available devices. Click Execute to import the devices then click Done. Click Things in the left column to see the Things that were created.   Click here to view Part 2 of this guide.

To simplify the development of IIoT applications and solutions on the ThingWorx platform, we introduce the concept of Building Blocks. The intent of Building Blocks is to ease the creation of your own solutions and customization of PTC’s solutions. These Building Blocks are domain specific business logic pre-made for reusability, which means you won’t need to build from scratch on ThingWorx and can accelerate your time to value. What do we mean by Building Blocks? Building Blocks are premade components that enable modular software development. They are reusable, replaceable packages of functionality that can be connected into an architecture framework. Building Blocks allow for quicker development and customization of solutions and applications. What are the different types of Building Blocks?   Connectors  Leverage the same connectors we use for PTC solutions for better overall application performance and seamless transfer of data from disparate devices and systems. Identify the devices and systems you would like to monitor and let the connector do the rest.   Domain Models  Incorporate behavior and data from your devices and systems into a conceptual model of the domain, which is prepackaged based on common use cases. You can also leverage our out of the box models to connect and build dependencies between domains.   Business Logic  Encode real-world business rules that determine how data can be created, stored, and changed. Create KPIs for your devices and systems with these rules and create alerts based on your unique parameters.   UI  Construct widgets to view or analyze key data points in a graphical user interface that you can customize and leverage to extend functionality. Created with manufacturing and service use cases in mind, UI are predesigned to make it easy to view and understand data.   Building Blocks build upon the ThingWorx platform and are the base of all of PTC’s current and future solutions. We will continue to discuss Building Blocks in future posts, but in the meantime: How will you leverage building blocks in your own solutions? Is there more you want to know?   Stay connected, Rachel  

This blog is about Decision tree and it is aimed at providing the Analytics user with additional information about our default algorithm; Decision tree. More specifically we will clarify what structures builds the Decision tree, understand the purpose of these structures, and last we will look at a few examples of pros and cons of applying Decision tree. Decision tree is a great tool to help us making good decisions based on a huge amount of data. The algorithm maps information provided from the dataset and constructs a tree to predict our goal. ​ Classification and regression trees are the structures behind Decision tree  – Therefore when we refer to Decision tree we collectively include classification and regression as being part of Decision tree. But what is the difference between Classification and regression? 1) Classification can be used for predicting dependent categorical variables. For example if needed to predict what type of failure occurs with a machine, or what type of car a person would buy it would be a classification tree. 2) Regression is used for dependent continues numerical variables. For example if you want to predict the amount of sugar in a person’s blood or you need to predict the price of oil per gallon in 2020, regression is uses for the prediction. Regression is addressing predictions, where the value can be continues valued, and classification tree predict the correct label/type for the class. Example of a classification tree: Keep in mind that it is the goal variable that determines the type of decision tree needed. Using Decision tree is a powerful tool for prediction: Easy to understand and interpret. Help us to make the best decisions on the basis of existing information. Can handle missing values without needing to resort. Considerations: As with all analytics models, there are also limitations of the decision tree. Users must be aware of, Decision trees can be subject to overfitting and underfitting, particularly when using a small dataset. High correlation between different variables may cause very high model accuracy.

  Meet Anthony. Anthony came to PTC from a large industrial company as a user of Axeda, a leading device connectivity company that PTC acquired in 2014. With a background in aerospace engineering and experience in a variety of industries including life safety, healthcare, nuclear power, and oil and gas, Anthony has been working to create new value around innovation for customers transitioning to ThingWorx. When he’s not working on IIoT, he’s playing music on Cape Cod, photographing Hawaiian landscapes or bringing awesome inflatable chairs into the office.    You may recall from last week's post that Thing Presence is one of the top three features in 8.4 that you might not know about. This week, I spoke with Anthony for a deeper dive on Thing Presence. Check out how it went.   Kaya: What was the challenge users were facing that led us to create Thing Presence? Anthony: Axeda customers transitioning to ThingWorx were struggling with the connectivity use case and kept asking, ‘why is my asset always offline?’ When we evaluated it, we discovered that it was tied to the difference between AlwaysOn and Axeda eMessage protocol architectures. IsConnected will always report false for polling and duty cycle devices.   The use case of Thing Presence is to know that the asset is reporting into the network and is ready to provide information (push) or be accessed to retrieve information or do a remote desktop support (pull). This use case is relevant for any asset in ThingWorx that uses duty cycle.   In ThingWorx 8.4 (coming in early 2019), the new IsReporting state will inform the user when a polling device is communicating on a regular basis. If it is, then IsReporting will be true. The IsReporting state resolves the discrepancy wherein devices that are on duty cycle appear disconnected due to the IsConnected state reporting false.  New "IsReporting" state improves visibility of an asset's communication state Kaya: How exactly does Thing Presence work? Anthony: You can think of it in terms of having teenagers. You tell them they need to check in with you on a regular basis through text message. If a text is missed, all of a sudden you take action.   Now, imagine the teenager is a device. If a device was supposed to check in every five minutes and it misses one poll, I want to flag that as a problem. The challenge with that from a service perspective is that sometimes your service personnel will go out and work on a device and may need to take it offline for a bit of time; we need to factor that in. We certainly don’t want to deploy someone or try to fix something when a service technician is already there.   You might decide, ‘my average service visit is an hour, so, if I miss a couple of pings, I’m okay; but, if I’m offline for more than an hour, then I’d like to know about it because I’d like to take action.’ Thing Presence allows you to define that window.   Kaya: You’ve mentioned ‘duty cycle’ and ‘polling cycle.’ Can you explain these terms? Anthony: Duty cycle and polling cycle are the same thing. It means that a device has a time for which it is expected to check in, and, provided that it checks in within that timeframe, all is good with the connection.   Connected services rely on a connection. As soon as the connection is broken, I no longer have the ability to service the asset.   Kaya: Given everything we’ve discussed, where do you see Thing Presence headed? Anthony: The next piece of the equation for us is to provide information on the health of the connection. When you look at servicing a remote asset, you need to a) know that it is communicating, and b) know that the connection is healthy before you try anything. I wouldn’t want to try a software update if I am losing connection with my asset on a regular basis.   What do we mean by health? We mean: is the device checking in when it should be? If it’s not, is there a pattern to that connection, and are those patterns tied to applications? For example, is it only on during working hours? Does it turn off during holidays? If the device is in a school, does it turn off during summer maintenance work? This allows us to garner insights on how and when the equipment is being used, not just operating status. At the end of the day, does this mean I can apply analytics and AI tools to it? Absolutely. Is it the first place I would apply it? Probably not.   Kaya: In your mind, what is the next big thing coming in ThingWorx that you’re particularly excited about? Anthony: Mashup 2.0 and Asset Advisor 8.4. (Double mic drop.)   Kaya: That’s awesome. My last question is related to you. Can you tell me what your favorite aspect is about working at PTC? Anthony: The chaos. Very often it’s chaos that breeds innovation. What I mean by that is that, if you try to create something because you sit down and you say, ‘I am going to innovate,’ very often that is a failure because the majority of the time it’s the influence of a deadline, a customer need or an application at hand that makes the environment trying and sometimes hectic. But, it is in these challenging environments where you can be the most creative and innovative as an engineer.

I’m excited to introduce you to a brand new training pathway called the ThingWorx IoT Developer Specialization. This specialization leverages over 40+ hours of training from our online learning platform, IoT University. Through a series of four online courses and an interactive capstone project, you’ll learn how to: Use the ThingWorx development process to build IoT applications from the ground up Build complex models and implement them in ThingWorx Design user-centric application interfaces in ThingWorx that leverage UI/UX and data visualization best practices Connect edge devices to ThingWorx and acquire the data you need for your application Once you complete all the courses, you’ll advance to the capstone project where you’ll put your knowledge into action by building an IoT solution. And to set you up for success, you’ll receive 1-on-1 feedback on your project from a dedicated industry mentor.   Learn more about the specialization by clicking here. To request access to the specialization, visit our Enterprise Training page.

When installing KEPServerEX, you will be presented with a tree of features to install. Open the pull-down menu next to "Full install" and select "Entire feature will be installed on local hard drive." This will ensure all needed drivers and plug-ins are included. When either a Client application has made a request of a Driver, or a Plug-in becomes activated, then a license check is performed. If a feature is not licensed, a two-hour demo countdown period will begin. For more information on this, see: KEPServerEX V6 Demo Timer

Configure and connect industrial devices and systems in any environment.   NOTE: Complete the following guides in sequential order. The estimated time to complete this learning path is 180 minutes.   1. Configure Permissions  Part 1 Part 2 2. Choose a Connectivity Method 3. Use REST API to Access ThingWorx  Part 1 Part 2 Part 3 Part 4 4. Java SDK Tutorial  Part 1 Part 2 Part 3 Part 4 Part 5 5. C SDK Tutorial  Part 1 Part 2 Part 3 Part 4

ThingWorx Manufacturing Apps Setup and Configuration Guide 8.1.0 ThingWorx Manufacturing Apps Customization Guide  8.1.0

When an Expression Rule of type Alarm, AlarmExtendedDataChange, AlarmSeverityChange or AlarmStateChange calls a Groovy script, the script is provided with the implicit object alarm.  This example shows how the alarm object can be used. This Expression Rule uses the CountAlarmsSinceHours Groovy script to check the number of alarms in the past number of hours, and escalate the alarm if more than three alarms have occurred: IF    ExecuteCustomObject("CountAlarmsSinceHours", 1) < 3 THEN SetAlarmState("ACKNOWLEDGED", "Less than three alarms in the past hour") ELSE  SetAlarmState("ESCALATED", "THREE OR MORE alarms in the past hour") Here is the definition of the CountAlarmsSinceHours Groovy script.  The script uses the parameter 'hours' passed from the expression rule and the implicit object 'alarm'.  It returns the number of times the current alarm has occurred within 'hours' hours. import com.axeda.drm.sdk.Context import com.axeda.drm.sdk.data.HistoricalAlarmFinder import java.util.Calendar import com.axeda.common.sdk.jdbc.DateQuery // get Date object for an hour ago Calendar cal = Calendar.getInstance() cal.add(Calendar.HOUR, -parameters.hours.toInteger()) Date sinceTime = cal.getTime() HistoricalAlarmFinder findAlarms = new HistoricalAlarmFinder (Context.create()) findAlarms.device = alarm.device findAlarms.setAlarmName(alarm.name) findAlarms.date = DateQuery.after(sinceTime) List matchingAlarms = findAlarms.findAll()