Creating an XIF for an Internal LON App

In this section, an XIF file is created for the Internal App that monitors VAV cooling demand to establish the required duct static pressure set point to optimize energy usage.  In this example, you are creating an application to control the nviDuctStaticSP (SNVT_press_p). If you have not done so yet, use git to clone the following github repo: https://github.com/izot/smartserver-iot

To support this application, the IzoT Resource Editor was used to define the functional profile UFPTDspSPcontroller within the ApolloDev resource file.  At this point, you should already have the ApolloDev resources installed on your computer and visible in the Resource catalog using the IzoT Resource Editor.  (If the ApolloDev resource set is not in your Resource catalog, follow the steps described under Selecting a Profile.)

In the IzoT Resource Editor, drill down to the Functional Profiles folder of the ApolloDev resources, and double click the UFPTDspSPcontroller node to see the details of this functional profile. 

Please spend some time reviewing each network variable and configuration property defined for this functional profile.  You should note how the Comment field is used to describe each network variable. For configuration properties, default, minimum, and maximum values can be defined. For example, it is important to limit the duct static pressure below 1000 Pascal to avoid conditions that may damage the duct work.

Defining your own functional profile in the IzoT Resource Editor is straight forward, but not needed now because the UFPTDspSPcontroller is already in the system.

If you have followed this example in order, there are several things that are prepared for you in advance. The folders shown in the following screenshot are part of the example linked above, and are described in the table below.

Folder/File Name

Description

dspSPcontrollerThis folder contains a Node.js application developed as an internal application example.
Interface Dev

This folder contains IzoT target Resource reports and Input files for defining the XIF file for the internal LON App.

Internal App Evb FIles

The folder contains XIF, APB, and NDL image files for FT 5000 and 6050 Evaluation boards. It is typically used to load the example applications before the exercise is started.

SmartServer Support

The files in this folder are imported using the SmartServer IoT CMS.  They represent the target simulation nodes and the internal App node being developed.

DspSPControllerExample.dtp

This is the complete package file for the internal application example defining the Internal device, as well as the devices emulating devices in the simulated network.

Follow these steps to create an XIF file for this application example:

  1. In Windows File Explorer, navigate to the folder ../smartserver-iot/apps/Dsp SP Controller Example/Interface Dev.

  2. Open the DspSPcontroller.c interface model to inspect  it.  The contents are shown below.

    DspSpController Model file - DspSpController.c
    /*
     * Interface definition using IML to define the Internal Application Example interface.
     * This file is the input to the iii.exe application, to produce aN XIF file. You need
     * to place the ApolloDev.* resouce files in a location that matches the location
     * in the IML belowUDPTDspSPcontroller. 
     * *** Note iii.exe 1.30.009 or higher is required ***
     */
    //@Izot option target("xif")
    //@Izot option programId("90:00:01:06:00:03:85:00")
    //@IzoT option dynamic(blocks=0, datapoints=0) 
    //@IzoT option addresses(15)
    //@IzoT option aliases(15)
    
    UFPTDspSPcontroller(DspCntl) DspCntl; //@Izot block (location="./P9000010600000000_4") external("SpController") 
  3. This file uses the IzoT Markup Language (IML) to simplify the definition of this interface.  Complete details for IML are found here: IzoT Markup Language.  What you need to understand is as follows;
    1. //@Izot is the tag that starts a block of IML.

    2. Lines 7-8 are common to all SmartServer IoT internal applications, and should be replicated verbatim in interfaces you design.

    3. Line 9 is your choice, according to the application you are building. The hex code bytes 90:00:01:06:00 should be part of applications that will target the apolloDev resources. The second to last hex coded byte (85) represents the channel ID for the device.  SmartServer Internal Apps use the internal IP-70 channel, so 85 is the correct value to use in all cases.

    4. The UFPT name UFPTDspSPcontroller at the start of line 11, calls out the functional profile detailed above in the ApolloDev resource file set.

    5. The location="./P900010600000000_4" option specifies the relative path to the IzoT targeted report that was generated and included in the Interface Dev folder.

    6. The last part of the IML defines the name that is used for this profile when exposed to users and other tools.  In this case, the user would see SpController instead of UFPTDspSPcontroller.

  4. In Windows File Explorer, type cmd in the address bar to make the folder Interface Dev the current working directory in a windows command window.

  5. At the Windows command prompt, type: iii DspSPcontroller.c and look for the result shown in the following screenshot.  The file dspcontrollersp.xif is the primary output of interest.  You now have an XIF file that describes the LON interface for the internal app under development.  


  6. The output file from iii.exe is the file dspspcontroller.xif. This XIF includes only a single functional block (SpController), which is a UFPT-defined ApolloAppDev resource file set. As a UFPT, the self-documentation string for a network variable (Lines 16, 21, and 26) needs to be re-formatted, where "@0| needs to be changed to "@0# for each network variable.

    The SpController UFPT is understood to be a UFPT because of the self-documentation string "&3.4@20004SpController (Line 12). The 20004 indicates a UFPT because it is greater than 20000.  

    DspSPccontroler.xif
    File: GroupController.xif 
    
    90:00:01:06:00:03:85:00
    2 15 1 15 0 5 3 3 2 4 4 11 11 11 11 3 0 1 15 1 1 11 15 0 0 3 193 16 0 0 0 0 2 15 0 0 0 0 0 2 1117 0 0 15 0
    115 0 0 13 28 0 0 15 5 3 175 4 10000000 0
    0 0 0 2 8 8 4 15 200 0
    4883 0 0 0 0 14 1 0 0 0 0 0
    0 0 0 0 0 0 0 0 1 0 0 63 166 119 103
    *
    "&3.4@20004SpController
    
    VAR nviAddRouge 0 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@0|7
    36 * 1
    4 0 31 0 0
    VAR nviEnable 1 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@0|1
    95 * 1
    4 0 2 0 0
    VAR nviRemoveRouge 2 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@0|8
    36 * 1
    4 0 31 0 0
    VAR nviShowRouge 3 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@0|9
    8 * 1
    4 0 2 0 0
    VAR nvoAvgDemand 4 0 0 0
    0 1 63 1 0 1 0 1 0 1 0 0 0
    "@0|5
    81 * 1
    4 0 2 0 0
    VAR nvoDspSP 5 0 0 0
    0 1 63 1 0 1 0 1 0 1 0 0 0
    "@0|2
    113 * 1
    4 0 2 0 0
    VAR nvoMaxDemand 6 0 0 0
    0 1 63 1 0 1 0 1 0 1 0 0 0
    "@0|3
    81 * 1
    4 0 2 0 0
    

    The code block example that follows shows a more complicated output from iii.exe. In this example, there is a nodeObject (SFPT, FB index 0) and 16 groupControllers (UFPT, FB index 1-16). In this output, the self-documentation strings for nviRequest and nviStatus do not need modification. All other network variable, self-documentation strings need to be changed as follows: beginning at line 22, all characters need to be replaced with #.

    General rule

    • If the network variable, self-documentation string is assigned to an SFPT, then the string should be "@[fb index]|[nv index].
    • If the network variable is assigned to a UFPT, then the string should be "@[fb index]#[nv index]
    GroupController.xif
    File: GroupController.xif
    
    80:00:01:1E:00:3F:85:21
    2 15 1 338 0 5 3 3 2 4 4 7 7 7 7 3 0 1 32 1 1 11 338 0 1 3 193 16 0 0 0 0 2 32 0 0 0 0 0 2 1629 0 0 15 0
    115 0 0 13 28 0 0 15 5 3 175 4 10000000 0
    0 0 0 2 8 8 4 15 200 0
    4883 0 0 0 0 14 1 0 0 0 0 0
    0 0 0 0 0 0 0 0 1 0 0 63 166 119 103
    *
    "&3.4@0nodeObject,20013[16groupController
    
    VAR nviRequest 0 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@0|1
    92 * 1
    4 0 3 0 0
    VAR nvoStatus 1 0 0 0
    0 1 63 1 0 1 0 1 0 1 0 0 0
    "@0|2
    93 * 1
    4 0 6 0 0
    VAR nviAutoMan_1 2 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@1#6
    95 * 1
    4 0 2 0 0
    VAR cpAutoManSrc_1 3 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&2,2,4\x80,11
    0 * 1
    4 0 1 0 0
    VAR nviLowLuxSw_1 4 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@1|9
    95 * 1
    4 0 2 0 0
    VAR cpLuxOvrdSc_1 5 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&2,4,4\x80,26
    0 * 1
    4 0 1 0 0
    VAR nviLuxLevel_1 6 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@1|10
    79 * 1
    4 0 2 0 0
    VAR nviManLevel_1 7 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@1|5
    95 * 1
    4 0 2 0 0
    VAR cpManlLevSrc_1 8 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&2,7,4\x80,11
    0 * 1
    4 0 1 0 0
    VAR nviManScene_1 9 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@1|8
    0 * 1
    4 0 1 0 0
    VAR nviSchedSw_1 10 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@1|1
    95 * 1
    4 0 2 0 0
    VAR nviSchedSw2_1 11 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@1|2
    189 * 1
    4 0 3 0 0
    VAR nvoCntrlSw_1 12 0 0 0
    0 1 63 1 0 1 0 1 0 1 0 0 0
    "@1|3
    95 * 1
    4 0 2 0 0
    VAR nvoCntrlSw2_1 13 0 0 0
    0 1 63 1 0 1 0 1 0 1 0 0 0
    "@1|4
    189 * 1
    4 0 3 0 0
    VAR nvoOvrdState_1 14 0 0 0
    0 1 63 1 0 1 0 1 0 1 0 0 0
    "@1|7
    0 * 1
    4 0 1 0 0
    VAR cpDuskSrc_1 15 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&1,1,4\x80,9
    0 * 1
    4 0 1 0 0
    VAR cpLuxSp_1 16 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&1,1,0\x80,82
    79 * 1
    4 0 2 0 0
    VAR cpOffDlyTm_1 17 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&1,1,4\x80,33
    107 * 1
    4 0 2 0 0
    VAR cpOvrdDur_1 18 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&1,1,4\x80,12
    0 * 1
    4 0 3 0 0
    VAR cpOvrdLevel_1 19 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&1,1,4\x80,13
    21 * 1
    4 0 1 0 0
    VAR cpOvrdScene_1 20 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&1,1,4\x80,26
    0 * 1
    4 0 1 0 0
    VAR cpOvrdStTm_1 21 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&1,1,4\x80,5
    84 * 1
    4 0 7 0 0
    VAR cpSegtSwCfg_1 22 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&1,1,4\x80,32
    0 * 1
    4 0 1 0 0
    VAR nviAutoMan_2 23 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@2|6
    95 * 1
    4 0 2 0 0
    VAR cpAutoManSrc_2 24 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&2,23,4\x80,11
    0 * 1
    4 0 1 0 0
    VAR nviLowLuxSw_2 25 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@2|9
    95 * 1
    4 0 2 0 0
    VAR cpLuxOvrdSc_2 26 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&2,25,4\x80,26
    0 * 1
    4 0 1 0 0
    VAR nviLuxLevel_2 27 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@2|10
    79 * 1
    4 0 2 0 0
    VAR nviManLevel_2 28 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@2|5
    95 * 1
    4 0 2 0 0
    VAR cpManlLevSrc_2 29 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 1
    "&2,28,4\x80,11
    0 * 1
    4 0 1 0 0
    VAR nviManScene_2 30 0 0 0
    0 1 63 0 0 1 0 1 0 1 0 0 0
    "@2|8
    0 * 1
    4 0 1 0 0
    
    

Next Step

Return to Creating a Custom LON App.