Your dev radio board sounds like it is using USART 0 to implement the CLI. When you Adapter->Launce Console you are actually opening a terminal program.  You can also use Tera Term or Hyperterminal as an alternative. If you where using the SWO, then you would click Adapter ->Open SWO Terminal. 

The best place to start is the user guide and schematic for your dev board and see how that is wired. 

Virtual comport and Virtual UART are different things. The Virtual UART is the SWDIO connection on the debugger as you state, and virtual COM port is the USB to USART interface on the dev board. When using the Virtual COM port, you needs to enabled this from the firmware.

Which ports and pins the app uses are configured in the configurator.

The bare minimum you need for a USART CLI is RX and TX if you are not using flow control 

the stack is Zigbee 6.6.3.0

It this any function in hardware_routines.c. I seem to have been able to get it to compile by removing the code and there are no linker errors so it looks like it's not used. Note I have also removed CSLIB_TRST [] from hardware_config.c

/**************************************************************************//**
 * Change TRST value based on noise estimation
 *
 * When system-wide noise is above threshold for more than TRST_DELAY LDMA
 * interrupts, switch to a new TRST setting and reset noise value.
 *
 *****************************************************************************/
//static void CSLIB_TRSTSwitchIfHighNoise(void)
//{
//  static uint8_t delayCountTRSTChange = 0;  // number of scans with noise above cutoff
//
//  if ( CSLIB_systemNoiseAverage > TRST_NOISE_THRESHOLD ) {
//    // Increment counter
//    delayCountTRSTChange++;
//    // If counter above change threshold
//    if ( delayCountTRSTChange > TRST_DELAY ) {
//      // Reset counter
//      delayCountTRSTChange = 0;
//      // Swap to new TRST setting
//      indexTRST++;
//      indexTRST = indexTRST % TRST_ARRAY_SIZE;
//      sleep_mode_default.resetPhase = CSLIB_TRST[indexTRST];
//      active_mode_default.resetPhase = CSLIB_TRST[indexTRST];
//
//      if (TRST_NOISE_EST_RESET) {
//        CSLIB_initNoiseCharacterization();
//        noise_level = mid;
//      }
//    }
//  } else {
//    // Noise is below cutoff, reset counter
//    delayCountTRSTChange = 0;
//  }
//}

The specific unresolved identifires are

TRST_NOISE_THRESHOLD, TRST_DELAY, TRST_ARRAY_SIZE, CSLIB_TRST, TRST_NOISE_EST_RESET

It this any function in hardware_routines.c. I seem to have been able to get it to compile by removing the code and there are no linker errors so it looks like it's not used. Note I have also removed CSLIB_TRST [] from hardware_config.c

/**************************************************************************//**
 * Change TRST value based on noise estimation
 *
 * When system-wide noise is above threshold for more than TRST_DELAY LDMA
 * interrupts, switch to a new TRST setting and reset noise value.
 *
 *****************************************************************************/
//static void CSLIB_TRSTSwitchIfHighNoise(void)
//{
//  static uint8_t delayCountTRSTChange = 0;  // number of scans with noise above cutoff
//
//  if ( CSLIB_systemNoiseAverage > TRST_NOISE_THRESHOLD ) {
//    // Increment counter
//    delayCountTRSTChange++;
//    // If counter above change threshold
//    if ( delayCountTRSTChange > TRST_DELAY ) {
//      // Reset counter
//      delayCountTRSTChange = 0;
//      // Swap to new TRST setting
//      indexTRST++;
//      indexTRST = indexTRST % TRST_ARRAY_SIZE;
//      sleep_mode_default.resetPhase = CSLIB_TRST[indexTRST];
//      active_mode_default.resetPhase = CSLIB_TRST[indexTRST];
//
//      if (TRST_NOISE_EST_RESET) {
//        CSLIB_initNoiseCharacterization();
//        noise_level = mid;
//      }
//    }
//  } else {
//    // Noise is below cutoff, reset counter
//    delayCountTRSTChange = 0;
//  }
//}

The specific unresolved identifires are

TRST_NOISE_THRESHOLD, TRST_DELAY, TRST_ARRAY_SIZE, CSLIB_TRST, TRST_NOISE_EST_RESET

I had a similar problem with pre and post build absolute paths making collaboration hard. 

I fixed it as follows

Fixing the pre and post batch file launch command.

Go to Project->properties->C/C++ Build->Settings->Build Steps and add the following…

…to pre-build step

cmd //c '${ProjDirPath}/iTRVZ3-prebuild.bat' '${BuildArtifactFileBaseName}' '${ProjDirPath}' '${TOOLKIT_DIR}' '${eclipse_home}'

…to post build steps:

cmd //c '${ProjDirPath}/iTRVZ3-postbuild.bat' '${BuildArtifactFileBaseName}' '${ProjDirPath}' '${TOOLKIT_DIR}' '${eclipse_home}'

However it kept changing it back on re-generation, so we ended up specifying the development path,

I think I've found the answer:
Reading through the ZCL spec. thermostat cluster (0x0201), temperature attribute (0x000) and pi heating demand (0x0008) both have reporting access as mandatory. Looking in configurator, reporting tab of the thermostat cluster, local temp and pi heating demand are both enabled. 

I think I've found the answer:
Reading through the ZCL spec. thermostat cluster (0x0201), temperature attribute (0x000) and pi heating demand (0x0008) both have reporting access as mandatory. Looking in configurator, reporting tab of the thermostat cluster, local temp and pi heating demand are both enabled. 

If they re-appear if you  power off and on again, I think they are kept in simulated eeprom

That was something I considered, which is why I tried erasing the whole chip and re-programming.  

What do you mean “They are removed when I run the plugin commands”?

Sorry, that wasn't that clear. On the ZED, i can delete the reports using CLI commands:-

>plugin reporting print

00:ep 01 clus 0201 attr 0000 svr y report min 0001 max FFFE rpt-chg 00000000
01:ep 01 clus 0201 attr 0008 svr y report min 0001 max FFFE rpt-chg 00000000
02:
03:
04:
05:
06:

>plugin reporting clear 

>plugin reporting print

00:
01:
02:
03:
04:
05:
06:

I've created a sleepy end device and and router / coordinator using stack EmberZNet 6.6.1.0.
I'm using the reporting plugin.

Working through the CLI of the coordinator I've set up bindings and reports, and these appear to work

zdo bind 0xED27 1 1 0x0201 {086BD7FFFE016330} {000B57FFFEA788B9}

zcl global send-me-a-report 0x0201 0x0012 0x29 0 20 {00 00}
send 0xED27 0x01 0x01

However, I now have 2 reports on the ZED that I can not delete using the CLI command plugin reporting clear or plugin reporting remove n.

plugin reporting print (args)

 - Print the report table.
00:ep 01 clus 0201 attr 0000 svr y report min 0001 max FFFE rpt-chg 00000000
01:ep 01 clus 0201 attr 0008 svr y report min 0001 max FFFE rpt-chg 00000000

They are removed when I run the plugin commands, but re-appear if I power off and on again. 

I've tried erasing and re-programming both the end device and the coordinator, but this doesn't fix the problem (I was thinking that maybe the simulated eeprom may have become corrupt).

I am unsure how I got to this stage, but I can add and remove new reports, but I am always left with the above 2. 

Where am I going wrong?

I've created a sleepy end device and and router / coordinator using stack EmberZNet 6.6.1.0.
I'm using the reporting plugin.

Working through the CLI of the coordinator I've set up bindings and reports, and these appear to work

However, I now have 2 reports on the ZED that I can not delete using the CLI command plugin reporting clear or plugin reporting remove n.

plugin reporting print (args)

 - Print the report table.
00:ep 01 clus 0201 attr 0000 svr y report min 0001 max FFFE rpt-chg 00000000
01:ep 01 clus 0201 attr 0008 svr y report min 0001 max FFFE rpt-chg 00000000

They are removed when I run the commands, but re-appear if I power of and on again. 

I've tried erasing and re-programming both the end device and the coordinator, but this doesn't fix the problem.

I am unsure how I got to this stage, but I can add and remove new reports, but I am always left with the above 2. 

Where am I going wrong?