@speechsupply You may be right - pages like the arduinoinfo site are never perfect. But it's a wiki and it seems not to be limited to nRF but also contains some other arduino related stuff beside the official arduino.cc site. So feel free to add further info (after the necessary validation) to that wiki .
Then there's the troubleshooting and debug guide also containing a lot of standard issues: https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help

Imo, there's no need to open up another channel, it's better to enhance the existing ones (and leaving out exotic stuff not properly tested).

Just my2ct.

I personally found a lot of useful information about nRF24-usage here: http://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo
(Moved from arduinowiki).

There's a lot of info, the only thing that's missing is how to identify counterfeid chips.

It should also work on a 3.3V pro mini and as is works for some time at least, there seems not to be a general problem with the sketch.

Some times, you might have buffer overflows in case you get really a lot of data from your network, so increading buffer size on the gw could help (no own experience, standard may be something like 20 messages).

But as I don't have much experience on usage of PI GPIO (I preffer using Mysensors Nodes when GPIO's are needed), I may not be able to help you any further. As a general remark, drawing power from a PI is very often "the root of all evil", so I'd recommend to avoid that whenever possible. But that's personal opinion, not proofed knowledge.

@skywatch I'd first have a look at your USB-Serial converter. Enough power @3.3V? FTDI with tesp-pin not connected to GND?

When using nRF24, imo there's no need for a level converter (beside having a stable 3.3V source to power the nRF), so using a normal Nano should'n be an issue.

Imo the "right choice" also depends a little on your controller software. As a first try, I'd go for S_COVER; this allows direction info and percentages. You may combine it with a S_DOOR type for direct indication of open/closed (in case of pure S_COVER derive info from percentage values).

Have a look at https://www.mysensors.org/download/serial_api_20 on what MySensors offers and also a look how your controller handles the different types.

Despite beening not familiar with any of the mentionned controllers, having multiple serial GW's seems not to be a big issue imo.
Atm, I'm running 7 USB-connected IO devices (4 of them for MySensors) on FHEM without trouble. The only point to keep in mind is how to address all these devices and not to mess things up. To achieve this, I just address all of the GW's with their "/dev/serial/by-id/<identifier>" path.
So when buying Arduinos, don't use more than one with CHG340 USB-serial converters (often to be found on the cheap chinese Nano clones) but chips that can be identified by an individual serial number (may need some more work in case of e.g. CP2102 chips that come by default without serial number but can easily be programmed).

@alowhum AFAIK, now the order of execution is preHwInit(), before(), presentation() and setup(), then loop().
As you may call the presentation function to be redone from controller side you should decide whether this is desired or not; depends on your needs imo.

Personally, I prefer having all kind of controller-independent initialisation in before() (especially turning relays off/desired state and so on; this allows also to use additional SPI stuff on hardware SPI PINs), put all controller-communication stuff in presentation() and the other things in setup(). For e.g. asking acutal values of counters setup() might be a good choice, as one typically want to do that only once after node has started.

@tbowmo Thx for clarification.
As I only use serial GW's, I didn't notice the difference until now.

@Tubes110
Using a Mega should not be a big issue.

Wrt. to using the MySensors framework without Controller you might look for "node to node communication" in the forum.
A good starting point imo (starting with this posting): https://forum.mysensors.org/post/84724

You have to configure all nodes with

#define MY_TRANSPORT_WAIT_READY_MS 100

as if the controller is not present, the nodes won't enter loop() (100 may be changed).

Would be keen to see your final code; I'd like to bridge ebus communication to MySensors , so your code could help to some extend.

Question: First all worked well, until you added the code for the DHT?
IMO, the

// Sleep for a while to save energy
  wait(UPDATE_INTERVAL);

part blocks the entire code for most of the time. You should instead use a non-blocking loop structure using millis(). See the https://www.mysensors.org/build/pulse_power example (follow the path, when "#define SLEEP_MODE true" is used).