How can I tell when a node in my network is entering or has exited?

When devices enter the network…
With regard to detecting incoming devices, the EmberZNet stack will generate a ChildJoinHandler callback on any router/coordinator node who accepts association (joining) by an end device (whether sleepy, mobile or neither). This callback indicates which index in the local node’s child table was impacted by the joining. The callback can also be triggered with the joining parameter set to False to indicate that the child has been removed from the child table, either because it communicated to the parent that it was willfully leaving the network or because the child table entry aged out (see End Device Poll Timeout FAQ in related articles list) or because the child was determined to have moved to a new parent. This callback is not triggered for incoming router devices because a ZigBee Pro networks makes no dependencies between routers (no child table entry is present).

Also, when security is activated in a network, all associations of new devices are followed by a negotiation with the Trust Center [TC] (assumed to be the coordinator), using the device that allowed the joining (“joinee”) as a proxy for communication. The joinee will ask the TC if the new node (the “joiner”) is permitted to join (or rejoin) the network, and the TC will either indicate its acceptance by sending the network’s encryption key (possibly encrypted with a link key) to the joiner via the joinee or will deny the entry of the joiner, signified by sending the joinee a Remove Device message, at which point the joiner is instructed to leave the network immediately. This process is signified at the TC by the TrustCenterJoinHandler callback, where the join decision is ultimately decided (at a security policy level).

When devices exit the network…
With regard to detecting devices leaving, your application should NOT depend on getting notifications when devices leave. In normal running systems, devices don’t often leave gracefully (or intentionally), so if a node drops off the network due to some circumstance not under its control, you won’t have the benefit of knowing about it through any official notification. Furthermore, the mechanisms that ZigBee uses to inform devices of a node’s departure are not reliable (broadcasts and un-ACKed Unicasts). Thus, your application design (if it cares very much about the presence/lack of devices) would need to have some mechanism to detect nodes that have dropped out of the network, regardless of whether that departure was intentional.

However, in regards to “official” notifications about devices leaving, all nodes send a Leave Announcement (broadcast) when they perform a proper Leave operation (emberLeaveNetwork API), and when the parent/neighbors of the leaving device hear this message, they send an Update Device notification (un-ACKed APS unicast) to the Trust Center [TC], which manifests at the TC application as a TrustCenterJoinHandler callback with status of DEVICE_LEFT. But since any of these operations could conceivably fail without the application (either the leaving device or the TC) knowing about it, you should put in your own safeguards to detect that nodes are no longer available in the network (if this kind of thing is crucial to your design), or [alternatively] some way for the device itself to notice that its connection to the remainder of the network has been disrupted.

In summary…
You can always depend on knowing when a node is coming in, because it can’t really come in without the TC’s permission (and a child node can’t come in without its parent taking responsibility for it). But a node going offline permanently or semi-permanently is not something you can depend on knowing about at the TC (or really anywhere other than perhaps at a parent node of an end device, since there is polling in that case to serve as a keep-alive for the child table entry).