user-1: I am looking for ideas on how to connect 12 sensors to an Arduino wirelessly.  The sensors will be about 10ft from the Arduino.  They need to send one byte of data every 100ms-250ms to the Arduino in an organized manner.

I have investigated MQTT and pubsubclient, but have not found a way to make an Arduino a Broker, and have been told it is very inefficient for my application.
I have looked at NRF24L01, but it appears to be limited to just 6 pipes to receive data in an organized fashion.
I researched Xbee, but have been told that it cannot keep up with the data rate.

Other suggestions are appreciated...  Thank you.

user14737: It might be easiest to send a UDP packet over WiFi.  There is no extra packet overhead for this "connectionless" protocol: no OPEN, no ACK/NAK, no CLOSE, etc.  The incremental cost for additional bytes is very small, so if you decide you need to send 2 bytes, or even 100 bytes, it won't affect the throughput very much.
If you can "batch" the bytes, that would be even better.  For example, could you send 8 bytes per node, once every 800ms-2000ms?  If not, WiFi speeds should allow the single-byte UDP packet to get through without much latency.  Do you know what latency the receiver can accommodate?  You might get lower average latency with batched packets, depending on the network access time (i.e., how long it takes to hop on to the air).
A roll-your own approach would be to use a raw RF transmitter/receiver with something like VirtualWire.  With proper synchronization from the "master", the slaves could each have their own time slot, avoiding collisions (which keeps the network access time low)

user18600: Use nRF24L01. To avoid collisions you can query the sensors (as Chris suggested in comment).
The setup would be:
Each sensor would have unique address. Central unit would transmit request and sensor node would respond to it. Central unit would have different address and all sensors would transmit to that address. You can also use data in ack to pack response.

Central node (Addr0) -> Sensor 1 (Addr1): Request
Sensor 1 (Addr1) -> Central node (Addr0): Response, sensor data
Central node (Addr0) -> Sensor 2 (Addr2): Request
Sensor 2 (Addr2) -> Central node (Addr0): Response, sensor data
Central node (Addr0) -> Sensor 3 (Addr3): Request
Sensor 3 (Addr3) -> Central node (Addr0): Response, sensor data
...


user4143: I would recommend the nRF24L01.
You don't need one pipe per node - just one pipe. 
Each pipe is effectively an address that a node responds to - having multiple pipes means you can have multiple addresses on one node (like aliases) - but of course you only need one address per node, and hence one pipe per node.
The range is more than adequate (with the antenna version I have managed to get hundreds of meters no problem) and the price is so low as to be negligible.

-1: <p>I am looking for ideas on how to connect 12 sensors to an Arduino wirelessly.  The sensors will be about 10ft from the Arduino.  They need to send one byte of data every 100ms-250ms to the Arduino in an organized manner.</p>

<ul>
<li>I have investigated MQTT and pubsubclient, but have not found a way to make an Arduino a Broker, and have been told it is very inefficient for my application.</li>
<li>I have looked at NRF24L01, but it appears to be limited to just 6 pipes to receive data in an organized fashion.</li>
<li>I researched Xbee, but have been told that it cannot keep up with the data rate.</li>
</ul>

<p>Other suggestions are appreciated...  Thank you.</p>
 14737: <p>It might be easiest to send a UDP packet over WiFi.  There is no extra packet overhead for this "connectionless" protocol: no OPEN, no ACK/NAK, no CLOSE, etc.  The incremental cost for additional bytes is very small, so if you decide you need to send 2 bytes, or even 100 bytes, it won't affect the throughput very much.</p>

<p>If you can "batch" the bytes, that would be even better.  For example, could you send 8 bytes per node, once every 800ms-2000ms?  If not, WiFi speeds should allow the single-byte UDP packet to get through without much latency.  Do you know what latency the receiver can accommodate?  You might get lower <em>average</em> latency with batched packets, depending on the network access time (i.e., how long it takes to hop on to the air).</p>

<p>A roll-your own approach would be to use a raw RF transmitter/receiver with something like VirtualWire.  With proper synchronization from the "master", the slaves could each have their own time slot, avoiding collisions (which keeps the network access time low)</p>
 18600: <p>Use nRF24L01. To avoid collisions you can query the sensors (as Chris suggested in comment).
The setup would be:
Each sensor would have unique address. Central unit would transmit request and sensor node would respond to it. Central unit would have different address and all sensors would transmit to that address. You can also use data in ack to pack response.</p>

<ul>
<li>Central node (Addr0) -> Sensor 1 (Addr1): Request</li>
<li>Sensor 1 (Addr1) -> Central node (Addr0): Response, sensor data</li>
<li>Central node (Addr0) -> Sensor 2 (Addr2): Request</li>
<li>Sensor 2 (Addr2) -> Central node (Addr0): Response, sensor data</li>
<li>Central node (Addr0) -> Sensor 3 (Addr3): Request</li>
<li>Sensor 3 (Addr3) -> Central node (Addr0): Response, sensor data</li>
<li>...</li>
</ul>
 4143: <p>I would recommend the nRF24L01.</p>

<p>You don't need one pipe per node - just one pipe. </p>

<p>Each pipe is effectively an address that a node responds to - having multiple pipes means you can have multiple addresses on one node (like aliases) - but of course you only need one address per node, and hence one pipe per node.</p>

<p>The range is more than adequate (with the antenna version I have managed to get hundreds of meters no problem) and the price is so low as to be negligible.</p>
