May 17, 2026

DNS Africa Resource Center

..sharing knowledge.

Building a LoRaWAN -> Wi-Fi -> Cellular Fallback IoT Device – Hackster.io

Add the following snippet to your HTML:
Using the Blues Notecard LoRa, along with a Cellular + Wi-Fi Notecard, allows you to build a bulletproof wireless connectivity device.
Read up about this project on
Using the Blues Notecard LoRa, along with a Cellular + Wi-Fi Notecard, allows you to build a bulletproof wireless connectivity device.
As ubiquitous as cellular networks, public Wi-Fi access points, and even LoRaWAN gateways are becoming, there is still no “one size fits all” when it comes to wireless IoT deployments. Unfortunately, when designing a product, we are often forced to pick a single Radio Access Technology (RAT), like one of the above, before any other work can start.
Why is this a problem?
At the end of the day, I might argue that we shouldn’t have to care about whether we are using LoRa or Cellular or Wi-Fi or Zigbee…we just want to get the dang thing connected!

This is why the Blues Notecard is such a breath of fresh air. By using a single JSON-based API and building around one form factor, you can design your product without fear of switching from Cellular, to Wi-Fi, to LoRa (and back again). You can even deploy the same product with different RATs, without changing a single line of code.

There’s the freedom of picking ONE of Cellular, Wi-Fi, or LoRa, but what if I want to use them all!?
Today I want to show you a scenario where we build a single product that has the ability to:

We are going to be using the following hardware:
The Notecard slots into the Notecarrier:
…to…
And the Notecarriers can even stack on top of each other on the Pi:

The Notecard is, by default, a low power and “occasionally connected” device. With ~1MB of user-addressable flash on the Notecards, you can store A LOT of data before the Notecard needs to sync its data with the cloud. This allows battery-powered, asset tracking, and condition monitoring solutions that can’t be continuously connected.
To be clear, the Notecard isn’t meant to be a drop-in replacement for Wi-Fi. It’s a low-bandwidth device that lets you send individual JSON-based events (or Notes in Blues lingo) that contain key-value pairs. For example:
The Notecard also knows exactly where to go as soon as it’s powered up. You don’t have to manage security or rotate keys with the Notecard, everything is handled for you and data is streamed securely from the device to the cloud.
On the cloud side, the Blues Notehub acts as the “hub” of data. From Notehub you can route your data to any cloud platform like AWS, Azure, Datacake, Ubidots, or your own custom HTTPS or MQTT endpoint.
Notehub handles everything for you. It takes all the headaches out of orchestrating your own infrastructure for merging wireless connectivity with cloud connectivity.
It’s important to note that communication with the Notecard is bi-directional in nature, so you can initiate an event on your cloud, deliver that to Notehub using the Notehub API, and Notehub will securely send that event to one or more Notecard devices (allowing for remote control or remote updating scenarios).

With those high-level concepts in mind, let’s see how to actually build out this LoRa -> Wi-Fi -> Cellular communication device.
When building with the Notecard LoRa, it’s important to consider it as the “lowest common denominator” of Notecards. Anything you can do with the Notecard LoRa you can ALSO do with the Notecard Cell+WiFI. But the opposite is sometimes not true. There are higher bandwidth activities and location-tracking scenarios that are easily handled with Cellular or Wi-Fi, but not so much with LoRa. Suffice it to say, it makes sense to start with LoRa!

Since we are connecting to both Notecards over I2C, they both can’t have the same I2C address of 0x17 (which is the Notecard default). This is easily handled using the card.io API, which lets us set one of them to a new address of 0x18:

Once that command is sent to one of the Notecards, we can start programming the Python script. Create a new file, say main.py, on your Raspberry Pi.
Since both Notecards are sharing the same I2C bus, we simply have to pass the I2C address of each Notecard in our code:

Next we need to issue a command to the Notecards that tell them which project in Notehub to connect to. A “project” is just what you think it is, it’s a collection of one or more Notecard devices and provides a logical way to organize events and route them to your cloud endpoint.
Here is an example of some Notehub projects in my account:
Back in main.py, use the hub.set command on EACH Notecard, specifying a different sn (a “serial number”) so we can identify the two Notecards when they start syncing data with Notehub:
You’ll have to specify your own productUID (the unique identifier of your Notehub project).

The next setup task is to make sure the appropriate Wi-Fi credentials are applied to our Notecard Cell+WiFi. Using the card.wifi API, we can specify the SSID and password required:
FYI, take a look at this article by TJ VanToll for an example of how you might use multiple Wi-Fi access points in one project.

A Note template acts as a hint to the Notecard that allows it to internally store data as fixed-length records rather than as flexible JSON objects, which tend to be much larger. This not only saves storage on the Notecard, but also saves bandwidth when syncing data with the cloud. Templates are also required when working with the Notecard LoRa.
Again, on each Notecard, make sure we are creating the same template. In this project, we’re just sending an arbitrary value like the registered voltage on the Notecard, but this could be ANYTHING!
Here is our code for creating that Note templates:

Again, this project is keeping things pretty simple. And to extend that, we need some data to send to the cloud, so let’s query the Notecard to get a voltage value from the power source:

Recall that the order of our connectivity preferences is:
So let’s create our first Note and try to send that with the Notecard LoRa. Send this request to the Notecard LoRa with the note.add API:
Now comes the tricky part. If the Notecard is an “occasionally connected” device, at what point do we agree that the data has been sent or not? In this scenario, we are going to use the (optional) sync argument, which tells the Notecard to try and immediately sync this data.
We can then use the hub.sync.status API after the above note.add request was sent! This API allows us to see the status of the most recently-sent Note.
Did it work? Well we can check Notehub to see if that voltage data appeared:
Great! Project done!
Well, let’s now disconnect my personal LoRaWAN gateway and then see what happens in a hub.sync.status request:
Uh oh. Unfortunately we are impatient and since “sync in progress” is going on past one minutes it’s time to fall back to Wi-Fi!

Since we are moving from one Notecard device to another, we first want to delete the Note on the Notecard LoRa, because we don’t want it to get sent later should that LoRaWAN gateway come back online.
Using the file.delete API, we can clear the Note from the Notecard LoRa:
Now, let’s create a new Note for the Notecard Cell+WiFi (same as the original note.add request) and again give it a couple minutes to connect. Here is the complete code block:
By default, the Notecard Cell+WiFi will try to use Wi-Fi first. Again using the hub.sync.status API, we can see if the Note was delivered:
Oh no, Wi-Fi isn’t working!
But here’s the beauty of using the Notecard Cell+WiFi – the fallback capability to cellular is AUTOMATIC. There is nothing we need to do. The Notecard will detect that Wi-Fi isn’t working and within about a minute will initiate the cellular radio to connect to the nearest cell tower and deliver the data:

Back in Notehub, we can look at one of the event details to see how the data comes through (this will effectively be the same whether it was delivered over LoRa, Wi-Fi, or Cellular):
In fact, you can drill into the Session data from a Notecard event to see the RAT that was used (unfortunately this information isn’t available for Notecard LoRa though).
Now what? With data synced with the cloud, the next obvious step is to route that data to your cloud endpoint. In your solution, you’ll probably want to use one of the aforementioned cloud providers. And luckily there’s probably a guide for you!

Learn more about the Notecard API and discover other Blues technical resources on blues.dev. Otherwise if you’re ready to get started, grab your own Blues Starter Kit OR if you’re looking to follow this project exactly, you’ll need the Notecarrier Pi Hat along with the Notecard Cell+WiFi, and Notecard LoRa.
Happy Hacking with Blues! 💙
Hackster.io, an Avnet Community © 2024

source

About The Author