Should you go straight to your wifi router with your IoT devices, or should you have an IoT gateway?  What to consider…

Currently, almost everything we do is designed around using a Rasbperry Pi as an IoT gateway that attaches to the internet through an ethernet cable, and talks to end devices through XBee radios.  We do it this way for range and for reliability.  But with the likes of the ESP8266 and ESP32 out there, XBee radios and the Raspberry Pi gateways look a little expensive.  The decision to use an gateway is not an easy one to justify.  Not only do you add cost, but you add the number of components used (and boxes that need to be assembled, power cords that need to be ordered, etc.).  So, why do it?

With the Pi at ~$40 and XBees now at ~$20 (you need at least two), you will pay about $100 more to get the benefits of a connected gateway.  For us, it’s worth it.  But not for every situation.  Here’s what we have to consider each time:


Wifi is often good.  But ethernet pretty much works all the time.  If you are chasing 100% fidelity (whether you actuall get it or not), then go with the ethernet-connected gateway.  IoT Gateway

The first OhioIoT project (the Halmidor) was saved when we realized we could fix our wifi issues by simply plugging our Pi gateway into the router.  In a cigar bar in Seoul, South Korea, an Arduino was monitoring the inside of a humidor, and talking through wired serial communication to a Raspberry Pi, which was in charge of maintaining a wifi connection to our server.  Despite a successful mock-up at our apartment, the box just wouldn’t connect to the wifi at the bar.  We never found out why.  But with two XBee radios in the tackle box, we plugged the Pi into the router upstairs and replaced the wired link with radios.

You can still get live data from this device, operating two years later, at

Local Functionality

A gateway is a place where you can drop some localized code.  I find the new buzz around edge computing to be slightly awkward.  I think of edge computing as computing.  It’s only if you come from a place where everything has to go to the internet that you find it profound to discover that computing can be done not in the cloud.  Nothing wrong with some work that doesn’t include cloud hits.


For some use cases, delays of even a few hundred milliseconds don’t feel right (think, lights turning on in a dark room after you have entered and triggered a motion detector).

Socket connections ( in javascript) are fairly instant.  But MQTT and standard REST requests are a different story.  And, remember that an ESP needs to successfully confirm its wifi connection before it can send.  Going to the internet for everything can slow things down.

XBee to edge device round trips are about 20ms, so if your logic is on the gateway, the system’s reaction times are imperceptible.  If speed is critical, you’ll want to process some decisions at the gateway.


It’s debatable whether or not IoT has a security problem as many people claim. The problem is only when people just actually don’t implement security.  But when proper security measures are taken, IoT doesn’t have any more of a problem than any other vertical.

But regardless, it will always remain true that a cloud hacker cannot access data that is not in the cloud, so… When security is that one step more important, or you don’t have tangible reasons to send everything to the cloud, then why not develop your app on the gateway, and send only relevant bits to the cloud?  As you add the number of end devices, this will have cost implications as well.

Server Cost

When you have a scaled-up implementation, you can have hundreds of data points coming in every minute.  I do at my home.  Those don’t all need to go to the cloud.  You can do some averaging locally, and then send processes packets at one time in a single report to your server.  If every piece you are ever collecting goes up, at some point your server costs will start to drift higher as well.  Some conditions require immediate reactions, so I have edge devices reporting every couple of seconds.  But the reports on any decisions made only need to get to the cloud every 30 seconds.  A gateway helps to smooth this flow.


SSIDs and passwords don’t change all the time.  But they do get changed occasionally for whatever reason.  When they do, you’ll need to reset the SSID and password on each of the devices in your location.  If that is twenty devices, you’re obviously not going to enjoy the transition.

If devices are on a radio connection, they are unaffected by any changes to the internet setup.


If you are building for yourself, you can hardcode the SSID and password, make sure it’s working, and tweak things if they don’t.  If it’s a matter you creating something for yourself, there are very few excuses for why you should start with a gateway and radios.

But what if you are you creating something that might be distributed?  If you are distributing your devices, you are at the mercy of that location’s wifi.  And if the wifi connection doesn’t work, you’ll probably be fielding the phone call.

One last advantage of a Ethernet-connected gateway is that it will work exactly the same, no matter where you put it, whereas the intricacies of different wifi setups may cause problems as you share your technology.



If you are simply attaching a sensor or actuator to the internet, a lot of this talk of IoT gateways and radios probably just feels like more homework for the sake of homework.  And I would avoid that.  But if you are considering a system that is long-term, expected to grow, and focused more on reliability than cost, I would still point you towards the gateway.

Of course, one has to acknowledge the inroads made by the ESP8266, and now the ESP32.  In fact, we are currently converting a lot of our early devices to ESPxx platforms to make them more cost effective from a consumer point of view.  But it’s still new territory.  You’re comments are welcome if you can comment on a history of success with these devices.  Maybe I’ll be espousing the ESPxx’s like every else in a few months, once we establish a good track record.

But until then, our IoT gateway will be enjoying a bit of job security.