Is it possible to create an ember framework application which has all device types built in, then have the device configured in real time to change between these device types? I am interested in this as our application will have configurable topologies.
At the stack-level, this is doable since the zigbee-pro-stack-library has support for all the various device types and can choose what to do at runtime. However, the Ember Application Framework doesn't currently provide a straightforward means to include "everything" (all the router/coordinator support as well as all the sleepy/non-sleepy end device support) in a single application and then dynamically disable/enable the relevant state machines. It wants to pare down the included code/libraries to just what's needed, so a build with Node Type (in AppBuilder) set to "Coordinator/Router" wouldn't pull in any libraries, plugins, or app state machines for sleepy ED support; similarly, a "Sleepy End Device" node type choice causes AppBuilder to include the zigbee-pro-leaf-stack-library, which only had end device support and won't route or form networks, and the included #defines enable (at compile-time) a lot of polling/sleeping state machines that would have to be circumvented if you weren't acting as an end device.
So, what can you do about all this? You could architect an app outside of the framework, just using stack APIs, which is possible but requires a lot of work and is prone to many pitfalls, but another approach I've experimented with for accomplishing this is to do a "multi-network" configuration in AppBuilder, where you have 2 ZigBee Pro networks on the same device, making one of them a Router/Coordinator and the other a Sleepy End Device, but otherwise having similar properties as far as security, clusters/endpoints, etc. Even though you'll duplicate the number of ZigBee endpoints on your device, the callback implementations for the Post Attribute Changed callbacks can reference the same hardware underneath when dealing with two endpoints for essentially the same attribute (e.g. the sleepy network's instance of CurrentLevel on endpoint X and the router network's instance of CurrentLevel on endpoint Y). With this setup, you could choose which network (the R/C-capable one or the ED-capable one) to use for forming/joining based on the runtime requirements of the device, and as long as you don't try to join both network instances to the same PAN at the same time (which would thoroughly confuse the network because it's still the same radio with the same EUI64 MAC address underneath each instance), you should be able to use all of the required functionality for either node type within the context of the relevant network.
Note that the choice of network contexts prior to API or CLI commands involves manual selection via either CLI command network set N or API command emberAfPushNetworkIndex(N), where N = network index 0 or 1.
I've tried this in some rudimentary testing and found it to be successful, but if you happen to use it more extensively, I'd be curious to know how it works out for you.
For more on multi-networking, see also: AN724: Designing for Multiple Networks on a Single ZigBee Chip