You cannot (easily) have all nodes on the network with the same address.
There are ways of doing it but they aren't easy. They basically involve creating a "broadcast" facility in your network, and that has certain caveats involved with it.
The nRF24L01 modules have an "auto-ACK" mode to give reliable communications. This only works with 1:1 addressing and cannot work with broadcast. If you want to (as most people do) use the auto-ACK facility then you have to have each node with its own unique address. After all, if you're sending the ACK to a station, and there are multiple stations with that address, which one will ACK?
So you have to think about if what you are trying to achieve is really the right way of going about it. It sounds like you want to just program another node with the same code as an existing node without making any changes to that code and "just have it work". That's a very advanced topic and one that even I would spend quite some time implementing it. Yes, you can do unreliable communications (i.e., no auto-ACK) then you could have all the remote stations with the same address, but I would certainly keep the master as a unique address. Better would be for each node to start up with a pre-defined address which it then uses to ask the master for a unique address (a-la DHCP) and the master then keeps a list of what is connected on what address. From then on it can use reliable communications to send and receive data to each node as it needs to.
A system I wrote for the chipKIT boards gives each node two addresses - its own unique address which you have to provide manually, and a more global "broadcast" address. They are each on different pipes within the nRF24L01. To communicate with an individual node you send to its unique address. To broadcast to all nodes you send to the broadcast address. If you're sending to the unique address you can then turn on auto-ACK. If you're sending to the broadcast address you don't turn on auto-ACK.
Note that using auto-ACK is a whole topic in itself and requires careful design planning to get it to work properly.
Also you have to think about what happens when you send a broadcast packet out and it's received by other nodes - how do they handle that data? Sending temperature data out globally, it will be received by the RGB receiver, which may try and interpret it, causing problems. You need to come up with a way of identifying just what it is you're sending out and only having the right nodes responding to the right data. That means coming up with a strict packet format. Luckily the nRF24L01 chips communicate in fixed packet sizes (incidentally, all nodes on the network will have to be set to use the same packet size or it just won't work) up to 32 bytes, so implementing a packet structure over that is easy enough. Just sending strings of data is both hard to interpret and incredibly inefficient. You should be sending the data as actual data values in variables as part of the packet structure.
The 1st node
The 2nd node
