ISI Programmer’s Guide Version 3 078-0299-01F
Echelon, LONWORKS, Neuron, NodeBuilder, LonMaker, 3120, 3150, and the Echelon logo are trademarks of Echelon Corporation registered in the United States and other countries. 3170 is a trademark of Echelon Corporation. Other brand and product names are trademarks or registered trademarks of their respective holders.
Introduction This guide describes how you can use Interoperable SelfInstallation (ISI) to create networks of control devices that interoperate, without requiring the use of an installation tool. This guide also describes how to use Echelon’s ISI Library to develop devices that can be used in both selfinstalled as well as managed networks. This guide refers to version 3.01 of Echelon’s ISI Libraries.
Overview Control networks consist of intelligent devices like switches, thermostats, pumps, motors, valves, controllers, and a variety of other sensors and actuators that communicate with each other to provide distributed monitoring and control. A control network may be a small, simple network consisting of a few devices; may be a large network in a building, factory, or ship consisting of tens of thousands of devices; or may even be a very large regional network consisting of millions of devices.
This guide presents a library for Neuron® C—called the Neuron C ISI library—to create interoperable self-installed devices. This library implements the ISI protocol. This guide details the application programming interface (API) that you will use to interact with the ISI library. For a detailed description of the ISI protocol, see the LONWORKS ISI Protocol Specification.
Table of Contents Introduction........................................................................................................................... 1 Overview ............................................................................................................... 2 Changes since Revision 2 .................................................................................... 3 Table of Contents .................................................................................................
Self-Installation Advanced Procedures .............................................................................. 61 Overriding a Callback Function........................................................................ 62 Forwarders ......................................................................................................... 65 Assembly Number Allocation ............................................................................ 67 Supporting Compound Assembly Connections ..................
IsiDiagnostic Enumeration ............................................................................. 112 IsiDidcf Structure ............................................................................................ 113 IsiDidrm Structure .......................................................................................... 113 IsiDidrq Structure............................................................................................ 114 IsiDirection Enumeration...................................
IsiGetConnection() ........................................................................................... 144 IsiGetConnectionTableSize()........................................................................... 144 IsiGetNextAssembly()...................................................................................... 145 IsiGetNextNvIndex()........................................................................................ 146 IsiGetNvIndex()....................................................
Installing ISI Devices ISI devices may support plug-and-play or plug-touch-and-play installation. For plug-and-play installation, installation is performed by plugging in the device. No user interaction is required in this case. This is suitable for devices where connections can be determined automatically. For example, all appliances in a home may automatically connect to a home gateway.
during development for capturing and interpreting ISI messages. The ISI Packet Monitor application is described in Developing and Debugging the ISI Implementation in Chapter 4. A few of the key ISI messages are introduced in this section. All of the ISI messages are described and documented in the ISI Protocol Specification. Following are a few of the most important ISI messages: • Device Resource Usage Message (DRUM)—this message is periodically broadcast by all ISI devices.
increases the network bandwidth consumed for administrative ISI messages, possibly preventing regular network operation due to an increased collision rate. Networks should be designed with some headroom. A reasonable limit is 80%. ISI-S networks that reach 26 devices should be considered for an upgrade to ISIDA (which might be as simple as adding a DAS), and ISI-DA networks exceeding 160 devices are prime candidates for an upgrade to a managed LNS network.
ISI does not support redundant routers, and the user is responsible for avoiding looping topologies. The network topologies described in this section will not cause looping topologies. Connection Complexity A single device can join multiple connections; limited by available address, alias, and connection table space on the device.
When used in a self-installed network, an ISI device will typically only require one address table entry for each group it can join. Since the ISI application has complete control over the groups it might belong to (by means of the IsiGetAssembly(), IsiGetNextAssembly(), and IsiCreateCsmo() overrides), the maximum size address table can be determined by the application developer. This is not the case in a managed network, where a 15-entry address table is normally required for flexible use of a device.
Earshot Problems Open media such as power line may experience occasional communication outages due to interference from other power line devices or neighboring networks. In addition, an open media device may receive packets from devices using the same media in neighboring networks.
Limit Value Maximum number of selectors per assembly 63 Recommended maximum number of selectors per assembly 4 Notes ISI and Energy Storage Devices In simple devices, such as a light or a switch, a common implementation uses an energy storage power supply, as described in the PL 3120, PL 3150 and PL 3170 Power Line Smart Transceiver Data Book. A device using this type of power supply can be referred to as an energy storage device.
2 Quick Start This chapter provides a quick start for ISI developers. The source code for a simple ISI application is described. The code examples used in this document do not describe a complete application and are provided as example code only. Example code is not optimized for code size or performance. Any code used from this document should be tested with your application and you may be able to reduce code size by optimizing the code for your application. See the ISI Web page at www.echelon.
Example ISI Application Most of the ISI protocol is implemented by the ISI engine that is part of the ISI library, and much of the related application development is to make calls to the ISI engine’s API and override some of the ISI engine’s default implementations with application-specific versions. The ISI engine sends and receives ISI messages and manages the network configuration of your device.
3 Self-Installation Basic Procedures This chapter describes the basic ISI procedures that will be implemented by most ISI applications. Chapter 5 describes more advanced procedures. The functions described in this chapter are further described in Appendices B and C and the data structures used by these functions are documented in Appendix A.
Starting and Stopping Self-Installation void IsiPreStart(void); void IsiStart(IsiType Type, IsiFlags Flags); void IsiStartS(IsiFlags Flags); void IsiStartDA(IsiFlags Flags); void IsiStartDAS(IsiFlags Flags); void IsiStop(void); void IsiIsRunning(void); You can start and stop the ISI engine. The ISI engine sends and receives ISI messages and manages the network configuration of your device.
applies to your application’s Node Object functional block, if available, or applies to the entire device if there is no Node Object functional block. The configuration property has two values—CFG_LOCAL and CFG_EXTERNAL. When set to CFG_LOCAL, your application can enable self installation. When set to CFG_EXTERNAL, your application must disable self installation.
If your device supports a single ISI type, you can use one of the three specialized versions of the IsiTick() function to minimize the memory footprint of your application. The IsiTick() and IsiTickDas() functions are not supported for PL 3170 devices. EXAMPLE The following example calls the IsiTickS() function every 250ms: #include
EXAMPLE 1 The following example for a device without domain acquisition tests for incoming ISI messages, and calls IsiProcessMsgS() to process them: when (msg_arrives) { if (IsiApproveMsg() && IsiProcessMsgS()) { // TODO: process unprocessed ISI messages here (if any) } else { // TODO: process other application messages here (if any) } } EXAMPLE 2 The following partial DAS example tests for incoming ISI messages and responses on a domain address server.
not the domain address server. This method allows the device to make intelligent decisions about retries, preventing enrollment during the domain acquisition. It also allows the device to increase automatic enrollment performance following the completion of domain acquisition. 3. A domain address server can assign a domain to a device without a request from the device. This minimizes the code required in the device, and can be used with all devices. This process is called fetching a device. 4.
Key advantage Active process— device is in control of proceedings and aware of success or failure Passive process, supporting resourcerestricted device implementations Supports installation of replacement or redundant domain address servers Acquiring a Domain Address from a Domain Address Server To acquire a domain address from a domain address server, start the ISI engine using the IsiStartDA() function, or using the IsiStart() function with the isiTypeDa type.
Device DAS IsiStartDeviceAcquisition() enters device acquisition mode IsiAcquireDomain() starts domain acquisition and sends the DIDRQ domain request message Respond to the DIDRQ domain request message with a DIDRM domain response message Collect all domain response messages for 1.
EXAMPLE 1 The following example starts domain acquisition mode on a domain address server when the user presses a Connect button on the server: when (connect_button_pressed) { IsiStartDeviceAcquisition(); } Once started, the domain address server remains in this state for 5 minutes unless cancelled with an IsiCancelAcquisitionDas() call. Each successful device acquisition retriggers this timeout.
Device DAS IsiFetchDevice() starts device fetching Send Service Pin message Respond to Service Pin message by sending Wink message Respond to Wink message with suitable audible or visual feedback User confirms correct device selection by sending a second Service Pin message Respond to matching Service Pin message by assigning local domain to remote device EXAMPLE 3 The following example fetches a device on a domain address server when the user presses the Connect button on the server: when (connect_but
function to obtain the current domain ID from any device in the network, even from those that only implement ISI-S, or that do not implement or execute ISI at all. This is typically used when installing replacement or redundant domain address servers in a network: a domain address server will normally use the IsiGetPrimaryDid() override to specify a unique, non-standard, primary domain ID.
EXAMPLE 3 The following example fetches a domain on a domain address server when the user presses the Connect button on the server: when (connect_button_pressed) { IsiFetchDomain(); } //Handle responses to requests in IsiFetchDomain() when (resp_arrives) { if (IsiProcessResponse()) { // TODO: process unprocessed responses here (if any) } } If no unambiguous domain ID is already present on the network, the domain address server will use its default domain ID, as advised with the IsiGetPrimaryDid() callback,
A connection host opens enrollment by sending a connection invitation. Once a connection host opens enrollment then any number of devices may join the connection. Connections are created among connection assemblies. A connection assembly is a block of functionality, much like a functional block. A simple assembly refers to a single network variable: A connection assembly that consists of a single network variable is called a simple assembly.
the application. Standard ISI profiles that define multiple assemblies must specify the order the assemblies are to be assigned. Each assembly has a width which is typically equal to the number of network variables in the assembly. In the previous figures, for example, assembly 0 has a width of 1, assembly 1 typically has a width of 2, and assembly 2 typically has a width of 4. All assemblies must have a width of at least 1.
Opening Enrollment void IsiOpenEnrollment(unsigned Assembly); void IsiCreateCsmo(unsigned Assembly, IsiCsmoData* pCsmoData); unsigned IsiGetPrimaryGroup(unsigned Assembly); unsigned IsiGetWidth(unsigned Assembly); void IsiInitiateAutoEnrollment(const IsiCsmoData* pCsma, unsigned Assembly); void IsiUpdateUserInterface(IsiEvent Event, unsigned Parameter); You can create a connection using automatic, controlled, or manual enrollment.
function uses the IsiGetPrimaryGroup() function to obtain the associated group ID, and sets all fields to zero except the Application field (which is filled with data from the device’s program ID), the Width field (which is set by the value returned by IsiGetWidth()), the Direction field (which is set to isiDirectionAny), and the NvType field (which is set to the assembly’s primary network variable’s SNVT ID).
EXAMPLE 1 The following example opens automatic enrollment: void IsiUpdateUserInterface(IsiEvent Event, unsigned Parameter) { if (Event == isiWarm && !IsiIsConnected(MyAssembly)) { IsiInitiateAutoEnrollment(&MyCsmoData, MyAssembly); } } EXAMPLE 2 The following example opens manual enrollment for a simple assembly with one network variable, using the network variable’s global index as the application-specific assembly number: void startEnrollment(void) { unsigned myAssembly; myAssembly = nvoValue::global_in
} } EXAMPLE 4 The following example opens manual enrollment for a compound assembly with four selectors. The isiGetWidth() returns the library’s default value. In this example, enrollment is being opened in response to the user pressing a Connect button. Enrollment can only be opened when the ISI engine is in the normal state. The ProcessIsiButton() function is called in response to the Connect button being pressed: IsiEvent isiState; void IsiCreateCsmo(....
when (msg_arrives) { IsiMessage inMsg; unsigned myAssembly; if (IsiApproveMsg()) { memcpy(&inMsg, msg_in.data, sizeof(IsiMessage)); myAssembly = nvoValue::global_index; if (inMsg.Header.Code == isiCtrq) { if (inMsg.Ctrq.Control == isiOpen && inMsg.Ctrq.
ISI_DEFAULT_GROUP, isiDirectionVarious, 4, 3251, 0, 0 // // // // // // // // Group NV direction Width Profile number (3251 = SFPTsceneController) Network variable type index (0 = determined by SFPT) Variant (0 = standard) }; // Call InitiateAutoEnrollment in response to isiWarm void IsiUpdateUserInterface(IsiEvent Event, unsigned Parameter) { if (Event == isiWarm && !IsiIsConnected(myAssemblyNumber)) { // We waited long enough and we are not connected already, // so let's open an automatic connection: I
Applications need not distinguish between regular and extended incoming messages. You can provide feedback to the user when an invitation is received and provisionally approved, for example by causing a Connect light to flash while enrollment is open. This is typically only done with a manual connection.
Accepting a Connection Invitation void IsiCreateEnrollment(unsigned Assembly); void IsiExtendEnrollment(unsigned Assembly); For manual and controlled enrollment, you can accept a connection invitation to join the offered connection. When you accept a connection invitation, the ISI engine sends an enrollment acceptance message (CSME) to the connection host.
You can eliminate this additional resource usage by deleting and re-creating a connection instead of extending it. You can provide feedback to the user when an invitation is accepted, for example by changing the state of the Connect light from flashing to solid on when the connection invitation is accepted. This is typically only done with manual enrollment.
// drive the ISI-related LED: switch(isiState) { ... case isiApproved: case isiApprovedHost: SetConnectLed(LED_ON); break; ... } } EXAMPLE 2 The following example opens controlled enrollment for a simple assembly with one network variable and accepts the invitation when requested by the connection controller: void sendControlResponse(boolean success) { IsiMessage ctrlResp; ctrlResp.Header.Code = isiCtrp; ctrlResp.Ctrp.Success = success; memcpy(ctrlResp.Ctrp.NeuronID, read_only_data.
Implementing a Connection In a manual or controlled enrollment, when a connection host sends a connection invitation by broadcasting an open enrollment message, one or more devices may accept the connection invitation and respond with an enrollment acceptance message (CSME). When the host receives at least one CSME message, the host indicates this to the host’s application by calling the IsiUpdateUserInterface() callback function.
} // (CSME) message. IsiCreateEnrollment(Assembly); break; ...
IsiCreateEnrollment() or IsiExtendEnrollment()), or simply do nothing. The pending assembly remains pending until the enrollment is closed, and automatically returns to the isiNormal state. Deleting a Connection You can delete an implemented connection using one of three methods: • The device can restore factory defaults. To do so, call the IsiReturnToFactoryDefaults() function. This function clears all system tables, stops the ISI engine, and resets the device.
IsiEvent Value Note isiNormal 0 The ISI engine has returned to the normal, or idle, state for an assembly. The related assembly is encoded in the parameter; a parameter value of ISI_NO_ASSEMBLY indicates that the event applies to all assemblies. isiRun 1 The ISI engine has been successfully started (parameter = 1) or stopped (parameter = 0). isiPending 2 The connection related to the assembly given with the numerical parameter has entered the pending state.
IsiEvent Value isiWarm 7 Note The ISI engine has warmed up (i.e. a predetermined time with a random component has passed since the last reset). From this moment on, the application may call the IsiInitiateAutoEnrollment() function. This event occurs no sooner than the expiry of the Tauto ISI protocol timer, but may occur later. isiPendingHost 8 The connection related to the assembly given with the numerical parameter has entered the pending state.
The following figure summarizes the typical sequence of events for a connection host using manual or controlled enrollment. The sequence of events is similar for a connection host using automatic enrollment, except that the connection host will skip the isiApprovedHost event and go straight to the isiImplemented event. The sequence of events shown in this figure is typical—the actual sequence of events passed to the IsiUpdateUserInterface() callback may vary from this diagram.
You can get more detailed ISI diagnostic events. These events are useful for debugging ISI applications and are not typically used for production products. To receive notification of diagnostic events, enable diagnostics in the IsiStart() function by raising the isiFlagSupplyDiagnostics flag, and override the IsiUpdateDiagnostics() callback function. This callback is normally disabled and the default implementation of IsiUpdateDiagnostics() does nothing.
IsiDiagnostic Value Note isiSubnetNodeAllocation 1 A local subnet/node ID has been allocated. isiSubnetNodeDuplicate 2 A duplicate subnet/node ID has been detected. isiReceiveDrum 4 DRUM message received. isiReceiveTimg 5 TIMG message received. isiSendPeriodic 6 Periodic message other than an NV heartbeat message (see the isiSendHeartbeat event for these) sent. The parameter contains the ISI message code for the message sent.
EXAMPLE The following example deinstalls a device after the service pin is held for a long period: when (timer_expires(ServicePinHoldTimer)) { nciNetConfig = CFG_LOCAL; IsiReturnToFactoryDefaults(); } Recovering from a Programming Error The IsiReturnToFactoryDefaults() function described in the previous section assists with recovering from some programming errors. For example, you can safely remove incorrectly established connections with this tool.
Implementing a SCPTnwrkCnfg CP ISI applications must implement a SCPTnwrkCnfg configuration property that is implemented as a configuration network variable. This configuration property must apply to your application’s Node Object, if available, or apply to the entire device if there is no Node Object. This configuration property provides an interface for network tools to disable self-installation on an ISI device. This allows for the same device to be used in both self-installed and managed networks.
4 Quick Start, Revisited This chapter revisits the quick start example in Chapter 1 to add connection enrollment support and user feedback.
Here is the quick start example from Chapter 1: #include
void IsiUpdateUserInterface(IsiEvent event, unsigned parameter) { if (event == isiPending || event == isiPendingHost) { SetConnectLed(LED_BLINKING); } else if (event == isiApproved || event == isiApprovedHost) { SetConnectLed(LED_ON); } else { SetConnectLed(LED_OFF); } deviceState = event; } SetConnectLed() is a device-specific function that is defined elsewhere. The function sets the device’s LED into the three states mentioned above.
DeviceState Connection Host Response to Connect Button isiApprovedHost Yes An approved connection host is one that has received at least one connection enrollment acceptance message (CSME). Call IsiCreateEnrollment() or IsiExtendEnrollment() to implement the connection. Call IsiCancelEnrollment() to cancel the enrollment. isiApproved No An approved connection member is one that awaits a connection enrollment confirmation (CSMC) or cancellation (CSMX) message from the host.
case isiNormal: if (longPress) { IsiDeleteEnrollment(assembly); } else { IsiOpenEnrollment(assembly); } break; } } } With the refinements to the quick start example introduced above the resulting device will do the following: • Participate in and honor all ISI messages relating to the device’s subnet/node address.
ISI Programmer’s Guide 56
5 Developing and Debugging an ISI Application This chapter describes how to develop and debug applications using the Neuron C ISI Library.
General Considerations You can develop applications for the Neuron C ISI library using the NodeBuilder® 3.1 Development Tool or the Mini EVK Evaluation Kit. The Neuron C ISI Library is included with Mini EVK, and is available as a free download for the NodeBuilder 3.1 Development Tool. New updates for the Neuron C ISI Library are posted periodically, so check www.echelon.com/isi for the latest version before starting a new development.
To enable debugging with the managed environment provided by the NodeBuilder and LonMaker tools, you must ensure that an ISI application in development cannot modify the primary domain. The primary domain and the device’s network address are managed by the NodeBuilder tool; modifying this data as a result of self-installation will prevent testing and diagnosing with the NodeBuilder or LonMaker tools.
since the different allocation algorithms used for managed and self-installed connections could result in duplicate resources being assigned. Managed devices and self-installed devices must always be installed in different domains. The NodeBuilder tool is the best tool for developing and debugging Neuron C applications, but there are three other tools that you can use to aid debugging: • The ISI Packet Monitor Application is a free utility included with the ISI Developer’s Kit.
6 Self-Installation Advanced Procedures This chapter describes advanced ISI procedures that are not typically used by all ISI applications, but support additional features not supported by the basic ISI procedures described in Chapter 2. The functions described in this chapter are further described in Appendixes B and C, and the data structures used by these functions are documented in Appendix A.
Overriding a Callback Function You can have the ISI engine call functions in your application in response to key ISI events. These functions are called callback functions, because the ISI engine calls back to your application. To simplify the use of callback functions, the ISI library includes implementations of all ISI API callback functions. As a result, you do not have to provide any callback functions.
Function Name Reason to Override IsiGetAssembly() This function should be overridden for applications with compound assemblies involving multiple network variables, connections involving functional blocks, or automatic enrollment. The default implementation returns the assembly number as the network variable’s global index, if a compatible network variable exists for a simple connection using standard network variable types.
Function Name Reason to Override IsiGetNextAssembly() This function should be overridden when providing for compound assemblies involving multiple network variables, connections involving functional blocks, or automatic enrollment. The default implementation returns the next assembly number if a complementary network variable exists for a simple connection, using standard network variable types.
Function Name Reason to Override IsiSetConnection() This function must be overridden when implementing a custom connection table. When this function is overridden, IsiGetConnectionTableSize() and IsiGetConnection() must also be overridden. The default implementation of the connection table has eight entries stored in EEPROM.
in order to simplify development; however, most developers will tailor the ISI implementation by overriding the default implementations. You cannot replace the functions that indicate they cannot be overridden in Appendix B. The C language has no concept of overloaded functions, so an overridden function can no longer call the default implementation: as both have the same name, calling the function with the same name will result in a recursive function call.
Library Functions with Forwarders Forwarders are implemented in a way that eliminates any overhead for the indirection; there is no benefit in calling the sister function directly other than from within an overridden function. Forwarders are often used to provide an application-specific implementation in a certain aspect, and to fall back to standard behavior in all other cases.
IsiGetNvIndex(), and IsiGetWidth() handle connections of simple assemblies referring to a single network variable of a standard network variable type. For example, a device supporting a compound assembly may implement a closedloop actuator with an input and output network variable—the actuator is an implementation of the SFPTclosedLoopActuator profile called myClosedLoopActuator with a SNVT_amp input and output called nviValue and nvoValue.
With that knowledge, an accepting device that implements a SFPTclosedLoopActuator functional block must associate S1 with its local input network variable, and S0 with its output network variable. The completed connections are shown next: Compound Assembly Connections When the accepting SFPTclosedLoopActuator functional block implements the connection, the ISI implementation will query the mapping from selector values to network variables using the IsiGetNvIndex() callback.
// and a compatible network variable type return Y; } ...
2. Connection host enrolls local, normal, output network variable: direction(CSMOEX) = isiDirectionInput or isiDirectionAny, poll(CSMOEX) = clear; 3. Connection host enrolls local, polling, input network variable: direction(CSMOEX) = isiDirectionOutput, poll(CSMOEX) = set; 4. Connection host enrolls local, polled, output network variable: direction(CSMOEX) = isiDirectionInput, poll(CSMOEX) = set.
formatted as a network variable update. Include an explicit address for the message with addressing details from an application-level address table and identify the message as using the acknowledged service, and then explicitly send the message. EXAMPLE The following example shows the construction of a CSMOEX for an acknowledged connection, and monitors DRUMs to update subnet and node IDs in a device that allows connections to one other device.
Neuron ID to be tracked must be discovered and written to the addressTracking variable when a connection invitation is accepted. When sending an (acknowledged) network variable message, this message is explicitly constructed like an application message, with explicit addressing provided using address details from the addressTracking variable. Turnaround Connections You can create a turnaround connection on an ISI device.
The connection table contains one entry for each simple connection the device has joined, and for each simple extension to a connection. Connections and connection extensions from compound assemblies require N connection table entries, with N being 1 + (Width / 4). You can replace the connection table to support more simultaneous connections or to support more complex connections, requiring a larger connection table.
#define CONTABSIZE 16u static IsiConnection connectionBuffer; unsigned IsiGetConnectionTableSize(void) { return CONTABSIZE; } const IsiConnection* IsiGetConnection(unsigned index) { // TODO: fetch data for index from external storage, // for example by using a I2C serial I/O model; fill // connectionBuffer with that data.
deleted devices, monitor the time of the last update for each entry in the table and detect devices that have not recently sent a DRUM. EXAMPLE 1 The following example maintains a device table, adding new devices when discovered, updating subnet and node IDs when they change, and deleting stale devices. #include #include
// Iterate through the device table again and decrement the // credits at each call of IsiCreatePeriodicMsg(), removing any // devices that have not sent a DRUM in the max possible amount // of credits.
request, and then repeats the process on the remaining devices. To accelerate device discovery, follow these steps: 1. Broadcast a Respond to Query message with a parameter of MODE_ON to the primary domain. This enables all devices to respond to the Query ID message. 2. Broadcast a Query ID message to the primary domain. 3. If there are no responses, exit the procedure. 4.
msg_out.dest_addr.bcast.rpt_timer = ENCODED_RPT_TIMER; msg_out.dest_addr.bcast.retry = RETRY_COUNT; msg_out.dest_addr.bcast.tx_timer = ENCODED_TX_TIMER; msg_out.dest_addr.bcast.subnet = 0; msg_out.tag = discoveryTag; queryIdRequest.selector = SELECTED; memcpy(msg_out.data, &queryIdRequest, sizeof(NM_query_id_request)); msg_send(); } // Handle incoming responses. For successful responses to // the query ID request, store the response data and process according // to the application's needs.
Creating a Connection with Controlled Enrollment You can create a connection from a connection controller using controlled enrollment. The connection controller is not a network management tool—it simply takes the place of the push buttons on devices used to create connections using manual enrollment. Based on user input to the connection controller, the controller sends requests to the devices to be connected that are translated to the same ISI API calls used to create manual connections.
unsigned assembly) { IsiMessage request; msg_out_addr destination; request.Header.Code = isiCtrq; request.Msg.Ctrq.Control = command; request.Msg.Ctrq.Parameter = assembly; destination.nrnid.type = NEURON_ID; destination.nrnid.domain = PRIMARY_DOMAIN; destination.nrnid.rpt_timer = ENCODED_RPT_TIMER; destination.nrnid.subnet = 0; destination.nrnid.retry = RETRY_COUNT; destination.nrnid.tx_timer = ENCODED_TX_TIMER; memcpy(destination.nrnid.
break; case enrolling: // Just one member for this example; close enrollment ControlCommand(controlJob.host.neuronId, isiCreate, controlJob.host.assembly); controlState = creating; break; case creating: // We're done; rport successful completion // to the user ... controlState = idle; break; } } else { // This is a failure response. For this example, simply // cancel the enrollment. ControlCommand(controlJob.host.neuronId, isiCancel, controlJob.host.assembly); // Indicate failure via user interface ...
The RDCT message includes optional host and member assembly fields that specify which connection table entries are requested. If they are not supported by the device, or are both set to 0xFF, the connection table entry indicated by the index is requested. If they are supported and the host or member field is not 0xFF, the index provided is the starting index. The first matching connection table entry is returned, if any.
request.Msg.Rdct.Index = recoveryJob.index++; request.Msg.Rdct.Host = request.Msg.Rdct.Member = ISI_NO_ASSEMBLY; destination.nrnid.type = NEURON_ID; destination.nrnid.domain = PRIMARY_DOMAIN; destination.nrnid.rpt_timer = ENCODED_RPT_TIMER; destination.nrnid.subnet = 0; destination.nrnid.retry = RETRY_COUNT; destination.nrnid.tx_timer = ENCODED_TX_TIMER; memcpy(destination.nrnid.nid, recoveryJob.
// connection table index provided. void SendConnectionTableResponse(unsigned index, boolean success) { IsiMessage response; unsigned length; if (success) { response.Header.Code = isiRdcs; response.Msg.Rdcs.Index = index; memcpy(&response.Msg.Rdcs.Data, IsiGetConnection(index), sizeof(response.Msg.Rdcs.Data)); length = sizeof(IsiMessageHeader)+sizeof(IsiRdcs); } else { response.Header.Code = isiRdcf; length = sizeof(IsiMessageHeader); } memcpy(resp_out.
} Sending an NV Update or Polling an NV from a Controller You can send an individual network variable update to, or poll an individual network variable from, an individual device. This is typically done on a gateway or controller that provides a user interface for individual devices on an ISI network.
EXAMPLE 1 The following example sends a network variable fetch message to a device with a specified NV index, subnet ID, and node ID. These may be fetched from the device table created in the previous section. #include #include
EXAMPLE 2 The following example sends an explicit network variable update to a device in the device table created in the previous section after sending a query NV request to determine the selector of the target network variable. #include #include #include
msg_out.code = NM_opcode_base | (NM_query_nv_cnfg & NM_opcode_mask); msg_out.service = REQUEST; msg_out.tag = nvTag; msg_send(); } // Handle receipt of the network variable configuration response, and // build a network variable update message that copies the value of the // local network variable to the remote network variable. This example // does not ensure that the remote network variable is an input, or // that the both network variables share the same type.
monitored device changes. Controlled and automatic enrollment both address responsiveness by supporting event-driven updates—the controller is notified whenever a monitored network variable value changes. The disadvantage of both controlled and automatic enrollment is that additional code space is required on the monitored device, with automatic enrollment requiring the most code space. This section describes the three methods for both controller and device developers.
device to a peer-to-peer connection. To support controlled enrollment, the controller must maintain a device description table that lists: • the program IDs that support controlled enrollment, • which network variables on each of those devices are to be monitored by the controller, • the assembly containing each monitored network variable, and • which of the devices support connection replacement and which support connection extension.
for the device and all devices that it is connected to using the isiOpen and isiCreate requests. To support controlled enrollment for monitoring, a controller must also recreate monitored connections to a device when the device overwrites on clears any connections created by the controller. There are two cases where this may happen. A device that supports connection replacement may overwrite a controller connection by creating a new connection that replaces the controller connection.
2. If the device supports automatic enrollment for monitoring and but does not support connection extension, the device calls the the IsiIsConnected() function to determine if the monitored NV is already in a connection. If the monitored NV is not already in a connection, the device accepts the connection invitation from the monitor point. If the monitored NV is already in a connection, the device does not accept the invitation.
You can use periodic processing in the ISI engine to schedule and send periodic heartbeat updates for any of the output network variables in your application. To send periodic heartbeats, follow these steps: 1. Start the ISI engine with the isiFlagHeartbeat flag. This causes the ISI engine to periodically call the IsiQueryHeartbeat() callback. This function returns TRUE if a heartbeat has been propagated, and FALSE otherwise. 2.
this function; just set the application-specific flag if there is a message to send and return control to the ISI engine immediately. 3. Use the application-specific flag in a separate when task to send the periodic message soon after the IsiCreatePeriodicMsg() function is completed. If you are sending an ISI message, you can use the IsiMsgSend() function. This function sets header fields for an ISI message, and then passes the message on to IsiMsgDeliver(), which propagates the message.
IsiFull This library contains the complete feature set as defined in this document. The IsiFull library may require device resources for library code and constant data that are unavailable for a specific target platform, especially if the platform is based on a 3120 chip. If there are insufficient resources on a device for the IsiFull library, then choose one of the other libraries.
IsiCompactSHb This library supports the same features as the IsiCompactS library, with the addition of support for network variable heartbeats, as described in Sending Periodic Heartbeats. Devices created with this library do not support domain acquisition. IsiCompactDa This library supports the same features as IsiCompactS, with the addition of support for domain acquisition. Network variable heartbeats are not supported by this version of the ISI engine.
Is iC Is o m iC p I s o m ac iC p t M I s o m ac an iC p t A u I s o m ac ut o al.l iC p t S . ib I s o m ac .lib lib iC p t S I s o m ac Hb iF p t D . l u l ac a i b l. l t D .lib ib a H b. l ib To identify the smallest possible ISI implementation that meets your application needs, start with the leftmost column (IsiCompactManual.lib) and proceed towards the right until you have found a library that supports all required features. When in doubt and device resources allowing, prefer using IsiFull.lib.
IsiTick(), because using these functions causes the linker to include the more specific functions (including the DAS functions) with the application. If your application uses the CENELEC Configuration Library functions to enable or disable the CENELEC Media Access protocol at runtime, your ISI application does not need to link with the cenelec.lib library because the PL 3170 system image includes these functions.
ISI Programmer’s Guide 100
7 Transitioning between Managed and Self-Installed Networks This chapter describes how you can transition a selfinstalled network to a managed network. This is useful when you want to introduce the benefits of a network management tool into an operating self-installed network.
You can upgrade a network from a self-installed network to a managed network. You may do this to add non-ISI devices to an ISI network, to extend the network beyond the ISI limits, or to introduce managed monitoring and control tools to the network. You can use the LonMaker Integration Tool or another application that implements LNS recovery to automatically analyze an ISI network and create a LNS database reflecting the present network configuration.
Appendix A API Data Types This appendix describes the data types used by the ISI library. Byte offset values shown refer to the IsiMessage structure, starting with IsiMessageHeader at index 0. This ISI API reference describes the ISI API for Neuron C, and uses the Neuron C programming model. The Neuron C language employs a 1-byte-centric, big-endian, programming model. The char, int, short, and enum types all use a single byte. The long type uses 2 bytes in big-endian ordering.
ConnDesc Structure Contains details describing a connection. Used in the IsiConnection structure. Data Type Field Name Note unsigned : 6 Offset Offset into the larger selector set for connections from compound assemblies with more than four selectors, 0 for connections from simple assemblies, connections from compound assemblies covering four or less than selectors, or the first connection table entry related to a connection from a compound assembly with a width > 4. Also see CSMI.
Byte offset Data Type Field Name Note N unsigned [5] UniqueId A unique identifier for the connection host, based on the host’s Neuron ID. N+5 unsigned long SerialNumber Connection host-allocated serial number. The byte offset N is 1 for the IsiCid or IsiConnectionHeader structure used with ISI message types, and is 0 (zero) when used with the IsiConnection structure.
Byte offset Data Type Field Name Note N IsiCid Cid See IsiCid. N+7 unsigned long Selector Selector value 0 – 0x2FFF. The most significant 2 bits must be cleared. The byte offset N is 1 for the IsiConnectionHeader structure used with ISI message types, and is 0 (zero) when used with the IsiConnection structure. IsiConnectionState Enumeration Specifies the state of a connection table entry. IsiConnectionState Value Note isiConnectionStateUnused 0 The connection table entry is unused.
IsiControl Value Note isiExtend 3 Extend a connection by calling IsiExtendEnrollment() using the assembly number passed in as the parameter. isiCancel 4 Cancel an open (pending or approved) enrollment by calling IsiCancelEnrollment(). isiLeave 5 Remove the specified assembly from all enrolled connections on the local device by calling IsiLeaveEnrollment() using the assembly number passed in as the parameter.
IsiCsmi Structure Defines an enrollment information message (CSMI) sent by the ISI engine. Byte offset Data Type Field Name Note 1 IsiConnection Header Header See IsiConnectionHeader 10 unsigned : 6 Offset Offset into the selector set of a connection from a compound assembly with five or more selectors; zero for a connection from a simple assembly or a connection from a compound assembly using less than five selectors.
Byte offset Data Type Field Name Note N unsigned Group The group (or device category) this connection applies to. See text for valid group ID values, and allocation of group ID values. N+1 unsigned : 2 Direction Direction of the primary network variable on offer. See the IsiDirection enumeration. N+1 unsigned : 6 Width Number of selector values used with this connection, starting with the value of the Selector field. Value 0 is reserved.
Byte offset Data Type Field Name Note N+5 unsigned Variant Variant number for the offered connection. Variants may be defined for any device category and/or functional profile/member number pair. Variants allow different interpretations of the offered data, based on a variant value. Set to zero unless otherwise known. Values 1 – 127 are standard variant values specified by the ISI Protocol Specification and by ISI profiles published by LONMARK International.
Byte offset Data Type Field Name Note N+6 unsigned : 2 Extended. Scope Scope of the resource file containing the functional profile and network variable type definitions specified by the Profile and NvType fields. See the IsiScope enumeration. Values 1 and 2 are reserved. For regular CSMO, CSMA, and CSMR messages, this field is always zero. You must specify the isiFlagExtended flag when starting the ISI engine to use this field. N+6 unsigned : 4 Reserved. Clear when sending, ignore when receiving.
The byte offset N is 10 for the IsiCsmoData structure used with ISI message types (IsiCsmo structure), and is zero when used with the IsiGetAssembly() and IsiGetNextAssembly() functions. IsiCsmr Structure An alias for the IsiCsmo data type, see there for details. The IsiCsmr data type is used with automatic enrollment reminder messages (CSMRs). IsiCsmx Structure An alias for the IsiConnectionHeader data type, see there for details.
IsiDiagnostic Value Note isiSubnetNodeAllocation 1 A local subnet/node ID has been allocated. isiSubnetNodeDuplicate 2 A subnet/node ID duplicate has been detected. isiReceiveDrum 4 DRUM or DRUMEX message received. isiReceiveTimg 5 TIMG message received. isiSendPeriodic 6 Periodic message other than an NV heartbeat message sent (see IsiQueryHeartbeat() for these). The ISI message code for the message sent is in the numeric parameter.
Byte Offset Data Type Field Name Note 2 unsigned [6] Did Domain ID. This field is always 6 bytes long; the number of significant bytes is contained in the DIDlength field 8 unsigned [6] NeuronId Neuron ID of the DAS, used for matching DIDRM messages with DIDCF messages. 14 unsigned DeviceCountEst Estimated device count used for throttling periodic messages. The device count is an approximation and will typically be larger than the actual network size.
IsiEvent Value Note isiDirectionAny 2 Indicates that both input and output network variables may be applicable to this connection. Used to support N:M connections. isiDirectionVarious 3 Indicates the network variable direction is distinct and a combination of inputs and outputs. Used in compound assemblies, where the network variable directions are defined by the functional profile. IsiDrum Structure Defines a domain resource usage message (DRUM/DRUMEX).
Byte Offset Data Type Field Name Note 18 unsigned long Extended.Device Class Value from the Device Class standard program ID field. For regular DRUM messages, this field is always zero. You must specify the isiFlagExtended flag when starting the ISI engine to use this field. 20 unsigned Extended.Usage Value from the Usage standard program ID field. For regular DRUM messages, this field is always zero. You must specify the isiFlagExtended flag when starting the ISI engine to use this field.
IsiEvent Value Note isiCancelled 5 Connection has been cancelled by a timeout, user, or network action. The parameter is always set to ISI_NO_ASSEMBLY. isiDeleted 6 Connection has been deleted. The parameter identifies the assembly. isiWarm 7 ISI engine has warmed up—i.e., some reasonable, but random, time has passed since the last reset. From this moment on, the application may call the IsiInitiateAutoEnrollment() function.
IsiFlags Value Note isiFlagExtended 0x01 Enables the use of the extended DRUMEX, CSMOEX, CSMAEX, and CSMREX messages. isiFlagHeartbeart 0x02 Enables automatic network variable heartbeats. Heartbeats are disabled by default. Automatic heartbeats apply to all bound output network variables and related aliases. See Optimizing Footprint of ISIenabled Applications for which libraries this feature can be used in.
IsiMessage Structure Contains the header and body of an ISI protocol message. These messages are typically sent using IsiSendMsg(). Byte Offset IsiMessage Data Type Note 0 Header IsiMessageHeader Message Header 1 Msg union Contents of the message.
IsiMessageCode Value Note isiDidrm 0x09 Domain ID response isiDidcf 0x0A Domain ID confirmation isiTimg 0x0B Timing guidance message isiCsmx 0x0C Connections: cancel enrollment isiCsmc 0x0D Connections: close and confirm enrollment isiCsme 0x0E Connections: accept enrollment isiCsmd 0x0F Connections: delete connection isiCsmi 0x10 Connections: status and resource information isiCtrq 0x11 Controlled enrollment: control request isiCtrp 0x12 Controlled enrollment: control respon
IsiRdct Structure Defines a read connection table (RDCT) request message used for controlled enrollment. Byte offset Data Type Field Name Note 1 unsigned Index Connection table index to return, or the starting index to start searching from (if Host or Member are not ISI_NO_ASSEMBLY). 2 unsigned Host Host assembly to search for in the connection table, or ISI_NO_ASSEMBLY. Support for this field is optional.
IsiScope Value isiScopeManufacturer Note 3 Indicates that Profile and NvType values refer to user-defined scope 3 – 5 resource files that match the applicable fields in the ProgramIDShort field All other values are reserved. IsiTimg Structure Defines a timing guidance message (TIMG). Byte Offset Data Type Field Name Note 1 unsigned : 4 Originator Set to 8 for a regular DAS. All other values are reserved.
Appendix B API Functions This appendix describes the functions provided by the ISI library. Important: To minimize its memory requirements, the ISI engine performs only limited function parameter verification. You must ensure that your ISI application passes correct parameters to the ISI functions.
IsiAcquireDomain() void IsiAcquireDomain(boolean SharedServicePin); Starts or re-starts the domain ID acquisition process in a device that supports domain acquisition. The IsiAcquireDomain() function must not be called from a DAS or device that does not support domain acquistion. The IsiFetchDevice() function provides an alternate method to assign a domain from a DAS. A DAS must support both methods.
IsiApproveMsgDas() boolean IsiApproveMsgDas(void); Determines if an incoming message is an ISI or service pin message by verifying the message code and length. If approved, the received message may be processed by one of the IsiProcessMsg() functions. This function must be used on ISI-DAS devices instead of IsiApproveMsg(). The function has the same functionality as IsiApproveMsg(), but also approves additional messages required by a domain address server.
This function has no effect unless the ISI engine is running and the device is either in device or domain acquisition mode. IsiCancelEnrollment() void IsiCancelEnrollment(void); Cancels an open (pending or approved) enrollment. When used on a connection host, a CSMX connection cancellation message is issued to cancel enrollment on the connection members. When used on a device that has accepted, but not yet implemented, an open enrollment, this causes the device to opt out of the enrollment locally.
Calling this function on a device that does not support connection removal while indicating an assembly number that is already engaged in another connection, will not implement the new connection. The isiImplemented event will not be fired in this case. The application may use the IsiIsConnected() function to determine if a given assembly is currently engaged in a connection. Where supported and unless application requirements dictate otherwise, the IsiExtendEnrollment() function should be used instead.
IsiExtendEnrollment() void IsiExtendEnrollment(unsigned Assembly); Accepts a connection invitation on a device that supports connection extension. This function may be called after the application has received and approved a CSMO open enrollment message. The connection will be added to any previously existing connections. If no previous connection exists for Assembly, a new connection will be created. This function must not be called on a device that does not support connection extension.
IsiFetchDevice() void IsiFetchDevice(void); Fetches a device by assigning a domain to the device from a domain address server (DAS). The IsiFetchDevice() function must not be called from a device that is not a domain address server. To use the IsiFetchDevice() function, you must implement a when (resp_arrives) task and call the IsiProcessResponse() function from the domain address server’s application to complete the processing involved with fetching a remote device.
To use the IsiFetchDomain() function, you must implement a when (resp_arrives) task and call the IsiProcessResponse() function function with the domain address server’s application to complete the processing involved with fetching a domain ID. EXAMPLE The following example is part of the domain address server’s application.
selector, and rejects the open enrollment message if insufficient network variable aliases are available to meet that assumption: unsigned IsiGetAssembly(const CsmoData* pCsmo, boolean Auto) { unsigned candidateAssembly; // Determine an eligible assembly based on local knowledge and // inspection of data provided with pCsmo and Auto arguments candidateAssembly = … return IsiGetFreeAliasCount() >= pCsmo->Width ? candidateAssembly : ISI_NO_ASSEMBLY; } Example 2: This example illustrates how a connection host
IsiInitiateAutoEnrollment() void IsiInitiateAutoEnrollment(const IsiCsma* pCsma, unsigned Assembly); Starts automatic enrollment. The local device will become the connection host. Automatic enrollment may replace previous connections, if any. No forwarder exists for this function. Once this call returns, then the ISI connection is implemented for the associated assembly. This function cannot be called before the isiWarm event has been signaled in the IsiUpdateUserInterface() callback.
IsiIsRunning() boolean IsiIsRunning(void); Returns TRUE if the ISI engine is running and FALSE if the ISI engine is stopped. Non-zero values are considered TRUE. No forwarder is provided for this function. The function operates in all states of the ISI engine. IsiIssueHeartbeat() boolean IsiIssueHeartbeat(unsigned NvIndex); Sends a network variable update for the specified network variable index and its aliases, as long as the network variable is a bound output network variable using group addressing.
IsiMsgDeliver() void IsiMsgDeliver(IsiMessage* pMsg, unsigned Length, msg_out_addr* pDestination); Sends an ISI message to the address specified in the pDestination parameter. An ISI application must implement the IsiMsgDeliver() function. The function is used by the ISI library for sending messages, and should not be used by the application itself. In most cases, the application code need not explicitly declare the IsiMsgDeliver() function; it is automatically implemented by including the isi.
IsiPreStart() void IsiPreStart(void); Establishes runtime links between the ISI engine in the read-only memory (ROM) of a PL 3170 Smart Transceiver and the callbacks in the application. For PL 3170 devices, you must call the IsiPreStart() function from the when(reset) task before calling any other ISI functions. You must call this function even if you do not plan to start the ISI engine. Important: The IsiPreStart() function is supported only for PL 3170 devices, and is not supported for other device types.
IsiReturnToFactoryDefaults(); // Call NEVER returns! } // Self-installed network--start the ISI engine scaled_delay(31745UL); // 800ms delay IsiStartS(isiFlagExtended+isiFlagHeartbeat); } } IsiProcessMsg() boolean IsiProcessMsg(IsiType Type); boolean IsiProcessMsgDa(void); boolean IsiProcessMsgDas(void); boolean IsiProcessMsgS(void); Processes an ISI message that has been verified as an ISI message by the IsiApproveMsg() function.
IsiProcessResponse() boolean IsiProcessResponse(void); Processes a response to a request message sent in the domain acquisition process. Only needs to be called on a DAS device. DAS devices must call this function, or the fetch requests will fail.
cpNwrkConfig = OldNetConfig; if (cpNwrkConfig == CFG_NUL) { // For the first application start, set nciNetConfig to // CFG_LOCAL, allowing the ISI engine to run by default: nciNetConfig = CFG_LOCAL; } OldNetConfig = nciNetConfig; if (nciNetConfig == CFG_LOCAL) { if (cpNwrkConfig == CFG_EXTERNAL) { // The application has just returned into the self// installed environment.
When selecting one of the specialized versions IsiStartS(), IsiStartDA(), or IsiStartDAS(), you must make sure to use the same type of specialized message processor function (IsiProcessMsgS(), etc) and tick function (IsiTickS(), etc). No forwarders are provided with the IsiStart() functions.
IsiStop() void IsiStop(void); Stops the ISI engine. Use one of the IsiStart() functions to re-start the ISI engine. The IsiStop() function has no forwarder. Calling IsiStop() when the ISI engine is stopped has no action. IsiTick() void IsiTick(IsiType Type); void IsiTickS(void); void IsiTickDa(void); void IsiTickDas(void); Performs periodic processing for the ISI engine. You must periodically call one of the IsiTick() functions after you have started the ISI engine with one of the IsiStart() functions.
Appendix C Callback Functions This appendix describes the callback functions that your application may provide for the ISI library. The ISI library includes default implementations of all ISI API callback functions. As a result, you only have to provide callback functions where you need to customize the default behavior.
IsiCreateCsmo() void IsiCreateCsmo(unsigned Assembly, IsiCsmoData* pCsmoData); Constructs the IsiCsmoData portion of a CSMO Message. The pCsmoData parameter is a pointer to an IsiCsmoData structure that is filled by this function call. This function is called by the ISI engine prior to sending a CSMO message. This function has the same effect if the ISI engine is running or not. IsiCreateCsmo() is a forwarder to isiCreateCsmo().
EXAMPLE The following example sends a periodic message: boolean SendApplicationPeriodic = FALSE; boolean IsiCreatePeriodicMsg(...
IsiGetConnection() const IsiConnection* IsiGetConnection(unsigned Index); Returns a pointer to an entry in the connection table. The default implementation returns a pointer to a built-in connection table with 8 entries, stored in on-chip EEPROM memory. You can override this function to provide an application-specific means of accessing the connection table, or to provide an application table of a different size.
You must override the IsiSetConnection() and IsiGetConnection() functions if you override the IsiGetConnectionTableSize() function.
IsiGetNextNvIndex() unsigned IsiGetNextNvIndex(unsigned Assembly, unsigned Offset, unsigned Previous); Returns the network variable index of the network variable at the specified offset within the specified assembly, following the network variable specified by the Previous index. Returns ISI_NO_INDEX if there are no more network variables, or a valid network variable index 1– 254 otherwise.
IsiGetPrimaryDid() const unsigned* IsiGetPrimaryDid(unsigned* pLength); Returns a pointer to the default primary domain ID for the device. The function also provides the domain ID length in the location provided by the pLength parameter. Domain IDs may be 1, 3, or 6 bytes long—the 0-length domain ID cannot be used for the primary domain. Only the number of bytes provided through the pLength output parameter must be valid in the returned pointer.
IsiGetWidth() unsigned IsiGetWidth(unsigned Assembly); Returns the width in the specified assembly. The width is equal to the number of network variable selectors associated with the assembly. This function is a forwarder to isiGetWidth(). The isiGetWidth() forwardee always returns one. Applications must override the IsiGetWidth() function to support compound assemblies. This function operates whether the ISI engine is running or not.
You must override the IsiGetConnection() and IsiGetConnectionTableSize() functions if you override the IsiSetConnection() function. IsiSetDomain() void IsiSetDomain(domain_struct* pDomain, unsigned Index); Sets the domain, subnet, and node ID in the primary entry of the domain table for a device. You can override this function with an empty function during development in a managed environment to prevent conflicts with the network management tool.
IsiUpdateUserInterface() void IsiUpdateUserInterface(IsiEvent Event, unsigned Parameter); Provides status feedback from the ISI engine. These events are useful for synchronizing the device’s user interface with the ISI engine. To receive notification of ISI status events, override the IsiUpdateUserInterface() callback function. The default implementation of IsiUpdateUserInterface() does nothing.
Appendix D ISI Router Configuration This appendix provides information for preparing a LONWORKS router for use with an ISI network.
LONWORKS Routers and ISI Networks To prepare a LONWORKS router for use with an ISI network, configure the device as follows: TP/FT-10 Side PL-20 Side Domain[0] 0x49-0x53-0x49 (“ISI”) 0x49-0x53-0x49 (“ISI”) Domain[1] n/a n/a Channel ID 0x04 0x10 Router Mode Repeater, Online Repeater, Online You can find more information about LONWORKS router modules and their configuration from the LONWORKS Router User’s Guide, available for download from http://www.echelon.
Appendix E Glossary This appendix defines the key ISI terms.
Term Definition Application message An ANSI/CEA-709.1 (EN14908-1) message with a message code in the range of 0 to 62. Message codes 48 to 62 are reserved for standard application messages, including messages used for ISI (message code 61) and file transfer (message code 62). Message codes 0 to may be used for proprietary manufacturer-specific messages. Assembly See connection assembly. Automatic enrollment The process of creating an ISI connection without user interaction.
Term Definition controller to specify the devices to be connected. Domain Address Server (DAS) A device present in ISI-DA networks that does ISI management tasks such as assigning a domain ID and monitoring and reporting network size. An ISI-DA network may include multiple domain address servers. Domain Resource Usage Message (DRUM) Periodic message containing the physical address (Neuron ID), logical address (domain, subnet, and node ID), and part of the program ID for a device.
Term Definition Network management The act of putting network configuration data into a persistent store (typically a database) with the intent of making the network configuration data in a network of devices consistent with that network configuration data in the persistent store, and maintaining that consistency over time. Just storing the data into a persistent store, for example, is not network management; it is just a backup or snapshot of the data at any one point.
www.echelon.
