« Back

Quick Tip: Determine the Switch Interface to which an Endpoint or Neighbor is Connected

Below is a walk through on how to programmatically determine the switch interface to which an EnergyWise endpoint or neighbor is connected to. This allows you to directly address that particular interface in an EnergyWise query.

This information is useful in daisy chaining scenarios where a PC endpoint is connected behind a PoE IP phone. By knowing the interface that the PC is connected through, you can address it explicitly to control the PoE power on the phone (e.g. enabling connectivity for late night patch management when the phone is off due to standard policy). This is also useful if you would want to install a recurrent policy on the interface that an endpoint is connected.

-Endpoints are running an EnergyWise SDK Agent version 1.2 or later
-Domain members running EnergyWise phase 2.5+ IOS

The procedure below should take place periodically in order to pick up new and/or moved devices in the domain. Ideally, this should happen when you know that most devices will be powered and active. Powered down devices will not be discoverable, so the application would need to have previously discovered them while in an active state.

Determine the interface to which an endpoint or neighbor is connected to:
  1. From the API, run a collect query for the neighbor attribute (EW_ATTRIBUTE_TYPE_NEIGHBOR). Each domain member will respond providing information about its connected endpoints (SDK endpoints) and neighbors.
  2. In the query resultset, there will be one row for each domain member in the EnergyWise domain. Within each row, there will be one neighbor entry for each connected neighbor or endpoint of that domain member. The neighbor entry will provide the following set of info for each neighbor/endpoint:
    a. Name
    b. Reply to (ip address)
    c. is neighbor or child (indication of whether it is a neighbor or SDK endpoint)
    d. MAC address
    e. EnergyWise ID (of the neighbor/endpoint)
    f. Connected interface physical index (the port that this neighbor is actually connected to on the domain member)
  3. Since we know the parent switch's EnergyWise ID already (can be extracted from the same result row as the neighbor info), we can combine that EnergyWise ID with the connected interface physical index to form the EnergyWise ID of the interface itself, allowing us to target that interface. (See code example below for example of how to do this)

Determining the interface that a PoE device such as an IP phone (no SDK) is connected to:
  1. Using the API, run a collect query against the network asking for standard info (name, role, device type, etc.)
  2. Dumb IP phones will be represented by the standard PoE interface entity. The application would need to look into the attribute info here and determine whether it is an IP phone or not. This can be done by looking into the EW_ATTRIBUTE_TYPE_DEVICE_TYPE field, which will be populated with a value such as "IP Phone 7925"
  3. Additionally, the Name field will be populated with a name of "SEPXYZ" where XYZ is the MAC address of the phone.

Once you've determined the connected interface for an endpoint and the phone's interface, you can then use queries to control the phone's interface power explicitly (this could be beneficial in the case of daisy chained PCs and IP phones). Ideally, address the query to the specific ID of the connected interface and set the power level to 10 or 0 based on the need. It can also be used to set a recurrence policy on the interface, etc.

The below code example demonstrates how this discovery can be done and provides comments inline. The example here queries the entire EnergyWise domain and forms the connected interface ID for each neighbor/endpoint on-the-fly. In a real implementation this should be done once during normal device discovery and then stored for later use.

exampleNeighborQuery(enw_session_t *session, char* domain)
enw_query_t* query;
enw_resultset_t *resultset;
enw_resultrow_t *result_row;
energywise_sender_id_t *id; /* to retrieve the domain member's id */
energywise_sender_id_t interface_id; /* form the connected interface id and store here */
energywise_neighbor_details_t *aNeighbor; /* structure holding each neighbor's info */
int32_t length;

query = energywise_createCollectQuery(domain, getImportance ());

energywise_addGetAttribute(query, EW_ATTRIBUTE_TYPE_NEIGHBOR);

energywise_execQuery(session, query);

// read results
resultset = energywise_queryResults(session, query);

* The resultset will contain one row per EnergyWise domain member that
* has a neighbor. Within each row, there will be one
* EW_ATTRIBUTE_TYPE_NEIGHBOR structure representing the neighbors of
* that domain member.
while ((result_row = energywise_getNextRow(resultset))) {
* First, fetch the domain member's ID. This will be used
* later to form the connected interface's ID.
id = energywise_getAttributeFromRowByType(result_row,
* The first part of forming the interface ID is to use
* the domain member's ID. This is because the connected
* interface is actually on the domain member switch. We now
* need to go and find what the connected interface index is,
* which will be used to form the second part of the ID.
memcpy (&, id->id, sizeof (;
* Iterate over each neighbor of the domain member and get its i/f index
while ((aNeighbor = energywise_getAttributeFromRowByType(result_row,
* For this neighbor/endpoint, combine the connected i/f index with the
* domain member ID that we fetched above. This is the
* EnergyWise ID of the interface that this device is connected
* to.
interface_id.phy_idx = aNeighbor->connected_interface_ent_phy_idx;
* interface_id structure now holds the EnergyWise ID of this neighbor
* or endpoint's connected interface. You would not want to rediscover
* this interface ID every time. Rather, once discovered, this ID should
* be stored for later use.
printf ("%s is connected to interface %s with EW ID: ", aNeighbor->name,
energywise_dump_buf_as_char (, sizeof (;
printf (" Index: %d\n", interface_id.phy_idx);


No files available