IoT & Connectivity Tips

    Step 4: Implement New Features   The SMT Assembly Line Data Model was built around a sample manufacturing facility that tracks critical data points, including diagnostic information for:   motherboards assembly machines assembly line performance   To make informed decisions based on the diagnostic and performance data, you can add features that will increase analytics capabilities.   In this optional step, we'll add a Line Chart to see the performance of any given assembly machine. Once completed, we can create Services that will be used to make calculations on the data we have generated from the assembly line.   For a final challenge, you can create a service that will compare data points to identify what works best in an assembly machine, a larger internal queue, or more placement heads.   Setup New Mashup   Create a Mashup that is Responsive and name it SMTTimeSeriesMashup. Click the Layout tab and add a column to the canvas. Drag and drop a List Widget onto the left column of the layout. Drag-and-drop a Line Chart Widget onto the other column of the layout.   Configure List Widget   Add the GetImplementingThingsWithData Service of the AssemblyMachineTemplate Thing Template as a data source in the Mashup. Ensure the checkbox for Execute on Load is checked. Drag-and-drop GetImplementingThingsWithData > Returned Data > All Data to the List Widget. On the Select Binding Target pop-up, select Data.   With the List widget selected, for the DisplayField property dropdown, select name. In the ValueField property dropdown, select name.   Configure Time Series Data Add the Dynamic QueryPropertyHistory Service of the AssemblyMachineTemplate Thing Template as a data source in the Mashup. Ensure the checkbox for Execute on Load is checked. Drag-and-drop QueryPropertyHistory > Returned Data > All Data to the Time Series Chart Widget. On the Select Binding Target pop-up, select Data. For the XAxisField property dropdown, select timestamp. For the DataField1 property dropdown, select IdleTime OR MotherboardsCompleted.   Connect Widgets   Drag-and-drop the GetImplementingThingsWithData > Returned Data > Selected Row(s) > name property to the EntityName parameter for the Dynamic AssemblyMachineTemplate data source. Select the GetImplementingThingsWithData service, then drag-and-drop the SelectedRowChanged event onto QueryPropertyHistory.   Click Save. After the save is complete, click View Mashup.   You are now able to see what the idle time is for each assemble machine over the span of its use.   Create Service   You can add JavaScript code to calculate the average completion time for the motherboard assembly.   Open the MotherboardTemplate ThingTemplate in Composer. Create a new Service titled CompletionTime. For the Output type, select Number. Enter the following code into the JavaScript window and save: var diff = 1; if(me.EndTime != null && me.StartTime != null){ diff = Math.abs(me.EndTime - me.StartTime); } //Seconds var result = Math.round(diff/1000); //Minutes //var result = Math.round((diff/1000)/60);   You can now calculate the time it takes for an individual motherboard to be completed. Create a service to be used with the GetCompletedMotherboards service (returns a list of all completed Raspberry Pi motherboards) with the SMTAssemblyLineTemplate ThingTemplate to calculate the average time for your assembly line to complete a motherboard. Finish this Service and add configure it to work with your new Mashup.       Step 5: Next Steps   Congratulations! You've successfully completed the ThingWorx Monitor an SMT Assembly Line Guide, learning how to use ThingWorx to create an application that provides real-time insight into connected assets.   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 Connect Java SDK Tutorial   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

    Step 7: Access Data   Now that we have a basic display in-place, we need to access the backend data.   To do so, we'll make use of built-in Mashup Data Services.   At the top-right, ensure that the Data tab is selected.   Click the green + button.   In the Entities Filter field of the Add Data Pop-up, search for and select MDSD_Thing. In the Services Filter field, type getprop. Click the arrow beside GetProperties. Note that the GetProperties() Service has been added to the right section. Check the Execute on Load checkbox.   At the bottom-right of the pop-up, click Done. Note how the GetProperties() Mashup Data Service has been added to the top-right under the Data tab.   Bind Info Table Property   Now that we have access to the Data Service within the Mashup, we'll use it to pull backend data into the Mashup (specifically, the aggregated Info Table Property), and then bind it to the Grid Widget.   Expand the GetProperties Service.   Drag-and-drop MDSD_InfoTable_Property onto the Grid Advanced Widget.   On the Select Binding Target Pop-up, select Data.   Note how the bottom-center Connections Window indicates that the aggregated Info Table Property is now bound to the grid.   Access the Aggregation Service   Because we selected the Execute on Load option for GetProperties(), the Service will grab the information from the aggregated Info Table Property and propagate that into the Grid Advanced Widget on initially opening the Mashup in a web browser.   However, we currently have no way to call our custom aggregation Service besides diving into the backend as we did when we first created it and performed testing.   Instead, we want the Mashup itself to have the ability to call the aggregation Service.   We'll do so via the Button Widget's Clicked Event, but we first need to gain access to our custom Service in the Mashup.   In the top-right Data tab beside Things_MDSD_Thing, click the green </> button. Note that the Add Data Pop-up opens with the MDSD_Thing pre-selected.   On the left of the Add Data Pop-up, expand Select Service Category, and choose **Uncategorized**. Note our custom MDSD_Aggregation_Service.   Beside MDSD_Aggregation_Service, click the right arrow to add it to the Selected Services section. Note that we do NOT want to check "Execute on Load", because don't want the Service called upon initially opening the Mashup in a web browser.   At the bottom-right, click Done. Note the MDSD_Aggregation_Service has been added to the far-right Data tab.   Bind Button to Aggregation Service   Now that we can reference the aggregation Service in the Mashup, we'll bind it to pressing the Button Widget.   Click the Button Widget to select it.   Click the top-left of the Button Widget to reveal the Drop Down Menu.   Drag-and-drop the Clicked Event onto the MDSD_Aggregation_Service under the Data Tab.   On the bottom-right, with the MDSD_Aggregation_Service selected, drag-and-drop the MDSD_Aggregation_Service's ServiceInvokeCompleted Event onto GetProperties in the Data Tab. This causes the completion of the aggregation Service to re-call GetProperties, which updates the grid; as such, a new entry into the Info Table Property created by the custom Service will immediately show up in the Grid Widget. In the top-right, click the GetProperties Service to see all of its interactions in the bottom-center Connections window.   At the top, click Save.       Step 8: Test Application   Our MVP MRI Service Application is now complete.   Let's test it.   At the top, click View Mashup. Note the pre-existing single entry from our Service test which we executed directly from the backend.   Click Retrieve MRI Statistics.   Wait a moment and click Retrieve MRI Statistics again. Note that each click adds another entry to the Grid Widget.   Each time that you press the Button Widget, what you're really doing is calling our custom aggregation Service in the Foundation backend.   This Service then goes out and pulls in information from our various EMS-connected Edge sub-systems.   To add additional sub-systems (maybe a "friction" detection on the patient-bed indicating that it needs additional grease) all you would have to do is repeat the steps in this Learning Path, i.e. connect the additional sub-system with the EMS, add another Field Definition to the Data Shape, and modify the aggregation Service to retrieve that info and store it in the Info Table Property.   In addition, you may wish to improve the GUI. Rather than using a Positioning: Static Mashup, you could utilize a Responsive setup, sub-divide the Canvas into various sections, and then add items such as your company's logo. This would also make the GUI more friendly to different screen resolutions.   You can even add business logic to the Mashup itself. For instance, the Auto Refresh Widget (Legacy) can effectively be used as a "timer". In the same way that the Button Widget's Clicked Event calls the aggregation Service, the Auto Refresh Widget could be used to trigger the Service call at a set interval. Then, as long as the Mashup was open, the Button Widget would only be needed when you wanted an immediate status update.   For more information on implementing additional business logic, refer to the Create Custom Business Logic guide.   Or the Time Selector Widget could be used to restrict the information in the Grid Widget to only the timeframe you wanted to investigate.       Step 9: Next Steps   Congratulations! You've successfully completed the Medical Data Storage and Display guide, and learned how to:   Create a Data Shape and Info Table Property to store Medical Data Create a Service to combine data from multiple Edge devices into a single, logical Thing Create a Mashup to view and retrieve Medical data   This is the last guide in the Medical Device Service learning path.   Learn More   We recommend the following resources to continue your learning experience:    Capability     Guide Build Methods for Data Storage 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 ThingWorx Help Center  

    Step 3: Create A Tree Grid   With our MyFunctionsMashup Mashup open, let's add a Validation. A Validation is similar to an Expression, except you have the added capability of triggering Events based on a True or False outcome of your validation. We will use the Validation to check and confirm the Text Field we created only has the values we added in our Functions. Let's also add two Status Message Functions that will show whether or not a user has added any text outside of what we want.   Open the MyFunctionsMashup Mashup to the Design tab. Click the green + button in the Functions area.    In the New Function modal, select Validator.     Set the Name to isDataClean.     Click Next.  Click Add Parameter. Set the Name to text and ensure the Base Type is STRING.     Add the following code to the Expression are: if(text === "NO") { result = true; } else if(text === "YES") { result = true; } else { let array = text.split("YES").join(""); array = array.split(",").join(""); let count = array.trim().length; if(count) { result = false; } else { result = true; } }   9. Click Done.   We have our Validator in place, now we need our two Status Message Functions. Why two? You can setup one Status Message to perform the task, but for this case, we're keeping things simple.   Click the + button in the Functions area. Select Status Message in the dropdown.    Set the Name to GoodInputProvided.   Click Next. Ensure Message Type is Info. In the Message field, enter Text is all good!.   Click Done. Let's create another Status Message Function. Set the Name to BadnputProvided.   Click Next. Change Message Type to Error. In the Message field, enter Text is BAD!.   Click Done.   We now have two Status Message Functions and a Validator to help with checking our text data. Let's connect everything together. This time, let's use the Bind button.   Expand the Validator section in the Functions tab. Click the Bind (arrows) button on the isDataClean Validator. This window will help us configure connections a bit easier.    Click the down arrow by the True Event. Click Add Trigger Service.   Click Functions. Check the checkbox by GoodInputProvided.   Click Next. Click the down arrow by the False Event. Click Add Trigger Service.   Click Functions. Check the checkbox by BadInputProvided.   Click Next. You should currently have the following setup:    Let's add in our connections to the Text Field and when we'll run this Validation.    Click the down arrow by the text Property.   Click Add Source. With the Widgets tab selected, scroll down and select the Text Property of our Text Field.   Click Next. Click the down arrow by Evaluate Service. Select Add Event Trigger.   With the Widgets tab selected, scroll down and select the Clicked Property of our Button.   Click Next. You should currently have the following setup:   Click Done. Click Save and view your updated Mashup.   Your Validator is complete. You now have a way to tell when a user has inputed their own text into the text box. To try things out, add some crazy characters, hit the button, and see what happens. You might notice that you have your Expressions running at the same time as your Validator. Switch up the bindings to get it to run the way you want it to.     Step 4: Next Steps   Congratulations! You've successfully completed the Explore UI Functions guide, and learned best practices for building a complex Mashup that navigations, multiple data inputs, confirmations, and all working together effectively for an enhanced user experience.   Learn More   We recommend the following resources to continue your learning experience:    Capability     Guide Experience Object-Oriented UI Design Tips   Additional Resources   If you have questions, issues, or need additional information, refer to:    Resource       Link Community Developer Community Forum Support Mashup Builder Support Help Center

U Term Definition user An account that can be used to access ThingWorx (design time and/or run time). user group A collection of users to provide a common level of security-access. Allows you to categorize users of the ThingWorx system. User groups can contain users and groups. All permission settings and overrides are cumulative. The ThingWorx default security policy is restrictive. When you create a new group or user, the account will not have any rights in ThingWorx until you assign them. user management subsystem Subsystem that manages session and password hash settings. See Subsystem.   V Term Definition value stream processing subsystem Subsystem that manages value stream storage and retrieval. See Subsystem. value stream A storage table for time-series information about a Thing's property values. Querying a Value Stream returns the value of the specified property. virtual Thing A modeled Thing defined in Edge that is represented as a remote Thing in the ThingWorx Platform. visibility A simple form of access control. If an entity is visible to members of an organizational unit, those members have access to the entity, and the underlying granular security model determines what interaction members of that organization unit have with a specific asset. Visibility can be set at the collection level, the individual entity level, or at the visibility level of the Thing Template instance. vocabulary A collection of terms used to create tags.   W Term Definition WebSocket-based Edge MicroServer (WS EMS) Allows edge devices or data stores to connect to the ThingWorx Platform through the internet or a firewall using the AlwaysOn™ binary protocol. WebSocket communications subsystem Subsystem that handles core WebSocket communications. See Subsystem. WebSocket execution processing subsystem Subsystem that handles WebSocket execution processing. See Subsystem. widget The components placed on a Mashup such as grids, charts, text boxes, buttons, and navigation links. Anything that is visible or clickable is a widget. wiki A type of Widget that mimics the functionality of a 'collaborative website', and allows collaborative editing of its content and structure by its users. Wikis may have posts added by both human users and the system itself.

  Step 6: Data Shapes   Data Shapes are an important part of creating/firing Events and also invoking Services   Define With Macros   In order to define a Data Shape using a macro, use TW_MAKE_DATASHAPE.   NOTE: The macros are all defined in the twMacros.h header file.   TW_MAKE_DATASHAPE("SteamSensorReadingShape", TW_DS_ENTRY("ActivationTime", TW_NO_DESCRIPTION ,TW_DATETIME), TW_DS_ENTRY("SensorName", TW_NO_DESCRIPTION ,TW_NUMBER), TW_DS_ENTRY("Temperature", TW_NO_DESCRIPTION ,TW_NUMBER), TW_DS_ENTRY("Pressure", TW_NO_DESCRIPTION ,TW_NUMBER), TW_DS_ENTRY("FaultStatus", TW_NO_DESCRIPTION ,TW_BOOLEAN), TW_DS_ENTRY("InletValve", TW_NO_DESCRIPTION ,TW_BOOLEAN), TW_DS_ENTRY("TemperatureLimit", TW_NO_DESCRIPTION ,TW_NUMBER), TW_DS_ENTRY("TotalFlow", TW_NO_DESCRIPTION ,TW_INTEGER) );   Define Without Macros   In order to define a Data Shape without using a macro, use the  twDataShape_CreateFromEntries  function. In the example below, we are creating a Data Shape called SteamSensorReadings that has two numbers as Field Definitions.   twDataShape * ds = twDataShape_Create(twDataShapeEntry_Create("a",NULL,TW_NUMBER)); twDataShape_AddEntry(ds, twDataShapeEntry_Create("b",NULL,TW_NUMBER)); /* Name the DataShape for the SteamSensorReadings service output */ twDataShape_SetName(ds, "SteamSensorReadings");     Step 7: Events and Services   Events and Services provide useful functionality. Events are a good way to make a Service be asynchronous. You can call a Service, let it return, 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.   Fire Events   To fire an Event you first need to register the Event and load it with the necessary fields for the Data Shape of that Event using the twApi_RegisterEvent function. Afterwards, you would send a request to the ThingWorx server with the collected values using the twApi_FireEvent function. An example is as follows:   twDataShape * ds = twDataShape_Create(twDataShapeEntry_Create("message", NULL,TW_STRING)); /* Event datashapes require a name */ twDataShape_SetName(ds, "SteamSensorFault"); /* Register the service */ twApi_RegisterEvent(TW_THING, thingName, "SteamSensorFault", "Steam sensor event", ds); …. struct { char FaultStatus; double Temperature; double TemperatureLimit; } properties; …. properties. TemperatureLimit = rand() + RAND_MAX/5.0; properties.Temperature = rand() + RAND_MAX/5.0; properties.FaultStatus = FALSE; if (properties.Temperature > properties.TemperatureLimit && properties.FaultStatus == FALSE) { twInfoTable * faultData = 0; char msg[140]; properties.FaultStatus = 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); }   Invoke Services   In order to invoke a Service, you will use the twApi_InvokeService function. The full documentation for this function can be found in [C SDK HOME DIR]/src/api/twApi.h. Refer to the table below for additional information.   Parameter Type Description entityType Input The type of Entity that the service belongs to. Enumeration values can be found in twDefinitions.h. entityName Input The name of the Entity that the service belongs to. serviceName Input The name of the Service to execute. params Input A pointer to an Info Table containing the parameters to be passed into the Service. The calling function will retain ownership of this pointer and is responsible for cleaning up the memory after the call is complete. result Input/Output A pointer to a twInfoTable pointer. In a successful request, this parameter will end up with a valid pointer to a twInfoTable that is the result of the Service invocation. The caller is responsible for deleting the returned primitive using twInfoTable_Delete. It is possible for the returned pointer to be NULL if an error occurred or no data is returned. timeout Input The time (in milliseconds) to wait for a response from the server. A value of -1 uses the DEFAULT_MESSAGE_TIMEOUT as defined in twDefaultSettings.h. forceConnect Input A Boolean value. If TRUE and the API is in the disconnected state of the duty cycle, the API will force a reconnect to send the request.   See below for an example in which the Copy service from the FileTransferSubsystem is called:   twDataShape * ds = NULL; twInfoTable * it = NULL; twInfoTableRow * row = NULL; twInfoTable * transferInfo = NULL; int res = 0; const char * sourceRepo = "SimpleThing_1"; const char * sourcePath = "tw/hotfolder/"; const char * sourceFile = "source.txt"; const char * targetRepo = "SystemRepository"; const char * targetPath = "/"; const char * targetFile = "source.txt"; uint32_t timeout = 60; char asynch = TRUE; char * tid = 0; /* Create an infotable out of the parameters */ ds = twDataShape_Create(twDataShapeEntry_Create("sourceRepo", NULL, TW_STRING)); res = twDataShape_AddEntry(ds, twDataShapeEntry_Create("sourcePath", NULL, TW_STRING)); res |= twDataShape_AddEntry(ds, twDataShapeEntry_Create("sourceFile", NULL, TW_STRING)); res |= twDataShape_AddEntry(ds, twDataShapeEntry_Create("targetRepo", NULL, TW_STRING)); res |= twDataShape_AddEntry(ds, twDataShapeEntry_Create("targetPath", NULL, TW_STRING)); res |= twDataShape_AddEntry(ds, twDataShapeEntry_Create("targetFile", NULL, TW_STRING)); res |= twDataShape_AddEntry(ds, twDataShapeEntry_Create("async", NULL, TW_BOOLEAN)); res |= twDataShape_AddEntry(ds, twDataShapeEntry_Create("timeout", NULL, TW_INTEGER)); it = twInfoTable_Create(ds); row = twInfoTableRow_Create(twPrimitive_CreateFromString(sourceRepo, TRUE)); res = twInfoTableRow_AddEntry(row, twPrimitive_CreateFromString(sourcePath, TRUE)); res |= twInfoTableRow_AddEntry(row, twPrimitive_CreateFromString(sourceFile, TRUE)); res |= twInfoTableRow_AddEntry(row, twPrimitive_CreateFromString(targetRepo, TRUE)); res |= twInfoTableRow_AddEntry(row, twPrimitive_CreateFromString(targetPath, TRUE)); res |= twInfoTableRow_AddEntry(row, twPrimitive_CreateFromString(targetFile, TRUE)); res |= twInfoTableRow_AddEntry(row, twPrimitive_CreateFromBoolean(asynch)); res |= twInfoTableRow_AddEntry(row, twPrimitive_CreateFromInteger(timeout)); twInfoTable_AddRow(it,row); /* Make the service call */ res = twApi_InvokeService(TW_SUBSYSTEM, "FileTransferSubsystem", "Copy", it, &transferInfo, timeout ? (timeout * 2): -1, FALSE); twInfoTable_Delete(it); /* Grab the tid */ res = twInfoTable_GetString(transferInfo,"transferId",0, &tid);   Bind Event Handling You may want to track exactly when your edge Entities are successfully bound to or unbound from the server. The reason for this is that only bound items should be interacting with the ThingWorx Platform and the ThingWorx Platform will never send any requests targeted at an Entity that is not bound. A simple example that only logs the bound Thing can be seen below. After creating this function, it will need to be registered using the twApi_RegisterBindEventCallback function before the connection is made.   void BindEventHandler(char * entityName, char isBound, void * userdata) { if (isBound) TW_LOG(TW_FORCE,"BindEventHandler: Entity %s was Bound", entityName); else TW_LOG(TW_FORCE,"BindEventHandler: Entity %s was Unbound", entityName); } …. twApi_RegisterBindEventCallback(thingName, BindEventHandler, NULL);   OnAuthenticated Event Handling   You may also want to know exactly when your Edge device has successfully authenticated and made a connection to the ThingWorx platform. Like the bind Event handling, this function will need to be made and registered. To register this handler, use the   twApi_RegisterOnAuthenticated Callback function before the connection is made. This handler form can also be used to do a delay bind for all Things.   void AuthEventHandler(char * credType, char * credValue, void * userdata) { if (!credType || !credValue) return; TW_LOG(TW_FORCE,"AuthEventHandler: Authenticated using %s = %s. Userdata = 0x%x", credType, credValue, userdata); /* Could do a delayed bind here */ /* twApi_BindThing(thingName); */ } … twApi_RegisterOnAuthenticatedCallback(AuthEventHandler, NULL);     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); }   Click here to view Part 4 of this guide

    Configure ThingWorx Advisors to remotely monitor your connected assets.   Guide Concept   This project will introduce ThingWorx Advisors.   Following the steps in this guide, you will learn how to add users, create a model to store data, and configure asset Properties.   We will show you how ThingWorx Advisors let you remotely monitor equipment without writing any code.   You'll learn how to   Configure ThingWorx Advsors Connect ThingWorx Advisors to ThingWorx Kepware Server Create assets in ThingWorx and tie them to data items in Kepware Server   NOTE: The estimated time to complete this guide is 60 minutes       Step 1: Configure Connection   This step shows how to open Controls Advisor, and configure the communication with ThingWorx Kepware Server.   Open Controls Advisor   Click on Hosted Server Info to open your ThingWorx Foundation server. In ThingWorx Foundation Composer, click Browse then Visualization > Master then click PTC.Factory.PlantStatus.Master.   Next click View Mashup button.    Click the App Switcher icon in the upper left.    Create Connection   In the top-left, click the app switcher icon. Click Controls Advisor in the app switcher.     click-controls-advisor     3. Click the + icon to add a new Connection.     click-plus-add-connection     4. Enter my-kepware-connection in the Connection Name field. 5. Click the wand icon in the Application Key User Name dropdown and select Administrator. 6. Click the Application Key Expiration Date date picker and select a date a year in the future.     create-connection     7. Click Done to close the date picker, then click OK. 8. Information that you will enter in Kepware is shown, click Print Instructions to save.     connection-summary     NOTE: If no port is shown, use 80 for an HTTP connection or 443 for an HTTPS connection. 9. Click Close to close the connection inforamtion pop-up. 10. The information is always available by selecting the Key icon in Controls Advisor.     new-connection-saved       Configure Communication with Kepware   Open ThingWorx Kepware Server configuration tool using either the desktop shortcut or the task bar icon.   Right click Project and select Properties to configure the connection with ThingWorx.   kepware-properties     3, Select ThingWorx in left panel. Under Connection Settings, update the Host, Port and Application Key to match your ThingWorx server.     /kepware-thingworx-settings     NOTE: All the required information is available in the "print" browser tab from the previous step. If no port number is shown, use 80 for an HTTP connection or 443 for an HTTPS connection.   4. Set Disable Encryption to No and Trust all Certificates to Yes. 5. Enter my-kepware-connection-GW in Thing name. 6. Click Apply, then OK. 7. Check Connected to ThingWorx is shown in Kepware.   NOTE: The message displayed should say: Connected to ThingWorx.    Troubleshooting   If you are unable to make a connection from KEPServerEX®, try the following:   Verify that the information you entered into the KEPServerEX Project Properties is exactly as displayed in the on-screen set-up instructions. If KEPServerEX is on a different machine than ThingWorx® ensure that your firewall is set to allow incoming connections on the port specified.     Step 2: Add User   In this part of the lesson, you'll create a User and modify permissions.   Click the grid icon located in the upper left to switch to a different utility.   Click the Configuration and Setup utility icon.    Click the Users tab, then click the Plus icon to open the Create User pop-up.   Enter a User Name that is at least 3 characters.   Enter the required First Name and Last Name. Although they will not be used in this guide, enter the required Email and Work Phone. Enter Mobile Phone including + and country code, +1 for US mobile phones. Check the SMS Notification Preference.   Enter a Password of at least 14 characters, then re-enter it in the Confirm Password field.   Create a User for yourself as a Controls Engineer. This role gives access to all of the Advisors installed on the system. The other roles are given a subset of the Advisors, depending on the functionality they need to perform their jobs.         Step 3: Create a Model   In this part of the lesson, you will create a Model to store data.   If Configuration and Setup is not already open, click the Utility Selector grid in the upper left, then click the Configuration and Setup utility icon.    Click on the Equipment tab.   Click on the + icon on the top left to add a new asset.   Set the new resource to Asset and name it Asset1. NOTE: You can also enter a description. Create another resource, this time with the Type set to Line. Name it Station A. After both resources have been created, select Asset1 and then click the pencil icon to configure it. On the Asset Configuration Details page, locate the Related Lines table. Click the + icon to relate line to the asset.   Select Station A, then click Add.   Step 4: Configure Asset Properties   From the Administration and Configuration page for Asset1, click Additional Properties located in the left-hand navigation pane.   Click the + icon to add a new property to the asset. Name the Property Temp.   Click the tag picker icon to associate this property in ThingWorx with a data tag from KEPServerEX. In the Resource Type drop-down, choose KEPServerEX. Select your server name (for this exercise, we use KEPServerEX.Local). NOTE: You will see a hierarchical view of all tags available from your KEPServerEX instance. In the left column, scroll down to Ch1 and click the triangle icon to expand it. Click Ch1.Asset1 to see the available Tags in the right column.   Select Temperature, then click OK. Click Save to save this Property. TIP: For additional practice, try to add a few more assets.   Step 5: Next Steps   Congratulations! You've successfully completed the Configure ThingWorx Advisors guide. In this guide, you learned how to configure ThingWorx Advisors to connect to KEPServerEX and connect an asset.   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community ThingWorx Advisors Community Support Kepware Technical Support Asset Advisor for service Home ThingWorx Asset Advisor for service

    Step 8: Learn More About Widgets   For more details on how to use and customize Widgets highlighted in this guide, refer to:    Widget            Link to How-To Layout Customizable and Responsive UI Gauge Display Property Values with a Gauge Style Define Your UI Style Navigation Customizable and Responsive UI Google Map Display Geolocation Data in Your UI     Step 9: Next Steps   Congratulations! You've successfully completed the Design an Effective UI guide, and learned best practices for building a complex Mashup that includes maps, menus, and detail sections all working together effectively for an enhanced user experience.   Learn More   We recommend the following resources to continue your learning experience:     Capability    Guide Experience Object-Oriented UI Design Tips   Additional Resources   If you have questions, issues, or need additional information, refer to:     Resource      Link Community Developer Community Forum Support Mashup Builder Support Help Center

  Step 6: Create OPC UA Tag in ThingWorx   We will now create a Device in Kepware with a Tag whose value will be shown in ThingWorx.   Right-click on Channel1 that was just created, then click Next to accept the default name Device1       Click Next six times to accept the default settings, Then click the Select import items button.     Expand the remote OPC UA server URL, then expand OpcPlc and Telemetry.     Click SlowUint1 to select it, then click Add items >>. Click OK, Next, Finish. Return to ThingWorx Composer. Under Browse > Modeling > Industrial Connections, open IndConn_Server. Expand Channel1 > Device1 > OpcPlc, then click Telemetry.     Click the check-box next to SlowUint1. Click Bind to New Entity.     Select RemoteThing, then click OK. Enter azure-opcua-plc in the Name field, then click Save.     Click Properties and Alerts, then Click Refresh to see the property value changing every 10 seconds.     Step 7: Next Steps   Congratulations! You've successfully completed the Connect to an Azure OPC UA Server guide, and learned how to:   Create an OPC UA Server in Azure Configure Kepware as on OPC UA Client Connect Kepware to ThingWorx Foundation Monitor OPC UA data in ThingWorx Composer   Learn More   We recommend the following resources to continue your learning experience: Capability Guide 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 Getting Started with ThingWorx Documentation Kepware documentation Support Kepware Support site

  Step 5: Properties   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 deliveryTruck.c helper C file is based on the DeliveryTruck Entities in the Composer. After calling the construct function, there are a number of steps necessary to get going. For the SimpleThing application, there are a number of methods for creating Properties, Events, Services, and Data Shapes for ease of use.   Properties can be created in the client or just registered and utilized. In the  SimpleThingClient  application, Properties are created. In the DeliveryTruckClient application, Properties are bound to their ThingWorx Platform counterpart. Two types of structures are used by the C SDK to define Properties when it is seen fit to do so and can be found in [C SDK HOME DIR]/src/api/twProperties.h:   Name Structure Description Property Definitions twPropertyDef Describes the basic information for the Properties that will be available to ThingWorx and can be added to a client application. Property Values twProperty Associates the Property name with a value, timestamp, and quality.   NOTE: The C SDK provides a number of Macros located in [C SDK HOME DIR]/src/api/twMacros.h. This guide will use these Macros while providing input on the use of pure function calls.   The Macro example below can be found in the main source file for the   SimpleThingClient   application and the accompanying helper file simple_thing.c.   TW_PROPERTY("TempProperty", "Description for TempProperty", TW_NUMBER); TW_ADD_BOOLEAN_ASPECT("TempProperty", TW_ASPECT_ISREADONLY,TRUE); TW_ADD_BOOLEAN_ASPECT("TempProperty", TW_ASPECT_ISLOGGED,TRUE); NOTE: The list of aspect configurations can be seen in [C SDK HOME DIR]/src/api/twConstants.h. Property values can be set with defaults using the aspects setting. Setting a default value in the client will affect the Property in the ThingWorx platform after binding. It will not set a local value in the client application.   For the DeliveryTruckClient, we registered, read, and update Properties without using the Property definitions. Which method of using Properties is based on the application being built.   NOTE: Updating Properties in the ThingWorx Platform while the application is running, will update the values in the client application. To update the values in the platform to match, end the Property read section of your property handler function with a function to set the platform value.   The createTruckThing function for the deliveryTruck.c source code takes a truck name as a parameter and is used to register the Properties, functions, and handlers for each truck.   The updateTruckThing function for the deliveryTruck.c source code takes a truck name as a parameter and is used to either initialize a struct for DeliveryTruck Properties, or simulate a truck stop Event, update Properties, then fire an Event for the ThingWorx platform.   Connecting properties to be used on the platform is as easy as registering the property and optionally adding aspects. 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 the  TW_PROPERTY macro as shown in the deliveryTruck.c. This macro must be proceeded by either TW_DECLARE_SHAPE, TW_DECLARE_TEMPLATE or TW_MAKE_THING because these macros declare variables used by the TW_PROPERTY that follow them.   //TW_PROPERTY(propertyName,description,type) TW_PROPERTY(PROPERTY_NAME_DRIVER, NO_DESCRIPTION, TW_STRING); TW_PROPERTY(PROPERTY_NAME_DELIVERIES_LEFT, NO_DESCRIPTION, TW_NUMBER); TW_PROPERTY(PROPERTY_NAME_TOTAL_DELIVERIES, NO_DESCRIPTION, TW_NUMBER); TW_PROPERTY(PROPERTY_NAME_DELIVERIES_MADE, NO_DESCRIPTION, TW_NUMBER); TW_PROPERTY(PROPERTY_NAME_LOCATION, NO_DESCRIPTION, TW_LOCATION); TW_PROPERTY(PROPERTY_NAME_SPEED, NO_DESCRIPTION, "TW_NUMBER);   Read Properties   Reading Properties from a ThingWorx platform Thing or the returned Properties of a Service can be done using the TW_GET_PROPERTY macro. Examples of its use can be seen in all of the provided applications. An example can be seen below:   int flow = TW_GET_PROPERTY(thingName, "TotalFlow").number; int pressue = TW_GET_PROPERTY(thingName, "Pressure").number; twLocation location = TW_GET_PROPERTY(thingName, "Location").location; int temperature = TW_GET_PROPERTY(thingName, "Temperature").number;   Write Properties   Writing Properties to a ThingWorx platform Thing from a variable storing is value uses a similarly named method. Using the TW_SET_PROPERTY macro will be able to send values to the platform. Examples of its use can be seen in all of the provided applications. An example is shown below:   TW_SET_PROPERTY(thingName, "TotalFlow", TW_MAKE_NUMBER(rand() / (RAND_MAX / 10.0))); TW_SET_PROPERTY(thingName, "Pressure", TW_MAKE_NUMBER(18 + rand() / (RAND_MAX / 5.0))); TW_SET_PROPERTY(thingName, "Location", TW_MAKE_LOC(gpsroute[location_step].latitude,gpsroute[location_step].longitude,gpsroute[location_step].elevation));   This macro utilizes the twApi_PushSubscribedProperties function call to pushe all property updates to the server. This can be seen in the updateTruckThing function in deliveryTruck.c.   Property Change Listeners   Using the Observer pattern, you can take advantage of the Property change listener functionality. With this pattern, you create functions that will be notified when a value of a Property has been changed (whether on the server or locally by your program when the TW_SET_PROPERTY macro is called).   Add a Property Change Listener   In order to add a Property change listener, call the twExt_AddPropertyChangeListener function using the:   Name of the Thing (entityName) Property this listener should watch Function that will be called when the property has changed void simplePropertyObserver(const char * entityName, const char * thingName,twPrimitive* newValue){ printf("My Value has changed\n"); } void test_simplePropertyChangeListener() { { TW_MAKE_THING("observedThing",TW_THING_TEMPLATE_GENERIC); TW_PROPERTY("TotalFlow", TW_NO_DESCRIPTION, TW_NUMBER); } twExt_AddPropertyChangeListener("observedThing",TW_OBSERVE_ALL_PROPERTIES,simplePropertyObserver); TW_SET_PROPERTY("observedThing","TotalFlow",TW_MAKE_NUMBER(50)); }   NOTE: Setting the propertyName parameter to NULL or TW_OBSERVE_ALL_PROPERTIES, the function specified by the propertyChangeListenerFunction parameter will be used for ALL properties.   Remove a Property Change Listener   In order to release the memory for your application when done with utilizing listeners for the Property, call the twExt_RemovePropertyChangeListener function.   void simplePropertyObserver(const char * entityName, const char * thingName,twPrimitive* newValue){ printf("My Value has changed\n"); } twExt_RemovePropertyChangeListener(simplePropertyObserver);   Click here to view Part 3 of this guide  

  Use ThingWorx Advisors to view trends and monitor Alerts. Step 2: Create and Configure Alert   Click the grid icon.   Select Configuration and Setup, then select the Alert tab. NOTE: If you are using the Demo Factory Simulator, you will see that several alerts have already been configured. To create a new alert, click the Alert tab, then click the + icon. Select the following properties in the Select Tag or Property box: Under Equipment Type, select Asset. Under Equipment, select 1-3_CNCMill. In Properties, click Temperature. Click OK. Set up the following in the Create New Alert pop-up: In the Alert Name text box, type HighTemp. In the Alert Type drop-down, choose Above. In the Value text box, type 34. In the Alert Description text box, type Temperature close to failure.   NOTE: An Alert will now be triggered whenever the temperature of Asset1 is more than 34.   Step 3: Monitor Alert   Click the grid icon. Select Alert Monitoring. NOTE: You can see the temperature alert message that you created earlier, and the amount of time that it’s been in that state. Select the HighTemp alert. Confirm that the Acknowledged field is recorded as false in the lower left-hand corner beneath the Details.   Select the HighTemp alert, then click the check mark icon to acknowledge the alert.   In the Acknowledge Alerts dialog, provide explanation. Click OK.   Note the updates to the Alert Monitoring page.   NOTE: Anyone viewing the Alerts will now be able to clearly see the green check mark, which indicates that the Alert has been acknowledged.   Step 4: Next Steps  Next Steps   Congratulations! You've successfully completed the Configure ThingWorx Advisors for Trending and Alerts guide. You have learned how to create and monitor trends and alerts based on assets connected with Kepware.   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community ThingWorx Manufacturing Community Support Kepware Technical Support Manufacturing Home ThingWorx Manufacturing    

    Watch a video tutorial on utilizing the Mashup Builder to create a User Interface (UI) for your IoT application.   Guide Concept   This project will introduce the ThingWorx Mashup Builder through the use of an instructional video. Following the steps in this video-guide, you will learn how to use this tool to create a Graphical User Interface (GUI) for your IoT Application. We will teach you how to rapidly create and update a Mashup, which is a custom visualization built to display data from devices according to your application's business and technical requirements.     You'll learn how to   Create new Mashups Choose a Static or Responsive layout Add Widgets to your Mashup Bind data Services to Widgets in your Mashup Create a functional GUI with applied usage of Widgets and Services   NOTE: The estimated time to complete this guide is 30 minutes       Step 1: Video   Click the link below to enjoy the video. You may set the video to full screen by clicking the button in the bottom-right.   If you're following along within your own ThingWorx environment, you may wish to pre-download and extract the attached MBQS_Entities.zip file. It will be used in the later half of the video as a backend data simulator.   Create Your Application UI - Video Guide     Step 2: Next Steps   Congratulations! You've successfully completed the Video Guide - Create Your Application UI, and learned how to:   Create new Mashups Choose a Static or Responsive layout Add Widgets to your Mashup Bind data Services to Widgets in your Mashup Create a functional GUI with applied usage of Widgets and Services   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Build Data Model Introduction Experience Object-Oriented UI Design Tips   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Mashup Builder Support Help Center

    Step 2: Java Properties (cont.)   Annotation @ThingworxPropertyDefinitions(properties = { @ThingworxPropertyDefinition(name = "Temperature", description = "Current Temperature", baseType = "NUMBER", category = "Status", aspects = { "isReadOnly:true" }), @ThingworxPropertyDefinition(name = "Pressure", description = "Current Pressure", baseType = "NUMBER", category = "Status", aspects = { "isReadOnly:true" }), @ThingworxPropertyDefinition(name = "FaultStatus", description = "Fault status", baseType = "BOOLEAN", category = "Faults", aspects = { "isReadOnly:true" }), @ThingworxPropertyDefinition(name = "InletValve", description = "Inlet valve state", baseType = "BOOLEAN", category = "Status", aspects = { "isReadOnly:true" }), @ThingworxPropertyDefinition(name = "TemperatureLimit", description = "Temperature fault limit", baseType = "NUMBER", category = "Faults", aspects = { "isReadOnly:false" }), @ThingworxPropertyDefinition(name = "TotalFlow", description = "Total flow", baseType = "NUMBER", category = "Aggregates", aspects = { "isReadOnly:true" }), })   NOTE: The call to VirtualThing.initializeFromAnnotations is necessary if there are properties, services, and events that are annotated.   Code //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);   Update Properties   Property values can be updated using the provided Macros or using the API directly.   The VirtualThing.setPropertyVTQ and VirtualThing.setProperty methods are used to update properties connected to the ThingWorx Platform. It is often easiest to use the setProperty method because it allows the usage of values outside of IPrimitiveType. Using these methods will fire a property changed event and also look to add the update to the pending list of changes to the Platform based on your DataChangeType aspect used for the property. An example of how to use VirtualThing.setProperty can be seen below: double temperature = 400 + 40 * Math.random(); super.setProperty("Temperature", temperature);   NOTE: setPropertyVTQ and setProperty are both methods inside of the VirtualThing class. All objects you would like to have represented in the ThingWorx Platform as an Entity, must extend the VirtualThing class.   When finished with updating all property values, use the VirtualThing.updateSubscribedProperties method to send the queue of changes to the Platform. Property value updates will NOT be sent to the platform if this method is not called. An example can be seen below:   super.updateSubscribedProperties(15000);   Retrieve Properties   Property values can be retrieved using the provided Macros or using the API directly.   The VirtualThing.getProperty and VirtualThing.getCurrentPropertyValue methods are used to retrieve properties connected to the ThingWorx Platform. The VirtualThing.getProperties returns a PropertyCollection which provides a collection type behavior for all properties initialized within your implementation. An example of how to use VirtualThing.getProperty can be seen below:   double temperatureLimit = (Double) getProperty("TemperatureLimit").getValue().getValue();   NOTE: getProperty and getCurrentPropertyValue are both methods inside of the VirtualThing class. All objects you would like to have represented in the ThingWorx Platform as an Entity, must extend the VirtualThing class.   Synchronize Updates   The VirtualThing.synchronizeState method is called when a connect or reconnect occurs. If property values are not synced with the ThingWorx Platform on a regular basis, this method should be overridden with a call to sync properties. An example of this is shown below: public void synchronizeState() { super.synchronizeState(); super.syncProperties(); }   Scan Cycles The VirtualThing.processScanRequest method should be overridden and used to perform the tasks that should occur during a scan cycle. A scan cycle could be considered a reoccurring period in which a task is performed. This should be called and performed after a connection is made and while the application is still connected to the ThingWorx Platform. An example is as follows: while (!client.isShutdown()) { if (client.isConnected()) { for (VirtualThing thing : client.getThings().values()) { try { thing.processScanRequest(); } catch (Exception exception) { System.out.println("Error Processing Scan Request for [" + thing.getName() + "] : " + exception.getMessage()); } } } Thread.sleep(1000); }       Step 3: Java - Data Shapes   DataShapes are used for Events, Services, and InfoTables. In order to create a DataShape, you will use the FieldDefinitionCollection class with a FieldDefinition object to set each aspect and field type for the DataShape. The VirtualThing.defineDataShapeDefinition method adds the recently created definition to the Entities list of DataShapes. If the DataShape is located on the ThingWorx Platform, utilize the ConnectedThingClient.getDataShapeDefinition method in order to retrieve it. An example is shown below of how to create a DataShape and store it to the list of available DataShapes: // 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);       Step 4: Java - Info Tables   Infotables are used for storing and retrieving data from service calls.   The provided InfoTable object uses a DataShapeDefinition object to describe the name, base type, and additional information about each field within the table.   The InfoTable class is a collection of ValueCollection entries for each row based on the DataShapeDefinition. When reading values from an InfoTable or loading an InfoTable with data, you will need to use the ValueCollection class.   Create and Load   The code below shows how to utilize these classes in order to create and add data to an InfoTable: DataShapeDefinition dsd = (DataShapeDefinition) this.getDataShapeDefinitions().get("SteamSensorReadings"); InfoTable table = new InfoTable(dsd); ValueCollection entry = new ValueCollection(); DateTime now = DateTime.now(); try { // entry 1 entry.clear(); entry.SetStringValue(SENSOR_NAME_FIELD, "Sensor Alpha"); entry.SetDateTimeValue(ACTIV_TIME_FIELD, now.plusDays(1)); entry.SetNumberValue(TEMPERATURE_FIELD, 50); entry.SetNumberValue(PRESSURE_FIELD, 15); entry.SetBooleanValue(FAULT_STATUS_FIELD, false); entry.SetBooleanValue(INLET_VALVE_FIELD, true); entry.SetNumberValue(TEMPERATURE_LIMIT_FIELD, 150); entry.SetNumberValue(TOTAL_FLOW_FIELD, 87); table.addRow(entry.clone()); // entry 2 entry.clear(); entry.SetStringValue(SENSOR_NAME_FIELD, "Sensor Beta"); entry.SetDateTimeValue(ACTIV_TIME_FIELD, now.plusDays(2)); entry.SetNumberValue(TEMPERATURE_FIELD, 60); entry.SetNumberValue(PRESSURE_FIELD, 25); entry.SetBooleanValue(FAULT_STATUS_FIELD, true); entry.SetBooleanValue(INLET_VALVE_FIELD, true); entry.SetNumberValue(TEMPERATURE_LIMIT_FIELD, 150); entry.SetNumberValue(TOTAL_FLOW_FIELD, 77); table.addRow(entry.clone()); } catch (Exception e) { e.printStackTrace(); }   Read   This code shows how to read a value from an InfoTable. InfoTable result = client.readProperty(ThingworxEntityTypes.Things, "SteamSensor", "name", 10000); String name = result.getFirstRow().getStringValue("name");   The example highlighted below showcases one way to get a property reading from a Thing in the ThingWorx Platform. InfoTable result = client.readProperty(ThingworxEntityTypes.Things, "SteamSensor", "name", 10000); ValueCollection entry = result.getFirstRow(); String name = entry.getStringValue("name");     Click here to view Part 4 of this guide.  

    Use the Pareto Chart Widget to visualize how issues compound to cause problems.   GUIDE CONCEPT   The Pareto Chart Widget is a useful method of displaying aggregate information.  In particular, it is often used to display multiple issues and how they combine to form an overall, larger problem.    This can be helpful when trying to determine "easy wins" by pointing out where your efforts will have the greatest impact.       YOU'LL LEARN HOW TO   Create a Data Shape Create a Thing Create an Info Table Property Populate an Info Table with appropriate data for a Pareto Chart Create a Mashup Utilize a Pareto Chart to display issue-aggregation   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete this guide is 30 minutes       Step 1: Scenario   In this guide, we'll assume a scenario where a factory is being automated using ThingWorx Foundation. In particular, this factory has some known issues with a robot arm that performs welding at a point along a conveyor belt.    When this welding robot has these issues, the factory line has to come to a complete halt while maintenance is performed on it.   Management has decided that these slow-downs are costing enough money that the robot arm needs some extra attention, up to and including modification to help alleviate these maintenance stops.    However, they're not sure what to tackle first. Every issues leads to a slow down, but some happen more frequently than others.    After talking with maintenance, four primary issues are identified, i.e.   Excess temperature on the welding end has caused some welds to fail due to simply burning through the material. Some of the joints need regular lubrication, preventing the arm from getting to the correct location in time as the part moves down the conveyor belt. The welding filler-material sometimes runs out, causing a stop while more is reloaded. The welding shielding gas sometimes runs out, causing a stop while more is reloaded.   Your task, then, is to start counting the number of times each of these failures occur. In addition, you need to create a small GUI which displays both how often these errors occur, and how they contribute to the overall downtime.    To accomplish this, you'll use a Pareto Chart Widget.     Step 2: Create Data Shape   In this scenario, we'll store the Pareto Chart's data in a Property type called an Info Table.   An Info Table is a spreadsheet-like Property, but in order to define the columns of the table, we first have to define a Data Shape. We'll do that in this step.   In the left-side navigation, click Browse > Modeling > Data Shapes. At the top, click + New. In the Name field, type TIPC_DataShape. If Project is not already set, search for and select PTCDefaultProject. At the top, click Field Definitions. At the top-left, click + Add. On the right-side slide-out, in the Name field, type month. Note that you want to leave "Base Type" as the default of "STRING". Check Is Primary Key. Click the "check with a plus" button for Done and Add. Add each of the following Field Definitions, entering the Name and selecting the Base Type from the drop-down as described in the table: Note that you will NOT enable "Is Primary Key" on any other Field Definitions, as you only need one Primary Key. Note that you will simply click the "check" button for Done after the last entry . Name Base Type  excess_temperature NUMBER  need_lubricant NUMBER  low_filler NUMBER  low_gas NUMBER At the top, click Save.   Step 3: Create Thing   Now that we have our Data Shape, we can create a Thing to hold the collected counts of various issues.   As already mentioned, we'll use an Info Table Property, formatted by the previously-created Data Shape, to do so.   Click Browse > Modeling > Things.   Click + New. In the Name field, type TIPC_Thing. If Project is not already set, search for and select PTCDefaultProject. In the Base Thing Template field, search for and select GenericThing.   At the top, click Save.     Add Info Table Property   Now that we have our Thing instantiated, we want to both add an Info Table Property, as well as set some Default Values.   At the top, click Properties and Alerts.   Click + Add.   On the right-side slide-out, in the Name field, type InfoTable_Property. Change Base Type to INFOTABLE. In the Data Shape field, search for and select TIPC_DataShape. Note that the Data Shape field will not appear until you set Base Type to INFOTABLE. Check Persistent.   At the top-right, click the "check" button for Done. At the top, click Save.   Set Value of Property Now that we have a place in which to store spreadsheet-like values, we'll do so manually for testing.   On the InfoTable_Property row, under the Value column, click the "pencil" icon for Set value of property.   On the pop-up, click + Add.   Enter the following values in each field as per the table below: Field Name Value month  January excess_temperature 5 need_lubricant 2 low_filler 1 low_gas 2   Click Add.   Click + Add again, enter the following values, and finish input by clicking Add, as per above. Field Name Value month February excess_temperature 7 need_lubricant 1 low_filler 3 low_gas 2 6. Click + Add again, enter the following values, and finish input by clicking Add, as per above. Field Name Value month March excess_temperature 6 need_lubricant 2 low_filler 1 low_gas 1   7. On the pop-up, click Save.   8. At the top, click Save.   Step 4: Create Mashup   Now that we have our data in-place for testing (and could be connected to automated systems after we finish testing), we need to visualize the data.   As mentioned, we'll use a Pareto Chart Widget, but first, we need to create a Mashup into which we can place the Widget.   Click Browse > Visualization > Mashups.   Click + New.   Leave the defaults and click OK.   In the Name field, type TIPC_Mashup. If Project is not already set, search for and select PTCDefaultProject. At the top, click Save .   At the top, click Design.   At the top-left, click the Widgets tab.   Drag-and-drop a Pareto Chart Widget onto the central Canvas.   At the top, click Save.   Click here to view Part 2 of this guide.

  Step 5: Additional Services   The Trend, Range, and Threshold Services are some of the Services the Statistical Monitoring ThingShape offers. Below is a table of additional included Services.   Links to guides for using services like these to build complete IoT applications are found in the next step.   Calculation Service Name Description Consecutive Points Based On a Range GetNumberOfConsecutivePointsBasedOnARange Calculate the number of points in the largest group of consecutive points meeting the range criteria. Consecutive Points Based On a Threshold GetNumberOfConsecutivePointsBeyondAThreshold Calculate the number of points in the largest group of consecutive points meeting the threshold criteria. Number of Points with Percentage Change Out of Range GetNumberOfPointsWithChangeRateOutOfRange Monitor for how many pairs of consecutive points in a series have a numerical percentage change outside the defined range. If the first value in a pair is 0, the pair is not considered.       Step 6: Next Steps   Congratulations!   In this guide, you've learned how to:   Create a Value Stream Create a Thing with the Statistical Monitoring Thing Shape Modify a Property to record values to the Value Stream Test built-in Services used in Statistical Monitoring   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Build Get Started with ThingWorx for IoT Build Build a Predictive Analytics Model Build Operationalize an Analytics Model   Additional Resources   If you have questions, issues, or need additional information, refer to:   Resource Link Community Developer Community Forum Support Descriptive Analytics Help Center    

  Step 5: Java - Events   While connected to the server, you can trigger an event on a remote Thing. The code snippet from the Simple Thing example below shows how to use a ValueCollection to specify the payload of an event, and then trigger a FileEvent on a remote Thing.   Create Event   The two implementations of the VirtualThing.defineEvent method are used to create an event definition ThingWorx Platform. @ThingworxEventDefinitions(events = { @ThingworxEventDefinition(name = "SteamSensorFault", description = "Steam sensor fault", dataShape = "SteamSensor.Fault", category = "Faults", isInvocable = true, isPropertyEvent = false) }) public void defineEvent(String name, String description, String dataShape, AspectCollection aspects) { EventDefinition eventDefinition = new EventDefinition(name, description); eventDefinition.setDataShapeName(dataShape); if (aspects != null) { eventDefinition.setAspects(aspects); } this.getThingShape().getEventDefinitions().put(name, eventDefinition); } public void defineEvent(EventDefinition eventDefinition) { this.getThingShape().getEventDefinitions().put(eventDefinition.getName(), eventDefinition); }   Queue Event   To queue an event, create a ValueCollection instance, and load it with the necessary fields for the DataShape of that event. ValueCollection eventInfo = new ValueCollection(); eventInfo.put(CommonPropertyNames.PROP_MESSAGE, new StringPrimitive("Temperature at " + temperature + " was above limit of " + temperatureLimit)); super.queueEvent("SteamSensorFault", DateTime.now(), eventInfo); super.updateSubscribedEvents(60000);   Fire Event   You can send the client a 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 order to send the Event to the ThingWorx Platform, use the VirtualThing.updateSubscribedEvents method. ValueCollection eventInfo = new ValueCollection(); eventInfo.put(CommonPropertyNames.PROP_MESSAGE, new StringPrimitive("Temperature at " + temperature + " was above limit of " + temperatureLimit)); super.queueEvent("SteamSensorFault", DateTime.now(), eventInfo); super.updateSubscribedEvents(60000);     Step 6: Java - Services   Create Services   Simply use the ThingworxServiceDefinition and ThingworxServiceResult anotations to create a service. Then, you can define the service as shown in this code: @ThingworxServiceDefinition(name = "GetSteamSensorReadings", description = "Get SteamSensor Readings") @ThingworxServiceResult(name = CommonPropertyNames.PROP_RESULT, description = "Result", baseType = "INFOTABLE", aspects = { "dataShape:SteamSensorReadings" }) public InfoTable GetSteamSensorReadings() { InfoTable table = new InfoTable(getDataShapeDefinition("SteamSensorReadings")); ValueCollection entry = new ValueCollection(); DateTime now = DateTime.now(); try { // entry 1 entry.clear(); entry.SetStringValue(SENSOR_NAME_FIELD, "Sensor Alpha"); entry.SetDateTimeValue(ACTIV_TIME_FIELD, now.plusDays(1)); entry.SetNumberValue(TEMPERATURE_FIELD, 50); entry.SetNumberValue(PRESSURE_FIELD, 15); entry.SetBooleanValue(FAULT_STATUS_FIELD, false); entry.SetBooleanValue(INLET_VALVE_FIELD, true); entry.SetNumberValue(TEMPERATURE_LIMIT_FIELD, 150); entry.SetNumberValue(TOTAL_FLOW_FIELD, 87); table.addRow(entry.clone()); // entry 2 entry.clear(); entry.SetStringValue(SENSOR_NAME_FIELD, "Sensor Beta"); entry.SetDateTimeValue(ACTIV_TIME_FIELD, now.plusDays(2)); entry.SetNumberValue(TEMPERATURE_FIELD, 60); entry.SetNumberValue(PRESSURE_FIELD, 25); entry.SetBooleanValue(FAULT_STATUS_FIELD, true); entry.SetBooleanValue(INLET_VALVE_FIELD, true); entry.SetNumberValue(TEMPERATURE_LIMIT_FIELD, 150); entry.SetNumberValue(TOTAL_FLOW_FIELD, 77); table.addRow(entry.clone()); } catch (Exception e) { e.printStackTrace(); } return table; }   NOTE: This service will be callable by the ThingWorx Platform.   Call Services   The are two types of service calls that can be made. The first type belongs to the ConnectedThingClient class. This client has methods for processing information where only the parameters for the method is necessary. The other type of call is based on services located on an Entity. For these calls, you must create a ValueCollection instance, and load it with the necessary parameters of the service.   After loading the ValueCollection instance, send the client the request to execute the service with the:   Parameter values Service name Timeout setting (in milliseconds) for the service to finish executing Information to find the entity the service belongs to   The first type of call can be seen in SimpleClient.java: InfoTable result = client.readProperty(ThingworxEntityTypes.Things, ThingName, "name", 10000); String name = result.getFirstRow().getStringValue("name");   The second type of call can be seen below: ValueCollection payload = new ValueCollection(); payload.put("name", new StringPrimitive("Timothy")); InfoTable table = handleServiceRequest("ServiceName", payload);   TIP: Put the code for creating the service and event 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. We recommend the annotation method as shown in the examples because it is much cleaner.       Click here to view Part 5 of this guide.  

  Step 5: Add Data   Now that our Mashup's Layout and Widgets have been set, we need to bring in backend data and tie it to those Widgets for display.    We'll make use of Mashup Data Services for this. The first one we'll add will be UserManagementSubsystem > GetUserCount.   Ensure that the Data tab in the top-right is active.   Click the + icon.   In the Entity field, search for and select UserManagementSubsystem.   In the Services field, type GetUserCount.   Beside the GetUserCount Service, click the right arrow. Under Selected Services, check the box for Execute on Load.     Add LicensingSubsystem > GetCurrentLicenseInfo   You're not limited to only pulling information from one Mashup Data Service.   We already have User Management's GetUserCount. We'll now also bring in information from the Licensing Subsystem.   On the same Add Data pop-up, click the X beside UserManagementSubsystem to clear it.   In the Entity field, search for and select LicensingSubsystem.   In the Services field, type GetCurrentLicenseInfo.   Beside GetCurrentLicenseInfo, click the right arrow. Under Selected Services on the GetCurrentLicenseInfo line, check the box for Execute on Load.   On the bottom-right of the pop-up, click Done.   At the top, click Save.   Bind Data   With our backend data now accessible, let's bind it to our Widgets for display.   On the Data tab, expand Subsystems_LicensingSubsystem > GetCurrentLicenseInfo > Returned Data.   Drag-and-drop Licensing's All Data onto the Grid Advanced Widget in the bottom section.   On the Select Binding Target pop-up, click Data.   Expand Subsystems_UserManagementSubsystem > GetUserCount > Returned Data > All Data.   Drag-and-drop User Management's result onto the Text Field Widget in the top section.   On the Select Binding Target pop-up, click Text.   At the top, click Save.   Automatically Refresh   If we were to click View Mashup now, we would see the User Count and Licensing info displayed in the Mashup's Widgets. However, it would never update unless we manually refreshed the page.   To automate that process, we'll use the Auto Refresh Widget.   In the top section of the Mashup, click the Auto Refresh Widget to select it.   On the top-left of the Auto Refresh Widget, click the drop-down icon to reveal additional options.   Drag-and-drop the Refresh Event onto GetCurrentLicenseInfo.   Repeat steps 1-3 to drag-and-drop the Refresh Event onto GetUserCount also.   With the Auto Refresh Widget still selected, browse the Properties section in the bottom-left.   Change RefreshInterval to 5, and hit your keyboard's Tab key to lock in the change. This will cause the Refresh Event to fire every 5 seconds.   Click Save. Click View Mashup.     Step 6: Replace License   We have now created a Minimum Viable Product (MVP) of a "licensing dashboard" to ease our administration work.   This dashboard could still be improved. For instance, a Mashup Function could be created which automatically recalculates the value from GetUserCount to more accurately match GetCurrentLicenseInfo. This can be accomplished via the Mashup Builder's bottom-right Functions tab. Or, you could even add a separate Text Field Widget to to the top section and directly access the remaining license time via the LicensingSubsystem > GetDaysRemainingInLicense Service.    Whatever you choose to do to improve the Mashup is up to you.   However, what should be done when a license is nearing its expiration? To resolve this issue, we need to replace the existing license via the AcquireLicense Service.   Within the OS of the Foundation server, navigate to the file-system folder where the current license_capability_response.bin is located. This is typically the ThingworxPlatform folder.   Move the existing license_capability_response.bin and any other existing *.bin files to another location for backup. Note that this is EXTREMELY important, as if anything goes wrong, you want to be able to restore the original license. It is very important to ensure that only one *.bin file exists in the appropriate folder Place the new .bin file into the appropriate folder and rename it to license_capability_response.bin. In Foundation, navigate to the LicensingSubsystem > Services page.   On the AcquireLicense row, click the "play" icon for Execute Service.   On the bottom-right of the pop-up, click Execute. Note that if you receive an error, it will be necessary to restart the ThingWorx Tomcat service.  The act of restarting the service will automatically load the new license.   To close the pop-up, click Done.   After acquiring your new license, you should immediately return to the LicensingSubsystem and consult the GetCurrentLicenseInfo Service to confirm that Thing, User, expiration-date, and other issues are accurate.   If anything goes wrong with the new license transfer, you can simply replace the original license_capability_response.bin file and re-run AcquireLicense to return to your old one. Once again, it is import to perform these steps well before your expiration occurs.    Foundation checks for a valid license periodically. If this happens while you have an invalid license_capability_response.bin file in-place, you will no longer be able to access the Foundation GUI.    Fortunately, these issues are self-correcting if a valid license_capability_response.bin is placed in the correct location, as these periodic checks will also pick up a valid license_capability_response.bin file automatically, even after the system has locked you out.    You should also be able to trigger an AcquireLicense action via a REST call even if the GUI is unavailable.      Step 7: Next Steps   Congratulations! You've successfully completed the Manage Licensing with Foundation Subsystems guide.   In this guide, you learned how to:   Access the Foundation Subsystems Execute built-in Services to retrieve: User counts Thing counts License expiration count Create a "License Dashboard" Mashup Update to a new License    Additional Resources   If you have questions, issues, or need additional information, refer to:    Resource       Link Community Developer Community Forum Support Foundation Help Center  

  Step 8: C - Properties   In the ThingWorx environment, a Property represents a data point, which has a:   Name Value Timestamp Quality (optional)   Define Properties   You can define attributes, base types and other aspects of ThingWorx properties.   Attributes   The table below provides information on the different attributes that are used to define a property.   Attribute Details name Specifies the name of the property that will appear in ThingWorx when users browse to bind the related Thing. description Provides additional information for the property. baseType Specifies the type of the property. For a list of base types supported by the SDK, refer to the BaseTypes chart below.   BaseTypes   The table below provides information on the different types of properties that can be created in ThingWorx.   BaseType  Description TW_NOTHING An empty value. TW_STRING A modified UTF8 encoded string. Data and length are stored in val.bytes and val.len, respectively. The twPrimitive owns the data pointer and will free it when deleted. TW_STRING types are null terminated. TW_NUMBER A C double value, stored in val.double. TW_BOOLEAN Represented as a single char, stored in val.boolean. TW_DATETIME A DATETIME value, which is an unsigned 64 bit value representing milliseconds since the epoch 1/1/1970. Data is stored in val.datetime. TW_INFOTABLE A pointer to a complex structure (defined in the next section) and stored in val.infotable. The twPrimitive owns this pointer and will free up the memory pointed to when the twPrimitive is deleted. TW_LOCATION A structure consisting of three double floating point values – longitude, latitude, and elevation. Stored as val.location. TW_BLOB A pointer to a character array. Data and length are stored in val.bytes and val.len, respectively. Differs from TW_STRING in that the array may contain nulls. The twPrimitive owns the data pointer and will free it when deleted. TW_IMAGE Identical to TW_BLOB except for the type difference. TW_INTEGER Assigned 4 by integral value. Stored as val.integer. TW_VARIANT Pointer to a structure that contain a type enum and a twPrimitive value. The pointer is stored as val.variant. The twPrimitive owns the pointer and will free the structure when deleted.   The following base types are all of the TW_STRING family and are stored similarly:   TW_XML,TW_JSON TW_QUERY TW_HYPERLINK TW_IMAGELINK TW_PASSWORD TW_HTML TW_TEXT TW_TAGS TW_GUID TW_THINGNAME TW_THINGSHAPENAME TW_THINGTEMPLATENAME TW_DATASHAPENAME TW_MASHUPNAME TW_MENUNAME TW_BASETYPENAME TW_USERNAME TW_GROUPNAME TW_CATEGORYNAME TW_STATEDEFINITIONNAME TW_STYLEDEFINITIONNAME TW_MODELTAGVOCABULARYNAME TW_DATATAGVOCABULARYNAME TW_NETWORKNAME TW_MEDIAENTITYNAME TW_APPLICATIONKEYNAME TW_LOCALIZATIONTABLENAME TW_ORGANIZATIONNAME   Aspects   Aspects define the ways to interact with a property. The table below provides information on details that make up the Aspects attribute of a property.   Attribute Macro Description isPersistent TW_ASPECT_ISPERSISTENT Set to TRUE for the ThingWorx server to persist the value even if it restarts. It is extremely expensive to have persistent values, so it is recommended to set this value to FALSE unless absolutely necessary. isReadOnly TW_ASPECT_ISREADONLY Set to TRUE to inform the ThingWorx server that this value is only readable and cannot be changed by a request from the server. dataChangeType TW_ASPECT_DATACHANGETYPE Describes how the ThingWorx server responds when the value changes in the client application. Subscriptions to these value changes can be modeled in ThingWorx Platform. If nothing needs to react to the property change, set this value to NEVER. dataChangeThreshold TW_ASPECT_DATACHANGETHRESHOLD Defines how much the value must change to trigger a change event. For example 0 (zero) indicates that any change triggers an event. A value of 10 (ten) for example would not trigger an update unless the value changed by an amount greater than or equal to 10. defaultValue TW_ASPECT_DEFAULT_VALUE The default value is the value that ThingWorx Platform uses when the RemoteThing connected to the device first starts up and has not received an update from the device. The value is different based on the different value for each base type. cacheTime N/A The amount of time that ThingWorx Platform caches the value before reading it again. A value of -1 informs the server that the client application always sends its value and the server should never go and get it. A value of 0 (zero) indicates that every time the server uses the value, it should go and get it from the client application. Any other positive value indicates that the server caches the value for that many seconds and then retrieves it from the client application only after that time expired. pushType TW_ASPECT_PUSHTYPE Informs ThingWorx Platform how the client application pushes its values to the server.   NOTE: cacheTime and dataChangeThreshold are for subscribed (bound) properties ONLY.   DataChangeType Values   This field acts as the default value for the data change type field of the property when it is added to the remote Thing. The possible dataChangeType values are below:   Value Description ALWAYS Always notify of the value change even if the new value is the same as the last reported value. VALUE Only notify of a change when a newly reported value is different than its previous value. ON For BOOLEAN types, notify only when the value is true. OFF For BOOLEAN types only, notify when the value is false. NEVER Ignore all changes to this value.   PushType Values   This aspect works in conjunction with cacheTime. The possible pushType values are below:   Value Description ALWAYS Send updates even if the value has not changed. It is common to use a cacheTime setting of -1 in this case. VALUE Send updates only when the value changes. It is common to use a cacheTime setting of -1 in this case. NEVER Never send the value, which indicates that ThingWorx server only writes to this value.It is common to use a cacheTime setting of 0 or greater in this case. DEADBAND Added to support KEPServer, this push type is an absolute deadband (no percentages). It provides a cumulative threshold, such that the Edge device should send an update if its current data point exceeds Threshold compared to the last value sent to ThingWorx Platform. It follows existing threshold fields limits.   With Macros   The C SDK provides a list of macros to help make development easier and faster.   The macros TW_PROPERTY and TW_PROPERTY_LONG define a property of a Thing. This macro must be preceeded by either TW_DECLARE_SHAPE,TW_DECLARE_TEMPLATE or TW_MAKE_THING macros because these macros declare variables used by the property that follow them. The functions return TW_OK on success, {TW_NULL_OR_INVALID_API_SINGLETON,TW_ERROR_ALLOCATING_MEMORY,TW_INVALID_PARAM,TW_ERROR_ITEM_EXISTS} on failure.   NOTE: The macros are defined in the file, twMacros.h.   This example shows how to utilize these functions:   TW_MAKE_THING(thingName,TW_THING_TEMPLATE_GENERIC); TW_PROPERTY("Pressure", TW_NO_DESCRIPTION, TW_NUMBER); TW_ADD_BOOLEAN_ASPECT("Pressure", TW_ASPECT_ISREADONLY,TRUE); TW_ADD_BOOLEAN_ASPECT("Pressure", TW_ASPECT_ISLOGGED,TRUE); TW_PROPERTY("Temperature", TW_NO_DESCRIPTION, TW_NUMBER); TW_ADD_BOOLEAN_ASPECT("Temperature", TW_ASPECT_ISREADONLY,TRUE); TW_ADD_BOOLEAN_ASPECT("Pressure", TW_ASPECT_ISLOGGED,TRUE); TW_PROPERTY("TemperatureLimit", TW_NO_DESCRIPTION, TW_NUMBER); TW_ADD_NUMBER_ASPECT("TemperatureLimit", TW_ASPECT_DEFAULT_VALUE,320.0); TW_PROPERTY("Location", TW_NO_DESCRIPTION, TW_LOCATION); TW_ADD_BOOLEAN_ASPECT("Location", TW_ASPECT_ISREADONLY,TRUE); TW_PROPERTY("Logfile", TW_NO_DESCRIPTION, TW_STRING); TW_ADD_BOOLEAN_ASPECT("Logfile", TW_ASPECT_ISREADONLY,TRUE);   NOTE: TW_PROPERTY_LONG performs the same actions as TW_PROPERTY, except that it offers more options. When using TW_PROPERTY to declare a property you are accepting the use of the default property handler. This property handler will allocate and manage the storage used for this property automatically.   Without Macros   Property values can be set with defaults using the aspects setting. Setting a default value in the client will affect the property in the ThingWorx platform after binding. It will not set a local value in the client application. Two types of structures are used by the C SDK to define properties.   Structure Notes Code Property Definitions Describes the basic information for the properties that are going to be available to ThingWorx and can be added to a client application. twPropertyDef *property1 = twPropertyDef_Create(property, TW_BOOLEAN, "Description for Property1", "NEVER", 0); cJSON_AddStringToObject(tmp->aspects,"isReadOnly", "FALSE"); cJSON_AddStringToObject(tmp->aspects,"isPersistent", "FALSE"); cJSON_AddStringToObject(tmp->aspects,"isPersistent", "FALSE"); Property Values Associates the property name with a value, timestamp, and quality. twPrimitive * value = twPrimitive_CreateFromNumber(properties.TempProp); twProperty * tempProp = twProperty_Create("TempProperty", value, NULL);       Click here to view Part 7 of this guide

    Use ThingWorx Advisors to view trends and monitor Alerts.     GUIDE CONCEPT   The intent of this guide is to provide instructions to configure trends and alerts in the ThingWorx Advisors.   NOTE: This guide's content aligns with ThingWorx 9.3. The estimated time to complete all parts of this guide is 30 minutes.     YOU'LL LEARN HOW TO   In this guide, you will learn how to: Configure and view trends in machine performance Create and configure an alert Monitor an alert   Step 1: Configure and View Trends  To begin, you will learn how to open up ThingWorx Advisors.   In ThingWorx Foundation Composer, click Browse then Visualization > Master then click PTC.Factory.PlantStatus.Master.          2. Next click the View Mashup button.                 3. Click the Utility Selector grid in the upper left            4. Click Trending and Troubleshooting              5. Click the + icon.               NOTE : A New Trend pop-up will appear.        6. In the Trend Name text box, type Station A Temperature, then click OK.              7. In the Tags area, click the + icon to start plotting a tag             8. In the Equipment Type drop-down, choose KEPServerEX, in the Equipment drop-down,        choose your KEPServer or the simulation server.          9. In the Server Structure menu, click LineGroup1 and use the drop-down menu to select LineGroup1.1-3_CNCMill. In the Tags menu area, click Temperature then click OK, or choose a tag based on your KepServer configuration.   10. Review the trend data for Station A.     11.  Repeat these steps to apply additional property setting to Station A.   12. Check the Show Value Range box in the Tags area. Review the trend data for the properties selected.                      NOTE: The three selected tags will appear plotted in the Show Value Range table.     Click here to view Part 2 of the guide.  

    Step 7: C - Entities and Functions   All SDKs require a RemoteThing be created in ThingWorx in order to communicate. If many Things are to be created with the same properties, services, and events, we recommend that a Thing Template be derived from one of the supplied RemoteThing templates.   NOTE: The macros are all defined in the twMacros.h header file.   Define ThingShape   ThingShapes are used in the ThingWorx object-oriented Data Model and used to create Things later on. In order to create a ThingShape, you can do so with the provided macros. In order to define a ThingShapes using a macro, you will use TW_DECLARE_SHAPE or TW_SHAPE. TW_DECLARE_SHAPE("SteamLocation","Address Shape","UniqueNameSpace");   Define ThingTemplate   ThingTemplates are used in the ThingWorx object oriented Data Model and used to create Things later on. In order to create a ThingTemplate, you can do so with the provided macros. In order to define a ThingTemplate using a macro, you will use TW_DECLARE_TEMPLATE or TW_TEMPLATE. TW_DECLARE_TEMPLATE("SteamLocationTemplate",TW_THING_TEMPLATE_GENERIC,"UniqueNameSpace");   Define Thing   Things are used in the Data Model and a staple in IoT development. In order to create a Thing, you can do so with the provided macros or functions.   Function Example In order to define a Thing with a macro, you will use TW_MAKE_THING. TW_MAKE_THING("SteamSensor", TW_THING_TEMPLATE_GENERIC); In order to define a Thing without using a macro, you will use the twExt_CreateThingFromTemplate function. twExt_CreateThingFromTemplate("SteamSensor","WarehouseTemplate", "SimpleShape", "AddressShape","InventoryShape",NULL);   Register Functions   ThingWorx provides functionality for a Thing to be bound or connected to the server. Function Notes twExt_RegisterPolledTemplateFunction Register a function to be called periodically after this Thing has been created twApi_RegisterSynchronizeStateEventCallback Called after binding to notify your application about what fields are bound on the server. Will also be called each time bindings on a Thing are edited. twApi_RegisterBindEventCallback Runs whenever a Thing is bound or unbound.   Bind & Subscribe   You will use the TW_BIND macro or the twApi_BindThing function with the Thing name provided as a parameter. The documentation can be found in [C SDK HOME DIR]/src/api/twMacro.h and [C SDK HOME DIR]/src/api/twApi.h respectfully.   NOTE: Registered properties are bound or subscribed after they have been registered.   Bind Callbacks   You may want to track exactly when your edge entities are successfully bound to or unbound from ThingWorx Core. The reason for this is that only bound items should be interacting with ThingWorx Core and it will never forward a request to a corresponding remote thing in its database when the request is targeted at an entity that is not bound. Call the twApi_RegisterBindEventCallback() function to register your bind callback function as seen below with a function we later define called BindEventHandler:   To learn about a specific bound Thing (ie, SteamSensor): twApi_RegisterBindEventCallback("SteamSensor", BindEventHandler, NULL);   To learn about all bound Things, leave the first parameter null: twApi_RegisterBindEventCallback(NULL, BindEventHandler, NULL An example of the function is below: void BindEventHandler(char *entityName, char isBound, void *userdata) { if (isBound) TW_LOG(TW_FORCE,"bindEventHandler: Entity %s was Bound", entityName); else TW_LOG(TW_FORCE,"bindEventHandler: Entity %s was Unbound", entityName); }   Create Tasks   The SDK contains a tasker framework that you can use to call functions repeatedly at a set interval. You can use the tasker to drive both the connectivity layer of your application and the functionality of your application. However, using the tasker is optional.   NOTE: The built-in tasker is a simple round-robin execution engine that will call all registered functions at a rate defined when those functions are registered. If using a multitasking or multi-threaded environment you may want to disable the tasker and use the native environment. If you choose to disable the tasker, you must call twApi_TaskerFunction() and twMessageHandler_msgHandlerTask() on a regular basis (every 5 milliseconds or so). Un-define this setting if you are using your own threads to drive the API, as you do not want the tasker running in parallel with another thread running the API.   To properly initialize the tasker, you must define ENABLE_TASKER: #define ENABLE_TASKER 1 An example of a data collection task is seen below: /*************** Data Collection Task ****************/ /* This function gets called at the rate defined in the task creation. The SDK has a simple cooperative multitasker, so the function cannot infinitely loop. Use of a task like this is optional and not required in a multithreaded environment where this functionality could be provided in a separate thread. */ #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("msg", msg, TRUE); twApi_FireEvent(TW_THING, thingName, "SteamSensorFault", faultData, -1, TRUE); twInfoTable_Delete(faultData); } /* Update the properties on the server */ sendPropertyUpdate(); }   NOTE: The Windows-based operating systems have a tick resolution (15ms) that is higher than the tick resolutions requested by the C SDK (5ms).       Click here to view Part 6 of this guide  

    Step 13: C - Support Other Platforms   If you are using a platform that is different than the options provided in the CMake configurations or in the C SDK configurations, you can add your own computer type.   CMake has its own custom toolchain support that enables you to add your computer to the CMake configurations.   Go to the CMake Toolchain. NOTE: The C SDK provides a CMakeList.txt file that contains the setup instructions for the C SDK. Make changes only if you have verified the configurations and compiler information. Create a CMakeList.txt file based on your OS inside the folder in which you would like to setup your application. Modify the Platform Configuration section of the CMakeList.txt file to add your personal computer architecture if it is not already listed. Ensure your configurations are in your application's CMakeList.txt file.   An example of the Platform Configuration section is shown below. if (PLATFORM) if (${PLATFORM} MATCHES "linux-arm") set(OS "linux") set(ARCHITECTURE "arm") set(CMAKE_C_COMPILER ${CMAKE_CURRENT_SOURCE_DIR}/../TOOLS/gcc-linux-arm-cross/bin/arm-angstrom-linux-gnueabi-gcc) set(CMAKE_FIND_ROOT_PATH ${CMAKE_CURRENT_SOURCE_DIR}/../TOOLS/gcc-linux-arm-cross ${CMAKE_CURRENT_SOURCE_DIR}/../TOOLS/gcc-linux-arm-cross/arm-angstrom-linux-gnueabi) # Set LD_LIBRARY_PATH set(Env{LD_LIBRARY_PATH} "${CMAKE_FIND_ROOT_PATH}/lib/gcc") else () if (${CMAKE_SYSTEM_NAME} MATCHES "Linux") set(OS "linux") if (${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86_64" OR ${CMAKE_SYSTEM_PROCESSOR} MATCHES "AMD64") set(ARCHITECTURE "x86_64") set(PLATFORM "linux-x86-64") elseif (${CMAKE_SYSTEM_PROCESSOR} MATCHES "x86_32" OR ${CMAKE_SYSTEM_PROCESSOR} MATCHES "i[36]86") set(ARCHITECTURE "x86_32") set(PLATFORM "linux-x86-32") elseif (${CMAKE_SYSTEM_PROCESSOR} MATCHES "armv5tejl") set(ARCHITECTURE "arm") set(PLATFORM "linux-arm") elseif (${CMAKE_SYSTEM_PROCESSOR} MATCHES "armv[67]l") set(ARCHITECTURE "arm-hwfpu") set(PLATFORM "linux-arm-hwfpu") else () # default to linux-x86_64 set(ARCHITECTURE "x86_64") set(PLATFORM "linux-x86-64") endif() endif ()   An example of how to work with your OS in your application's CMakeList.txt file is shown below: add_executable (SteamSensor src/main.c src/SteamThing.c) target_link_libraries (SteamSensor LINK_PUBLIC twCSdk) if (${OS} MATCHES "windows") add_custom_command(TARGET SteamSensor POST_BUILD COMMAND cmake -E copy_if_different "${CMAKE_BINARY_DIR}/$<CONFIGURATION>/twCSdk.dll" "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIGURATION>/twCSdk.dll" COMMENT "Copying C SDK dll to example directory.") if (${TLS_LIB} MATCHES "openssl") # Copy over openssl dll files add_custom_command(TARGET SteamSensor POST_BUILD COMMAND cmake -E copy_if_different "${OPENSSL_SSLEAY_BIN_PATH}" "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIGURATION>/ssleay32.dll" COMMENT "Copying ssleay dll to example directory.") add_custom_command(TARGET SteamSensor POST_BUILD COMMAND cmake -E copy_if_different "${OPENSSL_LIBEAY_BIN_PATH}" "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIGURATION>/libeay32.dll" COMMENT "Copying ssleay dll to example directory.") endif () endif () if (${OS} MATCHES "linux") if (${TLS_LIB} MATCHES "openssl") # Copy over openssl libraries. add_custom_command(TARGET SteamSensor POST_BUILD COMMAND cmake -E copy_if_different "${OPENSSL_LIB_DIR}/libcrypto.so.1.0.0" "${CMAKE_CURRENT_BINARY_DIR}" COMMAND cmake -E copy_if_different "${OPENSSL_LIB_DIR}/libssl.so.1.0.0" "${CMAKE_CURRENT_BINARY_DIR}" COMMENT "Copying openssl to test directory.") endif () endif () if (${OS} MATCHES "macos") if (${TLS_LIB} MATCHES "openssl") # Copy over openssl libraries. add_custom_command(TARGET SteamSensor POST_BUILD COMMAND cmake -E copy_if_different "${OPENSSL_LIB_DIR}/libcrypto.1.0.0.dylib" "${CMAKE_CURRENT_BINARY_DIR}" COMMAND cmake -E copy_if_different "${OPENSSL_LIB_DIR}/libssl.1.0.0.dylib" "${CMAKE_CURRENT_BINARY_DIR}" COMMENT "Copying openssl to test directory.") endif () endif()     Step 14: Next Steps   Congratulations! You've successfully completed the SDK Reference Guide.   This guide is designed to be used as a reference when developing your application with one of the ThingWorx SDKs.   Learn More   We recommend the following resources to continue your learning experience:   Capability Guide Build Design Your Data Model   Additional Resources   If you have questions, issues, or need additional information, refer to: Resource Link   Community Developer Community Forum   Support C SDK Help Center Java SDK Help Center

    Step 2: Java Properties   In the ThingWorx environment, a Property represents a data point, which has a:   Name Value Timestamp Quality (optional)   Define Properties   You can define attributes, base types and other aspects of ThingWorx properties.   Attributes   The table below provides information on the different attributes that are used to define a property. Attribute Details name Specifies the name of the property that will appear in ThingWorx when users browse to bind the related Thing. description Provides additional information for the property. baseType Specifies the type of the property. For a list of base types supported by the SDK, refer to the BaseTypes chart below.   BaseTypes   The table below provides information on the different types of properties that can be created in ThingWorx. BaseType Primitive Description BOOLEAN BooleanPrimitive True or false values only DATETIME DatetimePrimitive Date and time value GROUPNAME StringPrimitive ThingWorx group name HTML StringPrimitive HTML value HYPERLINK StringPrimitve Hyperlink value IMAGE ImagePrimitive Image value IMAGELINK StringPrimitive Image link value INFOTABLE InfoTablePrimitive ThingWorx infotable INTEGER IntegerPrimitive 32–bit integer value JSON JSONPrimitive JSON structure LOCATION LocationPrimitive ThingWorx location structure MASHUPNAME StringPrimitive ThingWorx Mashup name MENUNAME StringPrimitive ThingWorx menu name NOTHING N/A No type (used for services to define void result) NUMBER NumberPrimitive Double precision value STRING StringPrimitive String value QUERY N/A ThingWorx query structure TEXT StringPrimitive Text value THINGNAME StringPrimitive ThingWorx Thing name USERNAME StringPrimitive ThingWorx user name XML XMLPrimitive XML structure   Aspects   Aspects define the ways to interact with a property. The table below provides information on frequently used Aspect attributes of a property. Attribute Description isPersistent Set to TRUE for the ThingWorx server to persist the value even if it restarts. It is extremely expensive to have persistent values, so it is recommended to set this value to FALSE unless absolutely necessary. isReadOnly Set to TRUE to inform the ThingWorx server that this value is only readable and cannot be changed by a request from the server. dataChangeType Describes how the ThingWorx server responds when the value changes in the client application. Subscriptions to these value changes can be modeled in ThingWorx Core. If nothing needs to react to the property change, set this value to NEVER. dataChangeThreshold Defines how much the value must change to trigger a change event. For example 0 (zero) indicates that any change triggers an event. A value of 10 (ten) for example would not trigger an update unless the value changed by an amount greater than or equal to 10. defaultValue The default value is the value that ThingWorx Core uses when the RemoteThing connected to the device first starts up and has not received an update from the device. The value is different based on the different value for each base type. cacheTime The amount of time that ThingWorx Core caches the value before reading it again. A value of -1 informs the server that the client application always sends its value and the server should never go and get it. A value of 0 (zero) indicates that every time the server uses the value, it should go and get it from the client application. Any other positive value indicates that the server caches the value for that many seconds and then retrieves it from the client application only after that time expired. pushType Informs ThingWorx Core how the client application pushes its values to the server.   NOTE: cacheTime and dataChangeThreshold are for subscribed (bound) properties ONLY.   DataChangeType Values   This field acts as the default value for the data change type field of the property when it is added to the remote Thing. The possible dataChangeType values are below: Value Description  ALWAYS Always notify of the value change even if the new value is the same as the last reported value. VALUE Only notify of a change when a newly reported value is different than its previous value. ON For BOOLEAN types, notify only when the value is true. OFF For BOOLEAN types only, notify when the value is false. NEVER Ignore all changes to this value.   PushType Values   This aspect works in conjunction with cacheTime. The possible pushType values are below: Value Description ALWAYS Send updates even if the value has not changed. It is common to use a cacheTime setting of -1 in this case. VALUE Send updates only when the value changes. It is common to use a cacheTime setting of -1 in this case. NEVER Never send the value, which indicates that ThingWorx server only writes to this value.It is common to use a cacheTime setting of 0 or greater in this case. DEADBAND Added to support KEPServer, this push type is an absolute deadband (no percentages). It provides a cumulative threshold, such that the Edge device should send an update if its current data point exceeds Threshold compared to the last value sent to ThingWorx Core. It follows existing threshold fields limits.     Click here to view Part 3 of this guide.