In this section, we use the IzoT resource file editor to accomplish the following tasks:

• Create a UNVT to extend the definition of an existing standard type.
• Create a new functional profile type based on an existing functional profile.

Creating a UNVT and a New Functional Profile Type

1. Launch the IzoT Resource File Editor. 
   
   
2. If you cannot find the ApolloDev resource file set in the tree, go to Selecting a Profile to add the resource fileset.
   
   
3. It is bad practice to change resources of another company.  If you make a change and build on that change, your definitions may become broken when that Manufacture makes a change to the resources.  To do this right, you need to apply for a Manufacture ID with the LonMark Organization.  Follow this link: Temporary Manufacturer ID (MID) Request.  It is not required to have an MID to continue this exercise.
   
   
4. In this exercise we will assume our company, ControlWorks Inc, has been assigned F8801 by LonMark.
   
   
5. In the IzoT Resource file editor, right click the root of the tree and select Add Directory, and Use the dialog to create a folder C:\Users\Public\Documents\LonWorks\Types as shown in the following screenshot.
   
6. In the device resource tree, select the ApolloDev resource set, and right-click to select Copy to target this set for copying.
   
7. Select the folder created in step 5 above, and right-click to select Paste, as shown in the screenshot below.
   
8. In the following dialog we rename the files to myApolloDev, and assigning the fictional MID of F8801.  If you click the Calculator button, you will see how the CCCC portion of the Program ID is coded.  0600 is used to specify the device class "Generic Controllers".
   
9. Many devices used in the buildings temperature control application include a network variable based on SNVT_hvac_status.  To get a complete view of the conditions in the zone, the space comfort controller would also include variables that report temperature, the effective set point, and the occupancy state.  Let's define a UNVT_hvac_status_plus.  Inside the myApolloDev resource set, click the Network Variable Types node and right-click to select  Add NVT.   
   
10. This new NVT needs a name (UNVT_hvac_status_plus) and needs to be based on a structure.
    
11. Next we add fields to the structure that reference existing standard types.  Select the typedef in the Data type pane, right-click and select Add, then add a field named status, and reference the standard type SNVT_hvac_status.
    
12. Continue this process of adding fields until your Data type definition matches what you see in the following screenshot.  With our type UNVT_hvac_status_plus, we can express the state of zone completely with a single update on the wire.  Because it is based on standard type references, the code required to implement this type is straightforward with these values likely already exposed as network variables base on scalar types.
    
13. Next it's time to find the functional profile to build on.  This is the likely path for a device developer focused on creating a Lonworks based controller.  If you are building an Internal application for the SmartServer, you might build a function profile from scratch.  In the IzoT Resource File editor, drill down the Standard resources tree to find the SFPTsccVAV functional profile.  Select it and right-click to select Copy.
    
14. Now navigate to the Functional Profile Templates folder of the myApolloDev resources to right-click and Paste the copy you just made.  The result is shown in the following screenshot:
    
15. Now we will add our newly defined UNVT_hvac_status_plus type to this functional profile.  You need to choose to add the types to the Optional or Mandatory interface for this UFPT.  There is some efficiency to having it in the mandatory interface so that is what we will do.  Double-click the UFPTsccVAV controller to inspect its details.
    
16. In the left most pane are the resources that are available to this functional profile.  The first node is the Standard resources scope level 0 that are available to all program IDs.  The second node represents the myApolloDev resources that we are developing in this exercise.  Drill down until you see UNVT_hvac_status_plus that we have just defined.  Drag this node to the Mandtory NVs folder in the next pane, and name the network variable nvoStatusPlus.  Take note of the highlight fields that were modified when adding the network variable to the interface.  Because this variable typically repeats as conditions change, and the changes are continuous in nature, making the recommended service type as Unacknowledged is a sensible use of network bandwidth.  Of course the device implementation will need to consider throttling updates to this variable.  Consider a system with 40 such devices connected to the SmartServer IoT to monitor the zones.  A throttle limiting the update rate to 30-60 seconds would be good practice.  40 devices reporting each 0.05% change in cooling or heating output would consume quite a bit of network bandwidth.  Click OK to commit the addition of this output network variable.
    
17. Now we have made changes to our myApolloDev resources that include adding resources, it is a best practice to set the version.  Select the myApolloDev node in the tree and right-click to execute Set Version to the version. 
    
18. You can develop your own rule to what constitutes the change of the major or minor version, but whenever you publish the resources for use by other tools, a bump of one of these fields is a best practice. We have added a type, a functional profile, and likely modified the language files so we are bumping the versions of each of these files in the resource file set.  It is generally best to move all versions together because the files in a resource file set usually travel together between systems.
    
19. Now it's time to publish the changes.  Select the myApolloDev node, right-click and select Generate Resource Files.
    
20. Click Yes to generate the files for version 1.01 of myApolloDev resources.
    

Next Step

You have just completed an exercise that touches the major activities associated with managing device resource files.  You are doing this work to support clean strongly typed information about devices you create.  In the current form, IzoT CT and Open LNS based tools can use the resource type files to surface the data and configuration device interfaces reference types and profiles in the myApolloDev resource file set.  SmartServer IoT, and the Interface Integration Interpreter tool need the resources in a different format.  In the next section, we will use the IzoT Resource File Editor to generate these formats. 

Go to: Resource Report Generation.