BLE vs Wi-Fi for IoT/HTTP? Moderators: adafruit_support_bill, adafruit

[JWaymond]

Hello. I've been advised that reading from an io.adafruit.com output feed is possible with only a BLE device (e.g., nrf52840) paired with the Bluefruit Connect app using the MQTT protocol. This would, theoretically, be doing an HTTP GET request. However, could someone suggest what class/module I need to build the host around (in CircuitPython, btw)? Or, is it more efficient to simply strap an Airlift (a.k.a. esp32) on top of the Feather and call it a day?

[adafruit_support_mike]

I've been advised that reading from an io.adafruit.com output feed is possible with only a BLE device (e.g., nrf52840) paired with the Bluefruit Connect app using the MQTT protocol.

That’s either incorrect or makes assumptions that aren’t relevant in general. Adafruit.io is an online service, so you can read feeds directly from Wifi.

[JWaymond]

OKay, Airlift it is. Thanks.

[ericwertz]

AdafruitIO is simply an HTTP service. It doesn't know or care where the data is going to or coming from -- a phone with internet connectivity, a desktop/laptop running with an internet connection, or an IoT device with a TCP/IP connection (usually via WiFi or Ethernet) to the internet. As you know, an AirLift is one way to get to the internet from your nRF.

Another viable alternative is to BLE to a device with internet connectivity that acts as a proxy. This proxy could be a phone or a desktop. This offloads the internet connectivity from the IoT device to another device that has it already. The IoT device could send HTTP requests over the BLE Serial channel to the internet-connected device, which just HTTPs them over to AdafruitIO (or whereever else), and hands the returned data back to the IoT device.

An even smarter proxy could take higher-level requests over BLE from the IoT device, make the URL out of it and do whatever it needs to do to retrieve and filter/mangle the returned data and return what little it needs to back the IoT device. So, for instance an nRF Feather could send "temp 95112" to the phone over BLE, and a proxy program on the phone reads the BLE serial data, makes the right URL to get the right data from weather.com for the specified zip code, parses the returned data and simply returns "68" to the IoT device. The same type of compression could be done for a proxy designed to talk to AdafruitIO. If you don't care about optimizing for the local data transfer, just send the whole URL from the IoT device to the proxy, have it do the HTTP request, and funnel the entire HTTP response back over BLE serial to the IoT device. Not optimal, but general-purpose for sure.

It all depends on how you want to partition the work between the IoT device and the proxy program. It's "just" a matter of writing a program that takes BLE serial in and sends HTTP out, and then returns the HTTP response data back over BLE Serial to the constrained device.

Very doable. In fact I just came to the Forum here to see if anyone else had done the same thing already, otherwise I'll probably do it myself "eventually" (hopefully before the end of the semester).

Note that you don't even have to have BLE to do this. You could use the wired virtual com port over the USB cable to do something similar with a QTPy, but of course you'd be tethered to a PC-like device.

The "easiest" solution is to just go WiFi with an Airlift, if you're willing to get more hardware. But you can certainly do "the proxy thing" already with the hardware you've got if that fits your use case. You can imagine pushing data onto a Bluetooth mesh someday and having that one proxy server a buttload of IoT devices that only have BLE on them. Or LoRa, or anything else for that matter. That's kind of the classic "gateway" architecture. More complexity, but scalable cost-wise.

regards

[JWaymond]

@ericwertz Thanks for the informative input. After trying to communicate with IO via BLE/nrf only, I concluded that publishing to a tx feed is totally possible using the MQTT feature in the Bluefruit app. However, subscribing to an output feed in a similar manner doesn't seem possible, because the Bluefruit app doesn't have a "peripheral" mode. Maybe it used to but I don't see it. Granted, I'm also using Circuit Python. So, maybe there's a way to achieve this with Arduino/c++, which may be what you're describing, but it's above my skill set. Though, I wish you the best of luck with your project though. Feel free to keep me posted.

[ericwertz]

I believe seeing in one of the pages that the Blinka/BLE code (and probably the Connect app) only work as a Central node.

There's no reason that the proxy couldn't be written in Python as a desktop app. But being able to extend the Connect app would require working on it in whatever language it was written in. The theoretical advantage of using Blinka/BLE should be that it's more portable, since ostensibly someone else already took care of dealing with the platform-dependencies in the library so that you don't have to.

Good luck!
-e