Python Address Table Access on ConnectPort X4

Dear Community,
I have a network of Zigbee Pro 2007 end devices that is coordinated via a ConnectPortX4. The mapping between the MAC address and NWK address of each end device is of use to me, and I would like to know how one accesses the address table of the X4 via the python environment.

As you may recall, you can use socket.recvfrom() to get APS payloads from an end device along with its address. However, the address returned is only the NWK address, which is not an absolute reference because it is assigned by the coordinator.

Upon network joining, a MAC address is sent once, but one cannot know for certain which NWK address it corresponds to in the subsequent received messages. Hence the dilemma.

How does one access the coordinator’s NWK address to MAC address mapping in python?

If I understand you correctly, all you need to do is set the AO=1 in the XBee, and it will always issue you the API frame 0x91 which includes the full MAC+NWK+Cluster+Profile (etc).

See this Wiki page:

Note that you receiving a 0x91 is UNRELATED to you sending either 0x10 or 0x11. The receive form 0x90 without the MAC is just a historical/legacy feature for users migrating from the older XCite/XStream technologies. The 0x11/0x91 style message always moves across the RF channel.

Thanks for this input. How would I do the equivalent of setting AO=1 if my firmware is set to API mode?

You can use XCTU to just set it.

Or use the “AT Command” API frame (0x08) to first write AO to 0x01, then repeat for the “AC” (with no value) and then “WR”. The change is permanent so you only have to do once.

Call me clueless, but I have connected to my device via both XCTU and DigiESP. I have tried to use “AO=1” on the terminal, but the command is not recognized.

Is there a way you programmatically set this flag in Python? Is there a specific firmware version you need to set this flag?

Normally, the Xbee in an X4 should already have AO=1.

On the X4 you can do most things via:

From Python you’d use the xbee module to read/write ‘AT’ commands in the local (X4’s) or remote XBee:

Thanks for all the info. The full MAC address comes through consistently for my TI Z-stack-based routers. However, my TI end devices just show the NWK address when their packets come through the socket. They must have some crazy flag set that prevents them from transmitting their MAC address. Go figure.

The NWK IS used as a short-cut to speed up routing, since scanning 16-bit addresses in a table is much faster than 64-bit MACs. The Digi X4 and XBee hide such details from the user, so even if you submit a request with MAC, they use the NWK if known. Your TI stack apparently assumes you’ll do all of that.

But check the code you have, I’d assume they do include some form of ‘cache’ which you could query to convert MAC to NWK or vis-versa. Every Zigbee customer would need it sooner or later.

On the X4, you can also do things like this:

Thanks lynnl.

I have actually already looked at the code you linked.

The main function of importance in that code is


which returns a list of node objects with all the relevant address info. The problem with this function is it only returns XBee nodes on the network.

I imagine there is some low-level call that can be made (perhaps not in python) which actually returns all the nodes. The web interface hosted by the coordinator generates an XBee Network HTML page that displays all nodes on the network.

So the functionality I am looking for exists in the X4, it just may not be accessible at the python level.

Update: The function zigbee.getnodelist(refresh = True) seems to send the FULL list of nodes when I pass a value of False i.e.

zigbee.getnodelist(refresh = False)

Go figure!

If you are really interested in node lists - search the forum for “neighbor tables” - a common topic.

You can 9as example) go to teh X4’s XBee and ask for a table of all known ‘neighbors’ (aka: routable destinations). Given this list, you can recursively ask other routers for their neighbors and build an image of the mesh, of which routers can see each other.