Then you try to connect one more thing. Maybe a fitness band, a smart lock, or that tiny temperature sensor you ordered online because it was on sale. That is when the charm fades and reality walks in. Suddenly the connection drops, your phone cannot find the device anymore, and the once-friendly Bluetooth logo on your screen starts to feel like a taunt. You restart, you unpair, you try again, and somehow it only gets worse. What was once effortless turns into a puzzle with no clear solution.

Here is the secret that few people know: Bluetooth was never meant to handle the chaos we put it through today. When engineers designed it in the late 1990s, they imagined a world of simple one-to-one connections. A laptop talking to a mouse. A phone connecting to a headset. That was the whole idea. Fast-forward to the present and we are using the same technology to run entire networks of wearables, sensors, and smart appliances. We ask it to connect not just one or two devices but sometimes dozens of them at the same time, each running on different hardware and software. It is a miracle that it works at all.

To make things even more interesting, these devices live in very different worlds. Android devices are like an open playground where every manufacturer adds its own slide and swing set. iPhones live inside Apple’s carefully fenced garden where everything is polished but also tightly controlled. Embedded devices, like the ones built on tiny chips inside sensors or IoT boards, are the quiet introverts of the group. They have little memory, tiny batteries, and a strong preference for naps to save power. Getting all three to cooperate is a bit like trying to organize a band where one member only plays jazz, another insists on classical, and the third speaks in Morse code.

That is what engineers mean when they talk about scaling Bluetooth. It is not just about adding more devices. It is about making sure completely different systems can talk to each other reliably and continuously without draining their batteries or losing their minds. It requires design decisions that consider timing, power management, data formats, and even how the operating system schedules background tasks.

This article will guide you through that strange world. We will peel back the layers of how Bluetooth actually works and what happens when Android, iOS, and embedded devices try to share the same airwaves. We will explore why each one behaves the way it does and what you can do to build systems that stay connected instead of collapsing under their own complexity.

By the end, you will see that Bluetooth is not really broken. It is simply overworked. It is a polite translator trying to keep three very different languages in sync. Once you learn how to manage its quirks and give it the structure it needs, Bluetooth becomes not a source of frustration but a quiet, invisible network that holds the modern world together.

Table of Contents

• Bluetooth Has Two Personalities — Meet Classic and BLE

• Android, iOS, and Embedded Devices — The Odd Trio

• Architecting for Scale — Herding Cats, but Wirelessly

• Connection, Discovery, and Data Flow — The Bluetooth Dating Game

• Platform Quirks — And How to Stay Sane

• Security and Privacy at Scale

• Power and Performance Tuning

• Provisioning and Firmware Updates — Welcome to Device Kindergarten

• Debugging, Monitoring, and Testing Across Platforms

• Real-World Architecture Example — When Bluetooth Finally Behaves

• Checklist — Building a Truly Scalable Bluetooth System

• Wrap-Up — Lessons from the Field

Bluetooth Has Two Personalities — Meet Classic and BLE

Before we can talk about scaling Bluetooth, we have to understand that Bluetooth itself has a bit of an identity crisis. It actually comes in two flavors: Classic Bluetooth and Bluetooth Low Energy, also called BLE. They share the same name and sometimes even live on the same chip, but under the hood they behave very differently. Think of them as twins who went to completely different schools and now have opposite personalities.

Classic Bluetooth is the older sibling. It was designed for steady, high-speed data streams. This is the version your headphones, speakers, and car systems use. It is reliable for sending large amounts of data like audio, but it is also chatty and power-hungry. It likes to stay connected all the time, constantly keeping the line open so it can send sound packets smoothly. You could say Classic Bluetooth is like that one friend who calls instead of texting and keeps the conversation going even when there is nothing left to say.

Then there is Bluetooth Low Energy, the younger, more introverted sibling. BLE was designed for devices that need to last for weeks or months on tiny batteries. It does not keep a constant connection open. Instead, it wakes up, sends or receives a little bit of data, and then goes back to sleep. It is the protocol behind fitness trackers, heart rate monitors, smart locks, and most modern IoT devices. If Classic Bluetooth is a full-time conversation, BLE is more like sending quick text messages throughout the day, short, efficient, and battery-friendly.

The funny thing is that even though they share the same wireless spectrum and sometimes even the same antenna, these two modes do not talk to each other directly. A BLE device cannot communicate with a Classic Bluetooth-only device. This is why your wireless headphones can pair with your phone, but your BLE heart rate monitor cannot talk to your old Bluetooth speaker. They live in the same neighborhood but never attend the same parties.

Most of the world’s scaling problems come from BLE, not Classic Bluetooth. Classic has been around long enough that its use cases are stable and well understood. BLE, on the other hand, is used in thousands of different kinds of devices, each with different timing requirements, power limits, and operating systems. When you try to make Android, iOS, and embedded systems all use BLE together, you are juggling three slightly different interpretations of the same rulebook.

To make things trickier, each platform implements BLE its own way. Android exposes it through flexible but sometimes unpredictable APIs. iOS keeps it tidy under Apple’s strict Core Bluetooth framework. Embedded devices rely on lightweight vendor stacks that can vary from chip to chip. Every one of these stacks follows the same Bluetooth specification, but like recipes written by different chefs, the results can taste a little different.

Understanding this dual nature is key to building anything that scales. You must know when to use Classic Bluetooth for high-speed continuous data, when to use BLE for low-power bursts, and how to design your system so that the right devices use the right mode. It is the first step in turning Bluetooth from a confusing mystery into a reliable network you can actually control.

Android, iOS, and Embedded Devices — The Odd Trio

Now that we know Bluetooth has two personalities, let’s meet the three characters that make scaling it so complicated: Android, iOS, and embedded devices. They all speak Bluetooth, but in their own unique accents. Sometimes they understand each other perfectly, and other times it feels like they’re arguing in three different languages while pretending they’re on the same page.

Let’s start with Android. Android is the enthusiastic extrovert of the group. It gives you tons of control and freedom. You can scan, connect, advertise, read, write, and basically poke around every corner of the Bluetooth stack. But that freedom comes with chaos. Because Android runs on phones made by dozens of manufacturers, each one tweaks the Bluetooth implementation a little differently. On one phone, everything works flawlessly. On another, the same code randomly drops connections or refuses to scan in the background. Even Android engineers joke that if your Bluetooth works the same on every device, you’ve probably entered a parallel universe.

Android is powerful but unpredictable. It’s like a sports car that can win a race on a good day but sometimes refuses to start if it doesn’t like the weather. The trick is to write code that expects weird behavior, to build your own connection queues, add retries, and prepare for the occasional glitch. Developers who survive Android Bluetooth bugs don’t just gain experience, they gain humility.

Then there’s iOS, Apple’s polished and opinionated perfectionist. Unlike Android, iOS is consistent. The same code usually behaves the same way across every iPhone and iPad. Apple’s Bluetooth framework, called Core Bluetooth, is beautifully organized and well-documented. But Apple also has strict rules about what you can and can’t do. Background scanning? Only in very specific cases. Advertising? Only for certain UUIDs. Access to lower-level Bluetooth layers? Absolutely not. Apple’s approach is like a luxury hotel: everything looks gorgeous, but you’re not allowed in the kitchen.

Working with iOS feels calm at first. Your connections are stable, your APIs are clear, and your devices behave predictably. But the moment you need to do something slightly unconventional, like connecting to multiple peripherals at once or keeping the app alive in the background, iOS politely says, “No, that’s not how we do things here.” Developers often end up performing delicate dances with background modes, notifications, and clever reconnection tricks just to make things feel seamless for users.

And then we have the third member of the trio: embedded devices. These are the quiet, uncomplaining ones that actually do most of the work. They live inside your smart sensors, wearables, and IoT nodes. They’re usually built around tiny chips with limited memory and low-power processors. They don’t have fancy operating systems or flashy UI frameworks. All they know is how to advertise, connect, send data, and then go back to sleep to save battery.

Embedded devices are loyal but easily overwhelmed. They can’t handle constant large data transfers, and they get cranky if you make them maintain too many simultaneous connections. Imagine trying to run a marathon after eating one grape, that’s what it’s like for a small BLE chip to handle too much traffic. Yet, these little devices are the backbone of every scalable Bluetooth network. They measure your heart rate, control your smart lights, and track your environmental sensors, all while running quietly in the background.

The real challenge begins when you try to make these three cooperate. Android wants freedom, iOS wants structure, and embedded devices just want a nap. Getting them all to work together is like managing a group project where one person writes essays at midnight, another color-codes everything, and the third forgets to charge their laptop. But when you finally get it right, when Android, iOS, and your embedded nodes connect seamlessly, it feels like magic again.

In the next section, we’ll explore how to actually make that happen. You’ll see how to design a Bluetooth architecture that scales gracefully across these platforms instead of collapsing into a pile of logs and retries. It’s part engineering, part patience, and part diplomacy.

Architecting for Scale — Herding Cats, but Wirelessly

If there’s one secret to scaling Bluetooth, it’s this: treat it like herding cats. You’ll never truly control it, but with enough structure, patience, and a bit of catnip (or clever engineering), you can convince all the cats to move in roughly the same direction.

Building a Bluetooth system that spans Android, iOS, and embedded devices isn’t just about writing code that connects things. It’s about designing relationships, the rules and boundaries that keep those connections healthy. The key idea here is architecture, which is a fancy word for “deciding who does what, when, and how.” Without a solid architecture, your Bluetooth project quickly turns into a tangle of callbacks, disconnections, and unanswered packets.

The first principle of Bluetooth architecture is abstraction. Every platform has its own Bluetooth API, but the basic idea is always the same: scan for devices, connect, exchange data, and disconnect. So instead of writing separate logic for each platform, you create one unified interface, a sort of translator layer, that hides all the messy differences underneath. In practice, this means you can write something like connect(device) in your app, and whether you’re on Android, iOS, or even a Raspberry Pi, the underlying code figures out how to make it happen.

This abstraction layer is your peacekeeper. It prevents the rest of your app from needing to know whether it’s talking to a Nordic chip on a wristband, a smart bulb using an ESP32, or an iPhone pretending to be a peripheral. When you have hundreds or thousands of devices, abstraction isn’t just convenient, it’s survival.

Next comes connection management. BLE connections are like toddlers: they demand constant attention and can vanish the moment you look away. A scalable Bluetooth system can’t afford to panic every time a device disconnects. Instead, you design it to expect chaos. You add automatic retries, reconnection strategies, and timeouts that gracefully handle failures instead of freezing your app. Good systems don’t assume the network will always behave, they assume it won’t.

Then there’s data orchestration, deciding who talks first, how much data gets sent, and how you keep multiple connections from tripping over each other. Imagine you’re a conductor in an orchestra where half the instruments fall asleep randomly to save power. You need a plan that lets each device play its part in harmony without draining its battery. That’s what managing Bluetooth data flow feels like.

And finally, there’s power strategy. Embedded devices live on tight energy budgets. Every scan, advertisement, and data exchange eats into their lifespan. So, your architecture must schedule communication intelligently, let devices wake up briefly, share data, and return to sleep before they burn out. The best Bluetooth systems look lazy on the surface but are actually brilliant planners underneath.

When you put all of this together, abstraction, connection management, orchestration, and power control, you get something that scales. It doesn’t matter if you’re managing three wearables or three thousand sensors. The system behaves predictably, logs issues instead of panicking, and recovers from disconnections automatically.

Think of it like a well-run airport. Planes (your devices) take off and land constantly. The control tower (your app’s Bluetooth manager) keeps track of who’s in the air, who’s landing next, and who needs maintenance. No single pilot needs to know everything, they just follow the protocol.

Scaling Bluetooth isn’t about being clever with one device. It’s about designing systems that keep working even when dozens of devices act unpredictably. You don’t tame Bluetooth by force; you do it by creating a world where even chaos feels organized.

In the next section, we’ll dig deeper into how these connections actually behave in real time, how devices discover each other, exchange data, and, sometimes, break up without warning.

Connection, Discovery, and Data Flow — The Bluetooth Dating Game

Every Bluetooth connection starts like a modern love story. One device sends out signals into the air, announcing that it’s available. Another device scans the surroundings, hoping to find something compatible. When they finally spot each other, they exchange a few polite packets, decide they’re a good match, and try to make it official with a connection. It’s wireless romance, until one of them walks away without saying goodbye.

This is the heart of how Bluetooth works: advertising, discovery, and connection. An embedded sensor or wearable device usually plays the role of the advertiser. It broadcasts tiny packets called advertisements that contain just enough information to say, “Hey, I’m here, and I can measure temperature or heart rate or unlock your door.” These packets are intentionally small because transmitting data takes energy, and low-power devices have to conserve every drop of battery life.

Meanwhile, your phone or tablet acts as the scanner, it listens to the radio waves around it, searching for those signals. When it finds one that matches what it’s looking for, it sends a request to connect. If the peripheral accepts, they move into a new relationship phase: the GATT connection. GATT stands for Generic Attribute Profile, which is basically the language they use to talk. Once connected, your phone can ask the device for specific data, like reading a heart rate measurement or writing a configuration setting.

Now, if all of this sounds peaceful and predictable, that’s because we haven’t talked about what happens in the real world. In reality, devices move around, signals weaken, and phones go into power-saving modes that forget they were even connected. Connections drop. Pairing sometimes fails. And when you have ten or more devices talking at once, managing all those tiny wireless conversations becomes a circus act.

Scaling Bluetooth is all about keeping this circus under control. You can’t force every device to stay connected forever, that would drain batteries and jam the radio channels. Instead, you design a rhythm. Devices connect only when needed, exchange data quickly, and then disconnect to rest. This constant dance of connecting and disconnecting keeps the system efficient and stable.

Think of it like a well-run coffee shop. Customers (phones) walk in, place their order (data request), get their coffee (response), and leave. The barista (the embedded device) doesn’t serve one person all day, it serves everyone in quick cycles. The trick is to make sure no one gets stuck waiting for their latte forever.

Timing is everything in this dance. If a device advertises too infrequently, the phone might not discover it in time. If it advertises too often, it wastes power. If the phone sends too many requests at once, the device might crash or slow down. Bluetooth connections live in this delicate balance between performance and efficiency.

When you scale, you also have to think about coordination. Imagine one phone trying to talk to ten sensors at once. You can’t have it flood them all with requests simultaneously, it needs a queue, a polite way of saying “you first, then me.” This is called connection orchestration, and it’s one of the hardest parts of scaling BLE systems.

And then there’s the breakup. Devices disconnect all the time, sometimes intentionally, sometimes accidentally. The best Bluetooth systems treat disconnections not as failures but as normal events. The app automatically retries, reconnects, and syncs data without asking the user to “try again.” To users, it feels seamless. Underneath, there’s a lot of quiet heroism happening, background threads, timers, and reconnection logic all working together to patch up relationships on the fly.

So, at its core, Bluetooth is less like a stable marriage and more like speed dating with excellent scheduling. Everyone meets briefly, exchanges information, and moves on. When done right, this model scales effortlessly. When done wrong, it’s chaos.

In the next section, we’ll explore the quirks that make Android, iOS, and embedded devices behave differently in this dating game, and how to keep the peace when one of them inevitably ghosts the others.

Platform Quirks — And How to Stay Sane

Once you start scaling Bluetooth, you’ll notice something odd. The same code that works perfectly on one device suddenly refuses to behave on another. It’s like watching identical twins argue about who gets the last slice of pizza, they may look the same, but their personalities couldn’t be more different.

Let’s start with Android, the unpredictable one. Android gives developers more power than any other mobile platform. You can scan however you like, filter by services, read and write any characteristic, and even customize connection intervals. But that power comes at a price. Every phone manufacturer modifies the Bluetooth stack slightly. Samsung, Pixel, OnePlus, Xiaomi, each adds its own flavor of “enhancement,” which sometimes translates to “surprise, nothing works the same.”

One Android phone might handle ten connections at once without blinking. Another might drop all of them the moment the screen turns off. Some versions ignore Bluetooth permissions until you grant location access. Others claim they’re scanning when they actually stopped five minutes ago. Android developers eventually stop asking why and simply build more logging instead. The rule of thumb with Android Bluetooth is simple: test everything, assume nothing, and expect the unexpected.

Then there’s iOS, which at first feels like a breath of fresh air. Apple’s Core Bluetooth framework is clean, consistent, and almost elegant. You get predictable callbacks, smooth reconnections, and well-behaved devices. But if you step outside Apple’s boundaries, you’ll quickly find invisible fences. iOS doesn’t let apps scan in the background freely. It limits how often you can advertise. And if your app tries to keep too many simultaneous connections alive, iOS politely steps in and shuts them down.

Apple’s philosophy is control. It wants Bluetooth connections to behave in ways that don’t drain the battery or clutter the radio. That’s great for users, but for developers it can feel like being handed the keys to a Ferrari and told you can only drive in the parking lot. It works beautifully, as long as you color inside the lines.

And then we have embedded devices, which are in a category of their own. These are the little chips sitting inside your wearables, sensors, or IoT gadgets. They don’t have operating systems or background processes. They just run tiny loops of firmware that listen, respond, and sleep. Their quirks are more about physics than software. If the antenna isn’t tuned properly, signals drop. If the power supply fluctuates, the radio turns off. Sometimes they disconnect simply because a human walked between two devices and absorbed the signal.

Embedded Bluetooth stacks also differ by manufacturer. Nordic, Espressif, Silicon Labs, Texas Instruments, each has its own libraries, quirks, and limitations. Even small changes like increasing the packet size or adjusting the advertising interval can make or break communication. It’s a careful dance between efficiency and reliability.

Now imagine you’re trying to get all three of these worlds to cooperate. Android wants freedom, iOS enforces discipline, and embedded devices want long naps. Building a Bluetooth system that works across all of them is like running a daycare with overachievers, rule-followers, and kids who fall asleep mid-activity. You can’t treat them all the same, but you can design a routine that keeps everyone content.

The secret is resilience. Instead of expecting perfect behavior, build your system around imperfections. Add retries when connections fail. Cache data so you don’t lose progress during disconnections. Keep your embedded devices simple, your mobile apps forgiving, and your logs brutally honest.

If you design with these quirks in mind, your Bluetooth system will feel almost magical, even though, behind the scenes, it’s a web of error handling, reconnections, and polite compromise.

In the next section, we’ll take a look at another side of scaling: keeping everything secure and private while all these devices whisper secrets over the air.

Security and Privacy at Scale

Once your Bluetooth system starts working reliably, there’s another challenge waiting in the wings: keeping it secure. It’s one thing to get devices talking to each other, it’s another to make sure no one else is eavesdropping on the conversation. Bluetooth security can sound intimidating, but at its core, it’s about making sure your devices trust each other and that strangers can’t sneak into the chat.

Let’s start with pairing. Pairing is Bluetooth’s version of saying, “Hey, can I trust you?” It’s a handshake where two devices exchange keys that let them communicate securely in the future. There are a few ways this handshake can happen. The simplest is called Just Works, which basically means, “We’ll trust each other without asking too many questions.” It’s convenient but about as safe as leaving your front door unlocked because you live in a nice neighborhood. For harmless gadgets like wireless speakers, that’s fine. But for medical devices or smart locks, “Just Works” can turn into “Just Got Hacked.”

A safer approach is Passkey Entry, where one device shows a code and the other types it in, proving they’re physically near each other. Even better is Out-of-Band (OOB) pairing, where the devices exchange security information through another method, maybe a QR code, NFC tap, or even an optical blink, before connecting over Bluetooth. OOB pairing is like verifying someone’s identity face-to-face before continuing a conversation online.

Once paired, devices use encryption to scramble their communication. Anyone listening nearby will hear only gibberish. The strength of that encryption depends on the version of Bluetooth being used. Modern devices using Bluetooth 4.2 or later support something called LE Secure Connections, which is based on advanced cryptography. Older devices use weaker methods that are easier to crack. So, if you’re building something new, never rely on outdated pairing modes.

But security isn’t just about encryption. It’s also about privacy. Every Bluetooth device has an address, kind of like its phone number, that it uses when broadcasting. If that address stays the same, someone could track you by following your device’s broadcasts. That’s why newer standards support random address rotation, where devices periodically change their Bluetooth address. Your phone and smartwatch still recognize each other, but strangers can’t follow your signal around the city.

When you scale Bluetooth systems, these little details become critical. A single insecure device in your network can become the weak link that compromises everything. It’s like locking every door in your house but leaving one window open. Attackers don’t need to break the whole system, they just need to find the lazy one.

Building security into a large Bluetooth deployment means standardizing your pairing process, using strong encryption everywhere, and handling key storage carefully. On embedded devices, that can be tricky because they have limited memory and no secure element by default. Still, even small steps help, like regenerating keys periodically and disabling “Just Works” mode for devices that control anything important.

On mobile platforms, the rules are slightly different. Android and iOS handle much of the heavy lifting for you, but you still have to design your app logic carefully. Always confirm which device you’re connecting to before exchanging sensitive data. Always check bonding state before sending configuration commands. In short, treat Bluetooth communication with the same seriousness you’d give to a login session or an online payment.

At scale, security isn’t something you bolt on later. It’s part of the system’s DNA. You can’t fix a weak handshake by adding a stronger password later. You have to start from the first pairing and make sure every connection trusts the right partner.

The reward is worth it. When done right, your Bluetooth network becomes invisible but secure, a quiet, encrypted web of trust that just works. No drama, no leaks, and no nearby strangers hijacking your sensors.

In the next section, we’ll talk about another invisible problem that decides whether your Bluetooth network lives for days or months: power. Because what good is a secure device if its battery dies halfway through the handshake?

Power and Performance Tuning

If you’ve ever wondered why your Bluetooth gadget dies right when you need it most, you’ve just met the oldest enemy in wireless communication: power consumption. Bluetooth may be clever, flexible, and everywhere, but it also has a bit of a caffeine problem. It loves to talk, and talking burns energy. Keeping your devices alive longer, especially when you scale, means learning the quiet art of power management.

At first, it’s easy to assume that Bluetooth is low power by default. After all, it’s called Bluetooth Low Energy, right? But BLE’s efficiency only shines when it’s used correctly. A poorly tuned BLE system can drain a battery faster than streaming music over Classic Bluetooth. The magic lies in controlling when devices talk, how long they talk, and how much they say each time.

Let’s start with the advertising interval. This is how often a device shouts, “I’m here!” into the air. If you set it to broadcast every 20 milliseconds, you’ll discover devices quickly, but you’ll also burn through the battery like it’s running a marathon. Increase the interval to once every second, and your device will last much longer, but phones may take a moment to find it. It’s a tradeoff between speed and stamina. Every system has to find its sweet spot.

Next comes the connection interval, how often two connected devices exchange data. This is like deciding how frequently you check your messages. If you check every second, you stay perfectly up to date but never get anything else done. If you check once every minute, you save time but risk missing something important. In Bluetooth terms, a shorter connection interval means faster communication but higher power usage. Longer intervals conserve battery but add delay. Smart systems adjust these intervals dynamically depending on what the device is doing.

Then there’s the MTU, or Maximum Transmission Unit, the size of each Bluetooth data packet. Bigger packets mean fewer total transmissions for large chunks of data, which can improve efficiency. But some devices, especially older ones, can’t handle large MTUs, so finding the right balance is important.

Power management is not just about numbers, it’s about habits. A well-designed embedded device spends most of its life asleep. It wakes up only to advertise or exchange data, then returns to rest as quickly as possible. Imagine a hummingbird darting out for a sip of nectar and then zipping back to rest before anyone notices. That’s how efficient Bluetooth devices survive on coin-cell batteries for months or even years.

On the phone side, energy management is just as critical, especially when your app needs to handle multiple connections. Constant scanning, reconnecting, or keeping GATT channels open drains your user’s battery, and patience. Android and iOS both have built-in mechanisms that throttle background Bluetooth activity to save power. Developers have to work with these rules, not against them. The best apps schedule scans intelligently, reconnect only when necessary, and avoid holding connections open when no data needs to be sent.

Scaling Bluetooth systems makes these power decisions even more important. When you have one device, wasting a bit of energy doesn’t matter. When you have hundreds of devices, each one burning just a few extra milliwatts, the total waste adds up quickly. Power efficiency becomes the difference between a network that runs for months and one that collapses after a week.

The golden rule of power tuning is simple: talk less, talk smarter. A Bluetooth device that knows when to speak and when to stay quiet can scale beautifully, even in large networks. It’s not about being fast all the time, it’s about being clever with timing.

In the next section, we’ll look at how these devices join your network in the first place and what happens when you need to update their software later. Because once your system scales, you’re not just connecting devices, you’re managing an entire population.

Provisioning and Firmware Updates — Welcome to Device Kindergarten

Imagine setting up one Bluetooth device. It’s easy: you pair it, give it a name, and maybe tweak a few settings. Now imagine doing that a hundred times. Or a thousand. Suddenly, what felt like a simple task starts to look like a factory assembly line powered by frustration. That’s where provisioning comes in, the process of onboarding new devices into your Bluetooth network so they can start working right away, without manual babysitting.

Provisioning is like a first day at school for your devices. Each new student needs to be identified, assigned to a class, and given a name tag. In the Bluetooth world, a newly manufactured device begins life in an “unprovisioned” state. It doesn’t belong to any network yet, so it advertises with a special signal that says, “Hey, I’m new here.” When your mobile app or gateway spots that advertisement, it can connect, authenticate the device, and hand over the credentials it needs to join the system.

The app usually performs a few key steps during provisioning. It verifies that the device is genuine, assigns it a unique identifier, and exchanges security keys so future connections can happen securely. It might also store metadata like which room the sensor belongs to or what type of data it will report. After provisioning, the device switches to its normal operation mode, where it advertises with its new identity and starts behaving like a member of the family.

When you have just one or two devices, you can do all this manually. But when you scale up to hundreds or thousands, manual setup becomes impossible. That’s when you start thinking about automation, QR codes on packaging, NFC tags for instant pairing, or out-of-band provisioning where a separate channel (like Wi-Fi or a wired link) handles secure onboarding. The goal is to make provisioning quick, repeatable, and error-free, even when your factory or users are adding new devices by the dozens.

Once your devices are out in the world, the next challenge appears: firmware updates. Every system eventually needs to fix bugs, patch security holes, or add new features. For Bluetooth devices, this means pushing new firmware over the same wireless link, a process known as FOTA, or firmware-over-the-air updates.

Updating firmware over Bluetooth can be nerve-wracking. The connection is relatively slow, and interruptions can leave a device half-updated and confused about who it is. Good update systems handle this carefully. They divide the firmware into chunks, verify each piece with checksums, and only switch to the new version once the whole update has been safely received and validated. If anything fails midway, the device rolls back to the old firmware instead of bricking itself.

Scaling makes this even more complex. Updating ten devices is fine. Updating a thousand can overwhelm your network if you try to do them all at once. Smart systems stagger the updates in waves, track which devices have finished, and retry the ones that didn’t. Some even let devices report their status back to a central dashboard, so you can see which ones are ready and which ones are still stuck halfway through.

Provisioning and firmware updates might not sound glamorous, but they’re the backbone of every scalable Bluetooth system. Without smooth onboarding and reliable updates, your network slowly falls apart as devices drift out of sync or miss critical fixes.

Think of it this way: provisioning is how devices join the family, and firmware updates are how they grow up. Both are essential if you want your Bluetooth ecosystem to stay healthy and dependable over time.

In the next section, we’ll talk about what happens when something inevitably goes wrong, how to debug and monitor a network full of devices without losing your mind.

Debugging, Monitoring, and Testing Across Platforms

At some point, every Bluetooth developer faces the same moment of quiet despair. The logs look fine, the devices are paired, the code hasn’t changed, and yet… nothing works. Connections fail, packets vanish, and everything that worked yesterday now refuses to cooperate. Welcome to the wonderful, mysterious world of Bluetooth debugging, a place where logic takes a vacation and patience becomes your most valuable skill.

Debugging Bluetooth is tricky because so much of it happens invisibly. The data is flying through the air, hopping between frequencies dozens of times per second, and all you can see is whether the connection succeeds or fails. It’s like trying to diagnose a conversation between two people whispering in another room. You can tell they’re talking, but not what they’re saying.

The first rule of Bluetooth debugging is simple: log everything. Log when you start scanning, when you find a device, when you connect, and when you disconnect. Log the signal strength, the UUIDs you discover, the number of bytes you read, and the time it took. Bluetooth problems rarely announce themselves loudly, they hide in tiny details. A small delay in a callback or a missing acknowledgment can reveal exactly why your system seems haunted.

Different platforms give you different kinds of help. Android, for example, offers detailed Bluetooth logs through developer options or tools like adb. You can capture the raw Bluetooth HCI logs and analyze them later to see what really happened under the hood. iOS, on the other hand, gives you less direct visibility. Apple handles most of the Bluetooth stack internally, so your only clues come from Core Bluetooth callbacks. Embedded devices often let you log directly from the firmware, showing connection events, error codes, and sometimes even packet-level information if the stack supports it.

Testing across platforms is just as important as debugging. You can’t assume that if it works on one phone, it will work on another. Android devices, especially, have a habit of interpreting Bluetooth timing slightly differently. A system that’s rock-solid on a Pixel may stutter on a Samsung or freeze on a low-cost tablet. The only cure is diversity, test on multiple brands, OS versions, and firmware builds until you’re confident the system behaves everywhere.

For embedded devices, testing is a different challenge. Because they often run continuously, you need long-term endurance tests to catch issues that only appear after hours or days of operation. You might discover that a connection fails only after 300 reconnections, or that a memory leak appears after a week of normal use. Building test rigs that automate these scenarios: connecting, disconnecting, and verifying data repeatedly, is a huge time saver.

Monitoring is what happens after you’ve deployed your devices into the real world. It’s like keeping a health tracker on your entire Bluetooth network. Your mobile apps or gateways can collect statistics such as signal strength, connection failures, uptime, and battery levels. That data tells you which devices are performing well and which ones might be drifting toward trouble.

Adding this kind of visibility pays off enormously at scale. When you’re managing hundreds of devices, it’s impossible to check each one manually. Instead, you rely on trends, for example, if one location shows consistently weak signal strength, maybe there’s interference nearby. If multiple devices drop connections at the same time, maybe the central device needs a firmware update. Monitoring transforms guesswork into insight.

The truth is, debugging and monitoring never really end. Even after your system is stable, new versions of Android and iOS will appear with small Bluetooth changes that break something you didn’t know could break. Treat Bluetooth maintenance like car maintenance: routine, ongoing, and essential.

Once you learn to capture good logs, read them calmly, and build systems that report their own health, debugging stops being a nightmare and becomes a science. Bluetooth may always be a little mysterious, but with the right tools and attitude, you can keep the ghosts out of your connection list.

In the next section, we’ll put everything together with a real-world example of what scaling Bluetooth actually looks like when all the pieces: mobile apps, embedded devices, and architecture, finally work in harmony.

Real-World Architecture Example — When Bluetooth Finally Behaves

Let’s take everything we’ve talked about and bring it to life with a real-world scenario. Imagine you’re building a smart factory system with hundreds of Bluetooth sensors scattered across the floor. Each sensor measures temperature, vibration, or humidity. Some are attached to machines, others hang on walls, and a few are hidden in places even the janitor doesn’t know about. Your goal is simple on paper: collect data from all these sensors, send it to a central dashboard, and keep everything running smoothly.

The reality, of course, is much more complicated. Each sensor is an embedded device powered by a coin-cell battery that has to last for months. They advertise periodically to announce they’re alive. Your Android or iOS tablets, placed around the factory as gateways, act as Bluetooth centrals. Their job is to scan, connect to nearby sensors, read data, and upload it to the cloud. It sounds straightforward, but you’re juggling dozens of invisible connections at once, and they all have different moods.

The architecture begins with careful planning. Each gateway tablet knows which part of the factory it’s responsible for. That way, you avoid overcrowding the airwaves with multiple devices trying to connect to the same sensors. The sensors use slightly staggered advertising intervals so they don’t all shout at the same time. The gateways maintain a queue, connecting to a few sensors at a time, reading data, and then disconnecting before moving on to the next group. This rotation keeps everything balanced and prevents Bluetooth traffic jams.

Power management is built into every step. Each sensor wakes up, advertises briefly, sends its data when connected, and goes right back to sleep. The connection interval and MTU size are tuned for efficiency, large enough for smooth data transfer, but not so large that slower devices choke. Every byte is treated like gold because every transmission costs energy.

The gateways handle the messy parts: reconnections, retries, and data aggregation. They buffer readings in case the Wi-Fi link to the cloud goes down and sync later when it’s back. They also monitor each sensor’s signal strength, battery level, and uptime. If a sensor hasn’t reported in a while, the system flags it automatically so a technician can check on it.

Now imagine scaling this setup to multiple factory buildings. Suddenly, you’re managing thousands of sensors, dozens of gateways, and countless wireless interactions. At this scale, the design choices you made early, abstracted Bluetooth logic, retry mechanisms, power optimization, and logging, are the difference between a quiet, self-running network and a system that collapses into constant reconnections.

When everything works as intended, something beautiful happens. The sensors collect data silently. The gateways synchronize automatically. The dashboards stay green. Nobody has to restart anything, and Bluetooth quietly fades into the background where it belongs. It’s the rare moment when technology stops demanding attention and simply does its job.

This kind of architecture isn’t science fiction. Companies use it in factories, hospitals, and warehouses every day. From smart lighting systems to patient monitors, Bluetooth at scale can be astonishingly reliable, but only if you treat it like a distributed system, not a single gadget. Each device is a citizen of a larger ecosystem, and your job as the architect is to keep that ecosystem healthy.

The biggest takeaway is that success doesn’t come from fancy algorithms or expensive hardware. It comes from the small, deliberate decisions that make your system resilient: how you handle disconnections, how you schedule connections, how you monitor performance. Scaling Bluetooth is not about avoiding problems, it’s about designing a system that recovers gracefully when problems happen.

In the next section, we’ll wrap up everything we’ve learned into a practical checklist, a simple guide you can use whenever you’re designing a Bluetooth system that has to survive in the wild.

Checklist — Building a Truly Scalable Bluetooth System

By now, you’ve seen Bluetooth in all its moods, charming, confusing, unpredictable, and surprisingly capable when handled with care. So how do you actually put everything together? What makes a Bluetooth system scalable instead of just “working on my desk”? The answer isn’t a single trick or secret API. It’s a mindset, a way of designing your system to expect chaos and still function gracefully when it happens.

The first part of that mindset is consistency. Every Bluetooth system should have one clear and stable way of communicating. Keep your data formats simple, your GATT profiles predictable, and your naming conventions sensible. If you have ten devices made by ten different vendors, make them all speak the same language. The moment one device starts improvising, the whole orchestra sounds off.

Next comes patience, and in Bluetooth, patience means retries. Connections drop. Devices go out of range. A phone might go to sleep or decide that scanning is no longer fashionable. Instead of treating every disconnection as a crisis, treat it as part of the process. A good Bluetooth app quietly retries in the background, restores the connection, and carries on as if nothing happened. To the user, it feels seamless. Underneath, it’s a flurry of logic keeping the experience smooth.

Then there’s the question of power. Remember that every advertisement and connection eats into battery life. A scalable Bluetooth system doesn’t talk all the time, it talks smart. It plans when to wake up, when to exchange data, and when to stay silent. Devices that last longer need fewer replacements, fewer updates, and far less human attention. Power efficiency is the hidden currency of scalability.

Monitoring is another essential habit. If you can’t see what’s happening inside your system, you’re flying blind. Log your connections, track your signal strengths, record how often devices drop out, and visualize it somewhere. A simple dashboard that shows which devices are healthy and which ones are struggling can save you countless hours later. When you scale, visibility turns guesswork into control.

Security, too, can’t be an afterthought. Use secure pairing, proper encryption, and rotating addresses. The bigger your system gets, the more interesting it becomes to people who might want to peek at it. Make sure they can’t. A secure Bluetooth network doesn’t just protect users, it protects your reputation.

Finally, build for change. Bluetooth isn’t static, Android and iOS update their stacks every year, chip vendors release new firmware, and new security standards appear. A scalable system doesn’t break when something changes, it adapts. That’s why abstraction layers, modular code, and updatable firmware matter so much. They keep your system flexible long after the first version ships.

If you do all of this, keep it consistent, patient, efficient, observable, secure, and adaptable, something magical happens. Your Bluetooth system starts to feel less like a fragile web of devices and more like a living network. It keeps running, keeps healing, and quietly gets the job done without constant supervision. That’s when you know you’ve built something that scales.

In the final section, we’ll step back and reflect on the bigger picture, what scaling Bluetooth really teaches us about building technology that has to work not just once, but over and over again in the messy, beautiful real world.

Wrap-Up — Lessons from the Field

If you’ve made it this far, you’ve probably realized that scaling Bluetooth isn’t really about Bluetooth at all. It’s about learning how complex systems behave when they leave the comfort of your desk and enter the real world. It’s about understanding that wireless connections are not just electrical signals, they’re relationships between unpredictable, battery-powered, opinionated little machines.

Bluetooth gets a bad reputation because people expect it to be simple. They imagine it’s like Wi-Fi or USB, plug and play, pair and forget. But in truth, Bluetooth is more like a polite conversation at a crowded party. Everyone is talking at the same time, the music is loud, and you have to keep repeating yourself until the other person hears you correctly. When you think of it that way, it’s a miracle that it works as well as it does.

Scaling Bluetooth across Android, iOS, and embedded devices teaches you humility. You stop assuming things will always behave, and instead you start building systems that recover when they don’t. You learn that error handling is not an afterthought, it’s the main event. You discover that batteries are precious, timing is everything, and the smallest design decisions can ripple through an entire ecosystem of devices.

You also start to appreciate the quiet beauty of resilience. There’s something deeply satisfying about watching dozens of sensors, gateways, and phones connect, share data, and disconnect, all without human intervention. When it works, it feels effortless. You forget about the retries, the power cycles, the reconnections, and the debugging sessions that made it possible. All you see is a smooth network humming quietly in the background, doing exactly what it was meant to do.

And that’s the real magic of Bluetooth, not the flashy tech demos or the pairing animations, but the invisible collaboration that happens beneath the surface. It’s the heartbeat of every wearable, every sensor, every tiny device that quietly makes our lives a little easier. Scaling it isn’t just an engineering challenge; it’s a lesson in patience, design, and empathy for systems that can’t always speak for themselves.

So, the next time your Bluetooth device disconnects, take a breath. Somewhere in the chaos, it’s just trying to reconnect, to find its partner again and pick up where it left off. Because deep down, that’s what Bluetooth really is: a network built on trust, persistence, and tiny packets of hope flying through the air.

You probably don’t even think about Bluetooth anymore. It’s just there, quietly doing its job every single day. It’s what keeps your earbuds connected, your smartwatch synced, your car infotainment system talking to your phone, and your warehouse sensors awake and reporting.

The funny thing is, while most of us stopped paying attention, Bluetooth never stopped evolving. It just kept getting smarter.

Now it’s 2025, and Bluetooth has grown into something much bigger than a way to stream music. It has become a core ecosystem that connects nearly everything around us. From audio gear and IoT sensors to industrial automation and secure building access, Bluetooth is everywhere.

The newest versions, Bluetooth 5.4 and 6.0, completely redefine how devices talk to each other. We’re talking about encrypted broadcasts, smarter advertising, centimeter-level distance tracking, and a level of scalability that feels closer to magic than engineering.

In this article, we’ll take a tour through the newest Bluetooth technologies and see what’s happening under the hood. You’ll get a feel for what’s new, how these features work in real projects, and how developers can actually take advantage of them.

Grab your favorite dev board, and let’s dive in.

Table of Contents

1. The Evolution: From Classic to Low Energy to 6.0

2. Deep Dive: Technical Enhancements

3. Real-World Applications in 2025

4. Developer Guide: Getting Started

5. Challenges and Trade-Offs

6. The Road Ahead: Bluetooth 6.1 and Beyond

7. Conclusion

The Evolution — From Classic to Low Energy to 6.0

If you’ve been around Bluetooth for a while, you probably remember the early days when pairing a headset felt like solving a riddle. Back then, Bluetooth Classic ruled the scene, focused mainly on short-range audio and simple data links. Over the years, though, the story changed completely.

Today, Bluetooth has transformed from a simple cable-replacement protocol into a flexible framework for everything from earbuds to industrial robots. Each new version added fresh layers of intelligence, speed, and energy efficiency. The table below gives a quick timeline of how that evolution unfolded.

The journey tells a bigger story. What started as a way to connect two devices for audio has turned into a foundation for massive IoT networks. Each revision introduced smarter physical layers, better energy profiles, and new roles for devices that once had very limited capability.

Source: MDPI Sensors (2025), Bluetooth Core Specification Summary.

Above figure provides a visual snapshot of how Bluetooth has evolved across its major versions. It shows a clear chronological progression of features—from the launch of Bluetooth Low Energy (BLE) in version 4.0, to the introduction of secure connections, long-range PHYs, and direction-finding capabilities, all the way up to the latest breakthroughs like Channel Sounding and decision-based filtering in Bluetooth 6.0. The color-coded timeline highlights how each version refined both the physical and logical layers of communication, gradually expanding Bluetooth’s reach from simple peripherals to high-precision industrial and spatial applications. In essence, it maps Bluetooth’s transformation from a short-range wireless cable into a sophisticated, context-aware connectivity fabric that underpins modern audio, IoT, and automation ecosystems.

If you zoom out a bit, you’ll notice a clear pattern: Bluetooth keeps finding new neighborhoods to move into. From cars and headphones to factories and hospitals, the technology now feels less like a cable replacement and more like an invisible nervous system for the modern world.

What’s New in Bluetooth 5.4 and 6.0

When you hear that Bluetooth has a “new version,” it’s easy to shrug it off. After all, your headphones already work, right? But the jump from 5.3 to 5.4 and then 6.0 isn’t just a tiny step. It’s more like Bluetooth quietly taking on Wi-Fi’s job in certain places and pulling it off surprisingly well.

Let’s break it down by version so it’s easier to see what’s going on.

Bluetooth 5.4: Building the IoT Backbone

This release might not have made flashy headlines, but engineers loved it. It focuses on letting thousands of low-power devices talk to a single gateway without choking the airwaves.

Let’s look at some of the key features and why they matter:

Periodic Advertising with Responses (PAwR)

Think of it as Bluetooth’s group chat for sensors. Devices can broadcast messages and still get short replies, all without the full connection setup that usually drains batteries. It’s perfect for large sensor networks like smart warehouses or retail stores with electronic shelf labels.

Source: Nordic Semiconductor Developer Zone (2024)

Above diagram illustrates the timing structure of Bluetooth 5.4’s Periodic Advertising with Responses (PAwR) mechanism. Along the horizontal axis, it shows a repeating sequence of PAwR events separated by the overall periodic advertising interval. Within each PAwR event are several subevents—labeled #0, #1, #2, #3, and so on—each representing a defined window of time during which specific sensors or devices are allowed to communicate. The figure highlights that every subevent occurs at a fixed periodic advertising subevent interval, meaning devices can wake up only during their assigned slot, transmit or receive data, and then return to sleep. This predictable scheduling dramatically reduces radio collisions and power consumption, allowing a single gateway to coordinate thousands of low-power nodes such as electronic shelf labels or environmental sensors within a shared advertising cycle.

Encrypted Advertising Data

Broadcasts used to be open for anyone to sniff. Now they can be private and secure, which is essential for medical monitors and retail beacons carrying sensitive info.

Source: Raytac Technology (2024)

Above diagram breaks down the structure of the Encrypted Data Advertising Data (AD) type introduced in Bluetooth 5.4. It visually shows how encrypted advertising payloads are organized within a broadcast packet. At the top, the full advertising payload is represented, which includes the length (Len), Encrypted Data (ED Tag), and flags. Inside the encrypted section, the fields are expanded to show the Randomizer, Payload, and Message Integrity Check (MIC). The payload itself may contain various elements such as the Electronic Shelf Label (ESL) Tag, ESL Payload, Local Name (LN Tag), or other advertising segments. The color-coding differentiates which parts are encrypted (blue) versus unencrypted (gray or yellow), highlighting how Bluetooth 5.4 secures sensitive data while retaining key advertising identifiers for discovery. This layout helps engineers understand where encryption is applied within the advertising packet and how privacy and integrity are preserved during broadcast communication.

Electronic Shelf Labels (ESL) Support

Bluetooth 5.4 was practically written with supermarkets in mind. Imagine thousands of digital price tags blinking updates at once, all running for months on coin-cell batteries.

Source: Dani Data Systems (2023)

Above image illustrates the working architecture of a Bluetooth-based Electronic Shelf Label (ESL) system. On the left, a computer running ESL management software is shown, which allows retail staff to configure product data, prices, and display templates. The software communicates over a TCP/IP network connection with a Base Station positioned in the center of the diagram. This base station acts as a Bluetooth gateway, wirelessly transmitting the updated price and product information to numerous shelf labels throughout the store. On the right, a digital ESL display is shown featuring a price tag for a product labeled “Kaju Katali,” complete with product details, QR codes for mobile payments, and expiry dates. The blue wireless icon between the base station and ESL tag symbolizes Bluetooth communication. Together, the components demonstrate how Bluetooth 5.4 enables synchronized, low-power, and remotely managed price updates across thousands of retail shelf labels.

In short, 5.4 was the version that said, “Sure, we can handle massive IoT networks.”

Bluetooth 6.0: The Game Changer

Bluetooth 6.0 feels like the point where the technology matured from “just wireless” into “smart wireless.” This version brings features that start blurring the line between Bluetooth and more advanced location systems.

Channel Sounding

This is a big one. Instead of using signal strength (which can be messy), Bluetooth 6.0 measures phase differences in radio waves to calculate distance. That means centimeter-level accuracy (enough for digital keys), precise tracking, and even AR interactions.

Source: Bluetooth SIG (2025)

Above image explains the concept of Bluetooth Channel Sounding, a new feature introduced in Bluetooth 6.0 that enables precise distance measurement between devices. The top half of the diagram compares three levels of spatial awareness—presence detection through advertising, coarse distance estimation using RSSI (Received Signal Strength Indicator), and fine-grained ranging achieved with Channel Sounding. It also shows how Direction Finding complements these methods by determining angular orientation. On the left, a smartphone (the initiator) communicates with a smart lock (the reflector), demonstrating how Bluetooth can estimate distance and direction simultaneously. The bottom portion visualizes two measurement techniques. The Phase-Based Ranging chart shows how two signals of different frequencies experience measurable phase shifts that correspond to distance. The Round Trip Time (RTT) diagram on the right depicts packets traveling between the initiator and reflector, with the elapsed time between transmission and reception used to calculate distance. Together, these visuals illustrate how Bluetooth 6.0 achieves centimeter-level accuracy for applications like digital keys, indoor navigation, and spatially aware IoT systems.

Decision-Based Advertising Filtering

Bluetooth devices now decide which advertisements to process and which to ignore, saving both power and bandwidth. It’s like teaching scanners to pay attention only when it’s worth it.

Source: Bluetooth SIG (2024)

Above diagram illustrates the architecture of Decision-Based Advertising Filtering, a new Bluetooth 6.0 feature that allows observers to process only relevant broadcast packets, reducing power consumption and unnecessary data handling. The figure depicts two parallel host–controller stacks: the Observer on the left and the Advertiser on the right. Each side includes an Application layer, Host Controller Interface (HCI), and Controller. On the advertiser side, the application generates Decision Data that passes through the HCI to the controller’s advertising engine, where it’s embedded into extended advertising packets known as Decision PDUs. On the observer side, incoming advertising data passes through a Filter Policy module in the controller, which selects or rejects packets according to preconfigured decision criteria before forwarding only the relevant Advertising Reports to the host application. Blue arrows show configuration and report flows, while the yellow HCI bands highlight the host–controller boundary. Together, the components show how Bluetooth 6.0 empowers devices to make intelligent, context-aware filtering decisions at the controller level, improving efficiency in dense radio environments.

Advertiser Monitoring

Gateways can now keep tabs on the state of nearby advertisers, which is critical when hundreds of devices are broadcasting at once.

Source: Bluetooth SIG (2024)

Above image depicts the fundamental interaction between two Bluetooth Low Energy (BLE) device roles — advertising and scanning. On the left, a smartphone icon represents the scanning device, which actively listens for nearby Bluetooth broadcasts. On the right, a small sensor or tag icon represents the advertising device, periodically transmitting packets that announce its presence, capabilities, or data updates. Blue concentric rings radiate outward from both devices, symbolizing the propagation of radio signals and the overlapping wireless coverage area where scanning and advertising events intersect. The minimalist design highlights the asymmetric nature of BLE communication: the advertiser periodically transmits small bursts of information, while the scanner remains receptive to detect, filter, or connect with those broadcasts — forming the foundation of all Bluetooth discovery, pairing, and data exchange processes.

Negotiable Inter-Frame Spacing

This lets devices adjust timing between packets to improve throughput and avoid interference in noisy environments.

Source: Bluetooth SIG (2024)

Above image illustrates the concept of Negotiable Inter-Frame Spacing (IFS) in Bluetooth 6.0, which optimizes the timing between consecutive data packets to improve throughput and reduce interference. The diagram shows two sequences of communication between a Central (C) and a Peripheral (P) device, represented as alternating blue (C→P) and green (P→C) data blocks. In the first sequence, packets are transmitted with a short, fixed inter-frame spacing labeled T_IFS, showing a rapid exchange of packets within a connection event. The second sequence demonstrates the enhanced Bluetooth 6.0 model, where devices can dynamically negotiate a longer spacing interval — indicated by the notation “≥ T_IFS” — to accommodate environmental conditions, controller processing delays, or congestion. The red horizontal arrows mark the overall connection event duration, while the vertical lines represent packet boundaries. By allowing flexible timing adjustments between frames, Bluetooth 6.0 reduces airtime collisions and improves coexistence with other 2.4 GHz systems, particularly in dense or interference-prone environments.

ISOAL Enhancements

Audio data, especially LE Audio streams, now move more smoothly thanks to improved support for large frames.

Source: Bluetooth SIG (2024)

Above diagram illustrates the internal data flow and timing structure of the Isochronous Adaptation Layer (ISOAL) in Bluetooth 5.2 and later, which supports synchronized audio and data transmission over LE Isochronous Channels. The figure is divided into three main sections: the Upper Layer, the ISOAL, and the Link Layer. At the top, the Upper Layer handles isochronous data in the form of Service Data Units (SDUs). Within the ISOAL layer, SDUs undergo several key processes — Fragmentation and Segmentation break data into smaller protocol units, while Recombination and Reassembly merge received fragments back into complete SDUs. Two important timing-related steps occur in parallel: the Inclusion of Timing Offsets, which ensures proper packet scheduling, and Timing Reconstruction, which synchronizes the playback or reassembly timing for received streams. These operations produce either Framed or Unframed Protocol Data Units (PDUs), which are then passed to the Link Layer at the bottom for transmission over the Isochronous Stream. The diagram highlights how ISOAL bridges the upper and lower layers, managing timing alignment and packet structure to deliver low-latency, synchronized LE Audio or data streams across multiple devices.

When you put all that together, Bluetooth 6.0 starts looking a lot like Ultra-Wideband in terms of precision, but without needing new hardware. It’s faster, smarter, and somehow more polite on the airwaves.

Deep Dive — Technical Enhancements

This is where Bluetooth starts to feel less like “a thing your phone just does” and more like a finely tuned machine. The new specs add layers of intelligence that make devices more aware of distance, timing, and context. It’s the kind of stuff that gets engineers grinning because it solves problems we’ve all quietly complained about for years.

Let’s walk through a few of the most important ones.

Channel Sounding and Distance Awareness

If you’ve ever used RSSI values to guess how far a device is, you know how unpredictable it can be. RSSI measures how strong the signal sounds, not where it actually came from. A wall, a metal shelf, even a human body can distort it. Channel Sounding solves this by looking at phase instead of strength.

Here’s the idea: two devices exchange carefully crafted packets at multiple frequencies. Each frequency behaves like a different musical note. When those notes reach the receiver, their phases – how the peaks and troughs line up – shift slightly depending on distance. The receiver compares the original and received phases, then crunches the math:

$$[ \text{Distance} = \frac{c \times \Delta \phi}{2\pi f} ]$$

where:

• ( c ) is the speed of light,

• ( \Delta \phi ) is the phase shift,

• ( f ) is the carrier frequency.

This approach allows for precise distance measurement, achieving accuracy down to a few centimeters by analyzing the phase differences of signals received at multiple frequencies.

That level of precision changes the game. Cars can unlock automatically only when you’re physically beside the door. Smart-building systems can tell which room you’re standing in. Mixed-reality headsets can map your movements without extra sensors.

From a development point of view, you’ll need hardware that supports the new Channel Sounding PHY. Nordic’s nRF54 and Silicon Labs’ BG24 families already expose low-level APIs for it. Expect to work closer to the metal than usual: calibration, antenna diversity, and clock stability all affect measurement accuracy. It’s worth the effort, though. Few wireless technologies can deliver this precision without expensive dedicated hardware.

Periodic Advertising with Responses (PAwR)

For years, BLE advertising worked like shouting into a room and hoping someone heard you. The moment you wanted a reply, you had to form a full connection. That model doesn’t scale when you have ten-thousand tiny sensors that each wake up once a minute.

PAwR flips the model. Think of it as a scheduled town-hall meeting. A coordinator (the gateway) broadcasts a timeline. Each sensor has a reserved time slot to respond within that cycle. Because everyone speaks only during their assigned moment, collisions disappear and energy use plummets.

In practice, this lets one gateway handle tens of thousands of devices without ever maintaining individual connections. Supermarkets use it for electronic shelf labels that update prices in seconds. Factories deploy it for environmental sensors that report temperature and vibration periodically.

Developers integrating PAwR will notice that it doesn’t replace connections, it complements them. You can still open a full GATT session for configuration, but routine data flows through lightweight PAwR exchanges. Most modern SDKs, including Zephyr and ESP-IDF, now include PAwR APIs under their extended-advertising modules.

Isochronous Audio Channels & LE Audio

Bluetooth’s original audio stack wasn’t built for what we expect today. It was designed for single-stream mono headsets, not for multi-earbud synchronized audio or broadcast systems. Isochronous Channels fix that by ensuring that every packet in a group shares the same clock reference.

Two modes exist:

• Connected ISO Streams (CIS) handle one-to-one cases like stereo earbuds

• Broadcast ISO Streams (BIS) allow a transmitter to serve an unlimited audience, such as a gym or theater.

Both rely on the LC3 codec, which delivers near-lossless sound at roughly half the bandwidth of SBC.

In real life, this means earbuds that stay perfectly in sync even if you walk between interference zones, hearing aids that seamlessly share the same stream, and venues that broadcast announcements directly to phones without dedicated receivers. Android 14 and iOS 17 have already exposed system-level LE Audio support, so app developers can finally build end-user experiences without vendor-specific hacks.

For embedded engineers, implementing LE Audio requires controller firmware that supports ISOAL (Isochronous Adaptation Layer) and host-side stack integration. Nordic, Qualcomm, and Dialog all provide reference implementations, but testing is key – timing drift between links can break audio quality faster than you might expect.

Power & Efficiency Improvements

Battery life has always been Bluetooth’s quiet superpower, and version 6.0 tightens the screws even more. Rather than one big change, it’s a collection of small ones that add up.

Negotiable inter-frame spacing lets devices adjust the delay between packets, smoothing out contention when the air is busy. Controllers now enter deeper sleep states automatically, waking only when the radio truly needs them. Smarter advertising filters prevent devices from wasting time processing duplicates, and new firmware offloads push repetitive tasks (like connection parameter updates) away from the CPU.

When engineers combine all these tricks, the numbers look impressive: about a ten to twenty percent battery gain in dense environments. That might not sound huge, but for a coin-cell tag meant to last three years, it’s the difference between hitting the spec or not.

Security & Privacy Upgrades

With great connectivity comes great responsibility. Bluetooth now sits at the heart of cars, locks, and health monitors, which makes security non-negotiable. The new stack finally treats it as a first-class citizen.

LE Secure Connections with numeric comparison are now standard, encrypted advertising data hides sensitive broadcasts, and Channel Sounding even enables distance-based access control. In plain language, a device can now verify that you’re physically nearby before sharing keys or unlocking features.

Still, protocol features alone aren’t enough. Developers should rotate identity-resolving keys regularly, invalidate old bonds on firmware updates, and avoid static passkeys. Security in Bluetooth is like security anywhere else: the spec provides the locks, but you’re responsible for turning the key.

Together, these improvements make Bluetooth feel more alive, more aware, and more efficient. The stack now senses distance, saves power, and defends privacy without breaking backward compatibility. It’s a quiet revolution hidden inside chips that most people never think about, yet it’s shaping how billions of devices will talk to each other over the next decade.

Real-World Applications in 2025

It’s one thing to read about Channel Sounding or PAwR in a spec sheet. It’s another to see these features come alive in everyday products.

Bluetooth has quietly spread into nearly every corner of our lives, from the shelves of supermarkets to the dashboards of cars. By 2025, it’s no exaggeration to call it the most widely deployed wireless ecosystem on Earth.

Let’s look at where these new capabilities are already making an impact.

Retail: Electronic Shelf Labels and Smart Inventory

Walk into a modern supermarket in 2025 and look closely at the price tags. They aren’t paper anymore. Those little digital labels, changing prices in real time, are powered by Bluetooth 5.4’s Periodic Advertising with Responses (PAwR) and Encrypted Advertising Data.

Each label is a low-power sensor node, quietly listening for broadcast schedules from a gateway mounted above the aisle. When it’s their turn, the tags wake up, confirm their slot, and update the display – all in milliseconds and without forming a traditional Bluetooth connection. The result is a network of tens of thousands of nodes that consumes almost no energy.

Security matters here too. Encrypted advertising ensures that a competing store or curious shopper can’t sniff price data or inject bogus updates. Everything runs on coin-cell batteries that last several years, which saves retailers both time and maintenance costs.

Smart Home: Context-Aware Unlocking and Personal Audio

If you’ve ever fumbled with your phone to unlock a smart door, Bluetooth 6.0 might finally fix that. Channel Sounding makes proximity detection precise enough to trust. The system can tell whether you’re standing by the door or ten meters away in the driveway. Only when you’re truly within range does it trigger the unlock sequence.

The same precision is reshaping personal audio. Imagine walking from your living room to the kitchen and having your smart speaker hand off the song to your earbuds automatically. That’s LE Audio working behind the scenes with isochronous channels, keeping streams perfectly aligned across multiple endpoints. It feels invisible, which is exactly how good technology should feel.

Healthcare: Reliable, Secure Patient Monitoring

Hospitals have long relied on wireless monitors, but interference and power limits made them tricky. With PAwR, a single access point can now coordinate thousands of small sensors that track vitals like heart rate, oxygen, or temperature. These devices communicate in brief, deterministic bursts, avoiding packet collisions that used to plague dense wards.

Privacy is critical, and that’s where encrypted advertising comes in. Patient identifiers and medical readings remain hidden even in broadcast form. Channel Sounding adds another layer by confirming proximity: only readers within a safe range can retrieve sensitive data.

Combined, these features help reduce misreads and protect patient confidentiality without adding extra setup steps for clinicians.

Industry 4.0: Asset Tracking and Condition Monitoring

Factories and warehouses are some of Bluetooth’s biggest playgrounds. Equipment now comes with embedded Bluetooth 6.0 modules that use Channel Sounding for ultra-precise location tracking. Pallets, forklifts, and tools broadcast their position continuously, helping logistics teams know what’s where, all the time.

Add PAwR, and you get scalable telemetry for thousands of machines. Vibration, temperature, or pressure data can flow reliably to a single gateway. Some systems even combine Bluetooth data with AI analytics to predict failures before they happen. The ability to measure distance accurately also helps robots navigate crowded spaces safely.

Wearables: Hearables, AR Glasses, and Health Bands

Wearable devices benefit more than any other category. Modern earbuds use LE Audio to keep both sides synchronized, whether you’re streaming a movie or on a call. Hearing aids receive direct broadcast audio in public venues without special adapters.

AR glasses are an even bigger frontier. They use Channel Sounding to sense spatial relationships between the wearer, nearby devices, and the environment. That allows context-aware overlays – navigation cues, health metrics, or notifications – that appear exactly where they make sense. Bluetooth’s low-power model keeps these systems lightweight enough to run all day.

Automotive: Digital Keys and Vehicle Telemetry

Cars are fast becoming Bluetooth hubs on wheels. Digital Key Systems already use Bluetooth 6.0’s distance measurement to ensure you’re physically close before unlocking or starting the engine. It’s safer than older RSSI-based solutions that could be fooled by signal relays.

Onboard sensors rely on secure connections and encrypted advertising to stream data about tire pressure, cabin air quality, or driver posture. Maintenance centers can access diagnostic data automatically when a car pulls in, without plugging in a cable. In short, Bluetooth has quietly replaced several proprietary systems once needed for short-range communication inside vehicles.

The Big Picture

What’s striking is how flexible Bluetooth has become. The same fundamental protocol now powers medical wearables, industrial sensors, and entertainment systems. Each use case leans on a different mix of features – PAwR for scale, Channel Sounding for precision, LE Audio for experience, and encrypted advertising for privacy – but the foundation is consistent.

It’s this adaptability that explains why Bluetooth continues to thrive despite predictions of its demise. Rather than being replaced by Wi-Fi or UWB, it’s learning from them, borrowing their strengths, and finding new roles.

Developer Guide — Getting Started

Bluetooth 6.0 may sound futuristic, but the good news is that you don’t have to wait years to use it. Most of the new features are already landing in chipsets, SDKs, and development kits. If you’re an engineer or hobbyist itching to get your hands dirty, this section walks you through what to look for, how to get started, and a few pitfalls to watch out for along the way.

Picking the Right Chipset

The chipset you choose sets the tone for your entire project. If you’re building something simple, like a smart tag or sensor, you’ll want a microcontroller with integrated Bluetooth Low Energy and minimal power draw. But if you plan to experiment with Channel Sounding, LE Audio, or PAwR, you’ll need silicon that explicitly supports Bluetooth 5.4 or 6.0 features.

Current front-runners include the Nordic nRF54 series, Dialog DA1470x, and Silicon Labs BG24 family. These are developer-friendly chips with mature SDKs and good documentation. They also have flexible radio subsystems, which matter a lot when you’re testing features like Channel Sounding that depend on timing and signal stability.

A small tip from experience: always check the vendor’s firmware release notes. Some Bluetooth 6.0-capable chips still require you to enable experimental PHY layers or SDK flags to unlock certain features.

SDK and Stack Support

Once you’ve got your hardware, the next step is setting up your software stack. Most Bluetooth development happens through vendor SDKs or open platforms like Zephyr RTOS, ESP-IDF, or BlueZ on Linux.

If you’re targeting embedded systems, Zephyr is a great place to start. It’s modular, stable, and already includes PAwR and LE Audio APIs under its bt_le_ext_adv and iso modules. Silicon Labs’ Simplicity Studio also has strong tooling around Bluetooth mesh and PAwR.

On desktop or gateway platforms, Linux’s BlueZ stack supports extended advertising and secure connections out of the box, and work is underway to integrate Channel Sounding support via new HCI commands.

Always verify that your controller firmware is up to date before testing new features. Many “missing API” errors trace back to outdated controller images that don’t yet recognize the relevant HCI opcodes.

Advertising Strategy

Advertising is still the heartbeat of Bluetooth, and now it’s smarter than ever. Here’s a simple example of setting up extended advertising in C-style pseudocode:

ble_adv_params params = {
    .type = ADV_EXTENDED,
    .interval = 160,   // 100ms interval
    .tx_power = 0      // default transmit power
};

ble_set_adv_data(payload, sizeof(payload));
ble_start_advertising(&params);

Above pseudocode demonstrates how a Bluetooth Low Energy (BLE) device initializes and starts broadcasting advertisements so that nearby devices can discover it. The first block defines a structure named ble_adv_params, which contains the configuration settings for advertising. The .type = ADV_EXTENDED field specifies that the device will use Extended Advertising, a feature introduced in Bluetooth 5.0 that allows for larger payloads, better range, and the use of secondary channels beyond the traditional 31-byte limit of legacy advertising. The .interval = 160 value sets the advertising interval, expressed in Bluetooth time units of 0.625 milliseconds, meaning the device transmits an advertising packet every 100 milliseconds—frequent enough for responsive discovery without excessive power consumption. The .tx_power = 0 field sets the transmit power level to 0 dBm, which is the default radio output power and provides a balanced tradeoff between energy efficiency and signal range. After configuring the parameters, the function ble_set_adv_data(payload, sizeof(payload)) loads the advertising data—typically a collection of identifiers such as the device name, UUIDs for available services, manufacturer-specific data, or other Bluetooth advertising fields. This is the information that other devices see when scanning nearby. Finally, ble_start_advertising(&params) begins the actual transmission, instructing the BLE controller to start broadcasting the configured data on the standard advertising channels (37, 38, and 39). Once active, the device periodically transmits these packets until advertising is stopped manually or a central device establishes a connection. In essence, this short snippet encapsulates the three fundamental steps of BLE advertising: configuring the radio parameters, defining the broadcast data, and enabling the periodic advertisements that make the device visible to others.

This kind of setup works well for extended advertising and PAwR broadcast scheduling. When designing your advertising payloads, remember that the new encrypted format (introduced in 5.4) limits available space slightly, so plan for tighter data packing if you’re including custom fields.

If you’re building something that needs connection-less updates (like a sensor network), use PAwR or periodic advertising. For interactive applications, where you expect users to connect via a phone or hub, extended connectable advertising remains the right choice.

Connection Optimization

Tuning connection parameters is half art, half science. You’ll often find yourself trading latency for battery life. For streaming or LE Audio applications, intervals around 24–40 ms usually strike the right balance. For sensors or telemetry, you can stretch that interval out to save energy.

Sniff subrating is another underrated feature. It lets a peripheral sleep longer while maintaining an active connection, reducing energy use without affecting responsiveness too much.

If you’re testing with multiple devices, simulate busy airspace using tools like Ellisys Bluetooth Analyzer or the nRF Sniffer. This helps uncover timing issues or packet loss that might only show up in dense radio environments.

Power Testing

It’s easy to claim low power on paper – but proving it is another story. Use your dev kit’s current profiling tools to measure sleep and active currents under different intervals and PHY settings.

Run your firmware through long-duration tests in “noisy” airspace – meaning multiple other Bluetooth or Wi-Fi devices nearby. The goal is to see how your firmware reacts when packet retries or interference increase. Sometimes small timing tweaks can make big differences in battery life.

As a general rule, always start testing on the 1M PHY (the default) and only switch to 2M for high-throughput use cases like audio. Long-range modes can be valuable for IoT, but remember that higher receive sensitivity often costs extra current.

Security Checklist

Bluetooth 6.0 brings much stronger built-in security, but you’ll still need to wire it up correctly. Make sure to:

• Use LE Secure Connections instead of legacy pairing.

• Rotate Identity Resolving Keys (IRK) periodically.

• Encrypt advertising payloads whenever transmitting private or medical data.

• Handle key storage securely on your device, preferably with hardware-backed encryption or secure flash.

Also, watch for privacy gaps in the connection flow. Even encrypted devices can leak identity information if they reuse resolvable addresses or fail to clear bonds properly on reset.

Backward Compatibility

Real-world devices won’t all jump to Bluetooth 6.0 overnight. Your code should always detect peer capabilities and fall back gracefully. The HCI layer provides read commands that reveal which features the remote device supports.

For example, if Channel Sounding isn’t available, default to RSSI-based proximity or skip distance-based logic entirely. Similarly, if LE Audio isn’t supported, fall back to classic A2DP. Designing your firmware with this flexibility keeps your products compatible with millions of existing devices.

Testing and Certification

Once your prototype works, you’ll need to qualify it through the Bluetooth SIG Qualification Program. This process ensures your product complies with the spec and interoperates correctly with others. It might sound intimidating, but many vendors offer pre-qualified modules or test reports you can reuse to simplify the paperwork.

For debugging and validation, tools like the Ellisys Bluetooth Analyzer, Frontline BPA 600, or Nordic’s nRF Sniffer can capture over-the-air traffic and help verify packet sequences, timing, and encryption states.

Bluetooth development can be frustrating at first, as there’s lots of acronyms, layers, and hidden dependencies. But once you start seeing the system as a living conversation between devices, it clicks. The more you experiment with advertising intervals, connection timing, and PHY modes, the more you’ll appreciate how elegant and flexible the stack really is.

If you’ve ever wanted to build something that talks wirelessly and runs for months on a battery, this is your moment. The ecosystem has matured, the tools are ready, and the possibilities keep expanding.

Challenges & Trade-Offs

It’s tempting to think of Bluetooth 6.0 as flawless – after all, it’s faster, more efficient, and infinitely scalable. But like every engineering advancement, it comes with trade-offs. Real deployments reveal quirks that the spec sheets don’t mention, and knowing these early can save hours of debugging (and a few late-night rants).

Adoption Lag

Every new Bluetooth spec sounds exciting on paper until you realize the hardware for it isn’t widely available yet. Controller vendors take time to integrate the latest features, and phone or OS support can lag by a year or two. You might find yourself reading about Channel Sounding or PAwR in the core spec, only to discover that your development kit still marks them as “experimental.”

This is normal. The Bluetooth SIG’s release cadence moves faster than the hardware ecosystem can follow. The best strategy is to design firmware that detects capabilities dynamically. Build your code to gracefully fall back to 5.0 or 5.2 modes if 6.0 features are missing. That way your product ships today, but it’s ready for the future.

Environmental Interference

Bluetooth still lives in the 2.4 GHz band, the same noisy neighborhood as Wi-Fi, microwaves, and countless IoT gadgets. In factories or dense apartments, you’ll see interference spikes that cause packet loss or delay. Even with adaptive frequency hopping, performance can dip if too many radios are talking at once.

Developers need to test in real environments, not just in quiet labs. Use spectrum analyzers or sniffers to visualize congestion. Adjust transmit power, advertisement intervals, or even antenna orientation to mitigate problems. Remember, radio design is part science, part art. Sometimes moving a board trace by a centimeter makes more difference than rewriting code.

Power Versus Performance

Every Bluetooth generation tries to squeeze more precision and range out of roughly the same battery. Channel Sounding and high-speed PHY modes improve accuracy and throughput, but they also increase radio-on time and CPU load. You gain features but spend more energy to get them.

There’s no universal setting that fits all products. A hearing aid might value low latency over battery life, while a temperature sensor prioritizes sleeping as much as possible. Developers must tune intervals, transmission power, and frame spacing through measurement, not guesswork. The good news is that once you find the sweet spot, Bluetooth tends to be remarkably stable over long periods.

Security Configuration

Modern Bluetooth has excellent built-in security, but only if you use it correctly. Misconfigured advertising, static passkeys, or unrotated identity keys can still leak information. Even encrypted advertising won’t help if your firmware accidentally reuses session data.

The takeaway: don’t assume “secure by default.” Review every pairing and bonding flow, handle key rotation on firmware updates, and wipe old bonds when a user resets the device. The protocol gives you powerful locks, but it’s up to you to actually turn the key.

Software Complexity

The Bluetooth stack is getting heavier. Features like PAwR, Channel Sounding, and Isochronous Audio require new roles, new timing models, and new APIs. Developers who are used to simple GATT servers now have to think about scheduling, synchronization, and PHY coordination. Testing these features on multi-role devices can be especially tricky, since a single controller might handle multiple concurrent roles (central, peripheral, broadcaster, and observer).

If you’re working on an embedded platform, modular firmware design becomes essential. Split radio control, connection management, and application logic into distinct layers. It’s easier to debug timing bugs when your architecture mirrors the Bluetooth stack’s separation of concerns.

Fragmentation

Perhaps the most persistent challenge is fragmentation. Not every OEM implements the same subset of features, and some phones or chipsets may partially support a spec while skipping optional sections. Developers quickly learn that “Bluetooth 6.0” can mean slightly different things depending on the vendor.

The practical fix is to build flexibility into your software. Use feature discovery at runtime, keep your update mechanism ready for OTA patches, and enable configuration flags for new features so you can toggle them per device. Testing across diverse hardware early in the process pays off more than any elegant design decision later.

Mitigation and Mindset

Despite these challenges, none of them are deal-breakers. They’re simply part of building systems that live in the real world. Think modular, plan for gradual rollouts, and make firmware updates painless. Bluetooth’s backward compatibility means your device won’t become obsolete overnight, and your users benefit from improvements as the ecosystem matures.

In short, the trick isn’t avoiding the trade-offs but managing them. When you design with flexibility, Bluetooth 6.0 becomes less of a moving target and more of a living platform that grows alongside your product.

The Road Ahead — Bluetooth 6.1 and Beyond

If Bluetooth 6.0 was about awareness – knowing distance, filtering intelligently, and optimizing communication – then Bluetooth 6.1 is about refinement. It takes what already works and polishes it into something smoother, faster, and a little more elegant. It’s not a revolution, but it’s an important step in Bluetooth’s quiet transformation from a “wireless cable” into a context-aware network fabric for everyday devices.

Small Tweaks, Big Payoffs

Bluetooth 6.1 focuses on tightening the nuts and bolts rather than changing the whole machine. The update improves Channel Sounding accuracy, enhances advertising efficiency, and introduces a few quality-of-life adjustments to make device coordination easier.

That might sound minor, but it matters. Channel Sounding, for example, becomes more reliable when multiple reflections or obstacles exist. In indoor positioning systems like airports, hospitals, or museums, even a five percent improvement in accuracy can reduce false detections by a wide margin. Advertising refinements also make large IoT deployments more predictable, allowing gateways to manage high-density environments with less radio congestion.

In simpler terms: Bluetooth 6.1 is like a firmware tune-up for an already fast car. You may not notice it day to day, but under heavy load, it performs better and wastes less energy.

The Emerging Themes

Beyond the incremental fixes, the Bluetooth community is thinking much bigger. The next few years will likely focus on four major themes: energy harvesting, AI-assisted radio optimization, hybrid positioning, and context-aware security.

1. Energy-Harvesting Bluetooth Devices

We’re starting to see early prototypes of Bluetooth tags and sensors that run entirely on harvested energy – light, heat, or vibration – with no traditional battery. This ties into the push for maintenance-free IoT devices, especially in logistics and environmental sensing. Future specifications will refine ultra-low-duty-cycle communication patterns to support these “powerless” nodes.

2. AI-Driven Radio Management

Imagine a Bluetooth controller that dynamically learns the noise profile of its environment and adjusts its PHY, transmit power, or advertising timing in real time. Instead of a static table of parameters, AI models embedded in the firmware could predict interference and choose the best channel map automatically. It sounds futuristic, but chipmakers are already experimenting with machine learning cores in connectivity modules.

3. Cross-Technology Fusion (Bluetooth + Wi-Fi + UWB)

The border between short-range radios is blurring. Some systems already use Wi-Fi for throughput, Bluetooth for discovery, and UWB for pinpoint accuracy – all orchestrated by a single chipset. The goal isn’t to replace one with another but to fuse them, creating hybrid location frameworks that are more reliable than any single technology. Bluetooth’s Channel Sounding makes it a perfect partner in this mix.

4. Context-Aware Security

Future Bluetooth devices might decide access rights based not just on identity, but on context. For example, your smartwatch could unlock your laptop only if it detects that you’re sitting still and within one meter. That combination of motion, distance, and authentication could drastically reduce spoofing or relay attacks.

The Quiet Backbone of Connectivity

What’s fascinating about Bluetooth’s evolution is how quietly it happens. While other technologies make noise about high throughput or low latency, Bluetooth’s progress feels invisible but omnipresent. It doesn’t chase raw speed anymore – it chases relevance. The protocol is learning to sense, adapt, and coordinate, all qualities that make it essential for the next generation of ambient computing.

So while you might not notice Bluetooth 6.1 when it arrives, you’ll definitely feel its effects. Devices will sync faster, connections will drop less, audio will sound cleaner, and proximity-based features will just “know” what you want them to do. That’s the beauty of mature engineering: when it works so seamlessly that people stop thinking about it altogether.

Conclusion

Bluetooth has come a long way from its early days as a clunky pairing protocol for headsets. It’s now one of the quietest yet most influential technologies shaping how devices around us communicate. The newer generations – 5.4, 6.0, and soon 6.1 – show that Bluetooth’s evolution isn’t about flashy upgrades. It’s about refinement, about making wireless communication more precise, more private, and more power-aware.

At its core, Bluetooth’s story is about context. It’s learning to understand where you are, how far you are from something, and what kind of connection makes sense in that moment. Channel Sounding adds spatial awareness, PAwR makes massive IoT networks practical, LE Audio brings synchronized sound to earbuds, hearing aids, and broadcast systems, and encrypted advertising protects the information flowing through all of it.

For developers, this era of Bluetooth is exciting because it’s full of creative possibilities. You can build smarter sensors, more responsive wearables, or secure access systems that simply know when you’re nearby. The ecosystem is mature enough that you don’t need to be a radio engineer to experiment, but it’s still evolving fast enough to keep pushing boundaries.

The challenge now is not whether Bluetooth can handle the future. It’s how we, as developers and designers, decide to use it. Whether it’s powering ambient computing, healthcare networks, or next-gen audio, the technology is already ready.

So maybe the next time you put on your earbuds or unlock your car, take a moment to appreciate the quiet genius working behind the scenes. Bluetooth is thriving, adapting, and quietly building the connective tissue of our digital lives.

And for those of us who like tinkering with the unseen layers of technology, that’s a future well worth exploring.

I work as a Bluetooth software engineer on wearable devices like smart-glasses, and I’ve spent more time than I’d like to admit chasing down why these things break.

In this article, I’ll give you a peek behind the curtain: how Android’s Bluetooth stack actually works, why it sometimes feels unpredictable, and what you can do as a developer to make your apps or system more reliable.

Bluetooth in Plain English

At its core, Bluetooth is just a conversation between two devices. But it isn’t one simple line of communication – it’s multiple layers stacked on top of each other.

• The radio (Controller): Sends and receives the actual signals over the air medium.

• The software brain (Host stack): Decides whom to talk to and how, as well as if it wants to.

• Profiles: Define the purpose of the conversation – like streaming music or syncing health data.

• Protocols: Define how to talk to the other device.

There are two big “flavors” of bluetooth:

• Classic (BR/EDR): Used for things like headphones and car kits. Can lift more weight.

• Low Energy (LE): Used for fitness bands, beacons, and most wearables. Can sustain longer.

Most modern gadgets use both at once. That’s powerful, but it also opens the door for more things to go wrong.

Why Android Adds Its Own Quirks

On Android, Bluetooth isn’t just one neat package. It’s a chain of moving parts:

• Your app calls BluetoothAdapter.

• Those go into system services like AdapterService.

• Then into native code through JNI (Java Native Interface).

• Then into the chip vendor’s Bluetooth stack.

• Finally, it hits the radio hardware.

Every phone maker ships a slightly different Bluetooth chip and firmware. That means the exact same Bluetooth app might behave differently on a Samsung, a Pixel, or any other budget phone running Android.

The Real Problems Behind “It Just Disconnected”

Here are a few of the common headaches I see, explained simply:

Bonding issues (the “lost keys” problem)

When two Bluetooth devices pair, they exchange encryption keys (link keys for Classic, Long Term Keys for LE) and store them in non-volatile memory. These keys are what let the devices recognize each other later and reconnect securely without asking the user again.

A “mismatched memory” problem happens when one device’s stored keys don’t match the other’s anymore. This can be caused by:

• A firmware update or OS upgrade that wipes or regenerates keys.

• A factory reset or “forget device” on one side but not the other.

• Keys being corrupted or evicted by the system to free up storage.

From the user’s perspective, the device may still look paired (shows up in the Bluetooth menu), but connections mysteriously fail with errors like “Authentication Failed” or “Insufficient Encryption.” The only cure is usually to delete the device on both ends and re-pair, which feels ridiculous to non-technical users.

Timing mismatches

Bluetooth devices don’t just chat whenever they want, they agree on a connection interval – essentially a schedule for when each side will “wake up” and exchange packets. Think of it as two people agreeing to meet every 30 minutes at a café.

A mismatch happens when:

• The two sides negotiate different intervals but don’t fully agree (for example, one thinks it’s 30ms, the other 50ms).

• One side’s firmware update or configuration change alters its timing policy.

• Radio conditions cause one side to miss multiple scheduled check-ins, drifting the clocks apart.

• Power-saving logic (like a phone going into Doze mode) silently stretches out the interval.

This explains why a connection might work fine at first but start failing later: the devices initially synced on an interval, but then one side’s policy or behavior shifted. From the user’s perspective, it looks like audio stuttering, laggy input (on game controllers), or random disconnects after “it was working fine before.”

Unexpected disconnections

When a Bluetooth link ends, the radio layer (the controller) and the higher-level OS stack (the host) are supposed to exchange clear signals. The controller sends an HCI Disconnection Complete event (basically: “Goodbye, we’re done”). And the host should then update its internal state, clean up the GATT/ACL session, and be ready for reconnection.

But in practice, this doesn’t always line up:

• Sometimes the controller says goodbye cleanly, but the host stack doesn’t update its state properly. The app still “thinks” the connection is active, so reconnect attempts silently fail.

• Some platforms aggressively cache connection state (especially iOS). If the OS believes the connection is still valid, it won’t trigger a new connection attempt until you toggle Bluetooth or reboot.

• A race condition can occur if the disconnection event happens while another operation (for example, service discovery, bonding, or encryption setup) is in flight. The OS may get confused about what state the device is really in.

• On some devices, a fast reconnect attempt after a clean disconnection collides with internal cooldown timers. The controller ignores it, leaving the app waiting.

From the user’s perspective, the device looks “stuck.” The only way to recover is to toggle Bluetooth, restart the app, or power cycle the accessory, even though technically nothing “failed.”

How Developers Can Do Better

If you’re building a Bluetooth app, here are a few habits that save a lot of pain:

Check for bonded devices first

One of the most common causes of failed connections is mismatched bonding information: the phone and the accessory no longer share the same encryption keys. Even if the device appears in the UI, the OS may have lost its keys.

Before attempting a connection, always query the system’s bonded device list with BluetoothAdapter.getBondedDevices(). For example:

if (adapter.getBondedDevices().contains(targetDevice)) {
    targetDevice.connectGatt(context, false, gattCallback);
} else {
    showToast("Please re-pair this device to restore the connection.");
}

This ensures you only attempt secure connects to devices the OS still trusts. If the target device isn’t in the bonded list, you can give the user a clear instruction (“Please re-pair this device”) instead of leaving them with confusing connection errors.

Handle callbacks carefully

Another subtle pitfall is assuming that a STATE_CONNECTED event means a connection was successful. In reality, onConnectionStateChange() can report a connected state even when the underlying operation failed, the real result is in the status argument. To avoid chasing phantom connections, always check both status and newState:

if (status == BluetoothGatt.GATT_SUCCESS &&
    newState == BluetoothProfile.STATE_CONNECTED) {
    gatt.discoverServices();
} else {
    gatt.close();
}

This pattern prevents you from attempting service discovery on a dead connection and ensures stale sessions are closed promptly, leaving the stack ready for a clean retry.

Expect failures

Bluetooth connections fail all the time in the real world – devices drift out of range, interference spikes in the 2.4 GHz band, or the radio is simply busy. The worst thing an app can do is retry instantly in a tight loop, which drains the battery and makes the stack unstable.

A better approach is to implement exponential backoff like this:

long delay = (long) Math.min(250 * Math.pow(2, attempt), 30000);
new Handler(Looper.getMainLooper()).postDelayed(connectAction, delay);

This means your first retry happens quickly (~250 ms), but subsequent retries slow down (500 ms, 1 s, 2 s…), capped at a reasonable maximum. Backoff makes your app resilient without overwhelming the radio or the OS.

Use the right tools

Without visibility into what’s happening under the hood, connection problems look random. Tools like nRF Connect let you interactively scan, connect, and run GATT operations against your device, while Android’s Bluetooth HCI snoop log reveals the actual packets being exchanged. For example:

Settings.Secure.putInt(context.getContentResolver(), "bluetooth_hci_log", 1);

Once enabled, you can capture a logcat trace and confirm whether a failure is due to missing keys (Insufficient Authentication), a timing mismatch, or interference. Using these tools not only helps you debug your app, it also proves whether the issue lies in your code, the OS, or the accessory firmware.

Bigger Lessons

Working with Bluetooth taught me lessons that apply to engineering in general:

• Wireless is never perfect, so always build with recovery in mind.

• Logs and metrics aren’t optional. They’re your map through the chaos.

• The simplest solution usually survives best in the messy real world.

Conclusion

Bluetooth is messy because it’s a chain of hardware, firmware, and software all trying to cooperate. On Android, the variety of chips and vendors makes it even trickier.

But that doesn’t mean you’re helpless. By understanding how the layers work and designing your apps with retries, checks, and proper logging, you can make Bluetooth feel a lot less “weird” for your users.

The next time your earbuds misbehave, you’ll know – it’s not you. It’s just Bluetooth being Bluetooth.

⚡ This is the first of a number of articles I’m going to write on Bluetooth development. In the next one, we’ll dive deeper into how to build a secure Bluetooth Low Energy (BLE) GATT client and server on Android. Stay tuned!

The thing is that most solar inverter brands have a form of remote data monitoring platform, from Victron’s VRM to Growatt’s ShineServer to Deye’s Cloud, among others. But I’m a fan of self-hosting and local control of data. This is one of the best ways to visualize and showcase all that beautiful data you have publicly to fellow tinkerers, solar inverter users, and the general public without relying on the company’s cloud data logger solution.

In this article, we will be using data available in our Home Assistant setup, sending it to InfluxDB and making a Grafana dashboard out of it. There are a good number of ways to connect your inverter to Home Assistant, depending on the manufacturer. I use a Growatt SPF ES 6000 inverter, and I shared a guide on how to make a local data logger for it that works with Home Assistant here.

Table of Contents

• Prerequisites

• How to Install and Configure InfluxDB

• How to Install and Configure Grafana

• How to Create the Grafana Solar Dashboard

• How to Create a New Admin User and Delete the Default Admin User

• How to Enable Remote Access to the Solar Dashboard

• Conclusion

Prerequisites

• Home Assistant OS

• A domain name

• An inverter connected to your Home Assistant instance

How to Install and Configure InfluxDB

We will be starting by setting up InfluxDB. InfluxDB is an open-source time series database, which differs from the database that Home Assistant uses by default, SQLite. We will be using InfluxDB v1, as it’s much easier to set up.

Go to your Home Assistant dashboard and go to Settings > Add-ons and click on the Add-On Store.

Inside the Add-on Store, search for “InfluxDB“ and click on the Add-on. You should see the screen below, then install.

Toggle the “Watchdog” on, as this allows the add-on to restart if it crashes. Also, toggle the “show in sidebar” on, which allows you to see the add-on on Home Assistant’s sidebar.

Start the add-on and look at the logs to be sure it is working. The “Starting NGINX” is an indicator it’s working.

Next, go to your Home Assistant sidebar and click on InfluxDB. You need to create a new database to hold your data and also create a new user that has admin privileges to read and write data. Go to the InfluxDB Admin tab.

Click on Create Database – and you can name the database anything you want. I will be naming mine homeassistant.

By default, the retention policy for a created database is infinity (which is forever), but you can configure this to be any time frame you want. Retention policy refers to the time frame of data the database can hold. I prefer to stick with infinity as I want to keep as much data as possible and I have enough storage in my Home Assistant hardware for that.

Once the database is created, go to the Users tab so you can create the new admin user. Input a username and password for that user and click on Grant Admin, so the permission level can be set to all. I created a new user called root.

At this point, what is left on the InfluxDB side is to tell Home Assistant to start sending sensor data to InfluxDB. You can do this by going to your Home Assistant configuration.yaml file and adding this config below to it. Your host is the IP of your Home Assistant, the port is the default port for the InfluxDB add-on, and the remaining values are based on the values you used during setup.

influxdb:
  host: 192.168.8.12
  port: 8086
  database: homeassistant
  username: root
  password: password
  max_retries: 3
  default_measurement: state

Restart your Home Assistant and go to InfluxDB. Click on the Explore tab, and check to see if you have a database.autogen file there. Click on it, and if you see some values under Measurements & Tags, you are good to go.

How to Install and Configure Grafana

Next on our agenda is to install and configure Grafana. The goal is to have Grafana query InfluxDB and make dashboards based on the queried data.

Go to the Add-on store, search for Grafana, and install it. Remember to toggle on those important settings, then start the add-on.

Once it has started, click on Grafana on the sidebar. You will arrive at Grafana’s homepage which is where you can create those dashboards.

But before you do that, you need to connect InfluxDB to Grafana. Navigate to Grafana’s tab >> Connections. You should see an “Add new connection” page. Search for InfluxDB and choose it. Then click on the add new datasource button.

Under HTTP, edit the URL and use http://ha_ip_address:8086 – don’t omit the http:// or try to use localhost with it. Scroll down to the InfluxDB Details and fill in the data you used while setting up InfluxDB. Then click on Save & Test. If the config is correct, you should see a green tick and text saying “datasource is working…measurements found.”

How to Create the Grafana Solar Dashboard

With that, you should have InfluxDB running and connected to Grafana. Let’s get to building beautiful dashboards out of all the data being generated. This part is subjective, so you can feel free to edit and modify the design to your taste. We will be using this dashboard here as the inspiration for our design.

So now go to your Grafana in Home Assistant, click on the + icon and create a new dashboard.

You should know that a dashboard in Grafana refers to the full space and each thing placed on the dashboard is a panel. Each visualization on the dashboard is a panel.

Let’s create a new panel. Pick InfluxDB as the data source, and at the FROM row, pick W which is the unit we want to create a visualization from. WHERE is entity_id::tag, as that is the way to sort the values by Home Assistant sensor entity name. Then pick the entity id of your panel – mine is growatt_pv1_charge_power. You can change the panel title, change the visualization to stat, and add the watt as the unit and the base colour to yellow.

The raw query looks like this:

SELECT mean("value") FROM "W" WHERE ("entity_id"::tag = 'growatt_pv1_charge_power') AND $timeFilter GROUP BY time($__interval) fill(null)

The Grafana edit page looks like this:

At this point, you should be able to recreate the remaining parts of the dashboard. But I manually did all that, so you don’t have to go through it all yourself if you don’t want to.

Here is the link to a GitHub repo that has the JSON file of this dashboard. When you go to create a dashboard, you will see an option to import from a JSON file. You can choose to copy and paste or upload the file, whichever works for you.

After importing, you only need to edit each panel through the GUI to use your own entity ID tag in Home Assistant and also the UID of your InfluxDB database.

Here is a picture of my finished result:

How to Create a New Admin User and Delete the Default Admin User

By default, the Grafana Add-on in Home Assistant uses an auth proxy and creates a default user (admin) with a password (hassio) that's synced with your HA login session. This prevents password or user changes through the UI.

For context, an auth proxy, or authentication proxy, acts as an intermediary between a client and a target resource, handling authentication and authorization on behalf of the client

As a security step, we need to create a new user for the Grafana Add-on and edit their permission to have admin privileges, then delete the default admin user. This is because you can’t change the default admin user password on the Add-on.

Go to Grafana’s menu > Administration> Users and access > Users. Then create a new user.

Next, give it admin privileges. Edit Grafana Admin to be yes and make sure the organization role is set to admin, then save.

Go back to the Add-on Configuration tab. Scroll to the Network setting and add a port to expose the Add-on. I will be using port 3000. Save and restart the Add-on. If you have SSL turned on and it isn’t configured, the add-on won’t start. You can disable it as we will have Cloudflare handle that.

To confirm that the port has been exposed properly, go to http://ha_ip:3000/ and confirm you see this Grafana login screen. Make sure it is http and not https.

Log in as the new user you created. Then go to your list of users and delete the default admin user.

After that, go back to the Grafana Add-on Configuration tab. Click on the 3 dots on the Options row and choose Edit in YAML. Then add this line below to your configuration file and save.

grafana_ingress_user: usernameofnewuser

How to Enable Remote Access to the Solar Dashboard

At this point, we have the solar dashboard all ready and we can access it in Home Assistant while inside our home network. But we don’t want it only that way. We want anyone to be able to visit the link without having access to our home network.

I will be implementing this part with the aid of a Home Assistant Cloudflared Add-on that leverages Cloudflare Tunnel. Here is the Github repository – the installation is simple and stress-free.

After going through the setup and having remote access to your Home Assistant network (remember to have 2FA turned on), go to the Cloudflared Add-on configuration tab and edit the Additional Hosts part.

- hostname: subdomain_you_want.your_domain.xyz
  service: http://ha_ip:3000
  disableChunkedEncoding: true

Save and restart the Add-on and check the logs. You should see it creating a DNS entry for the hostname you added.

As another security step, go to your Grafana Add-on Configuration tab. Add these values to the environment variables.

- name: GF_AUTH_ANONYMOUS_ENABLED
  value: "true"
- name: GF_AUTH_ANONYMOUS_ORG_ROLE
  value: "Viewer"
- name: GF_AUTH_DISABLE_LOGIN_FORM
  value: "true"

• GF_AUTH_ANONYMOUS_ENABLED: Anyone who visits Grafana without logging in will still be allowed in.

• GF_AUTH_ANONYMOUS_ORG_ROLE: This sets the default permission for anonymous users. In this case, anonymous users will have the viewer role.

• GF_AUTH_DISABLE_LOGIN_FORM: Disables the login form on the Grafana login page. Make sure you are already logged in on the remote hostname. But you can always edit this on the Add-on Configuration tab if you get locked out.

Wrapping Up

Finally, go to the Remote hostname for your Grafana and you should see the Grafana home page. Then go to your dashboards and click on the solar dashboard created. Share it and choose publicly. Now you can share that link (the URL on that page and not the actual copied URL from the share button) with anyone and they can get to see your beautiful dashboard.

This method serves as an all-in-one way of having everything done, through your Home Assistant machine. I hope you had fun tinkering, see you next time.

This VPN will allow you to access your home network from anywhere as if you’re still at home. So why is this useful, you might ask? Well, it allows you to use your home network IP, no matter where you are, which is a good for privacy.

In this article, we’ll use Tailscale, an open-source mesh VPN (Virtual Private Network) service that streamlines connecting devices and services securely across different networks. It enables encrypted point-to-point connections using the open-source WireGuard protocol. This means that only devices on your private network can communicate with each other.

Table of Contents

• Prerequisites

• Install Raspberry Pi OS Lite (32-bit)

• Boot The Raspberry Pi

• SSH Into The Raspberry Pi and Login

• Install Tailscale on Raspberry Pi

• Key Expiry

• Configuring the Raspberry Pi as an Exit Node

• Conclusion

Prerequisites

• Raspberry Pi (I am working with a Raspberry Pi 5)

• Raspberry Pi Imager

• A Micro SD Card (8GB is enough)

• A Micro SD Card reader for your computer.

• Home Router

• A Tailscale account

Install Raspberry Pi OS Lite (32-bit)

We’ll start this process by installing the Raspberry Pi OS Lite (32-bit) on the micro SD card we have. We will be making use of the Raspberry Pi Imager software which is available for free here.

When you run the imager software, pick the Raspberry Pi Device, which for me is a Raspberry Pi 5.

Then in Operating System, click on Raspberry Pi OS (other), then scroll down to Raspberry Pi OS Lite (32-bit)

Next, select your SD card which you have inserted into the card reader, and the card reader into the computer. Your screen should look similar to what you see below. Click on next.

After next, you should see a pop-up asking if you would like to apply OS customisation settings.

Next, click on edit settings. Enable set hostname and write the name you want to give the Pi. For this tutorial, I will be using dapivpn. Then enable set username and password. Pick a username and a strong and secure password

You can enable configure wireless LAN if you plan to use Wifi, but if you are team Ethernet cable, you can skip this. I will be using WiFi in this tutorial though.

Now you’ll need to enable set local settings and pick your correct time zone and keyboard layout.

After that, go to the Services tab, then enable SSH and click on “Use password authentication”. Then click save, then yes on the apply customisation screen, and yes again. Remember this will erase all the data on the SD card, so make sure you’re using one without any important files on it.

This is how your Raspberry Pi Imager should look now:

Boot the Raspberry Pi

After this is done, take the SD card and insert it into your Raspberry Pi. Then plug the power cable into the Raspberry Pi and wait some minutes for it to boot properly. You will know it is ready when the green LED light stays on.

Now you should go to your router and set a static IP to the Raspberry Pi. For mine, I set it to 192.168.8.21.

SSH into the Raspberry Pi and Login

Open up your command line terminal. Type “ssh <pi username>@<raspberry_pi_ip_address>”. For me, this would be:

ssh danpi@192.168.8.21

Then type in the password you used. You should see your username and the Pi hostname and this confirms you have logged in successfully to it.

Type in:

sudo apt update && sudo apt upgrade -y

You run this command to make sure everything is up to date locally.

Now reboot your Pi after this by typing:

sudo reboot

Install Tailscale on Raspberry Pi

Now you’re going to add Tailscale’s package signing key and repository.

curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null 
curl -fsSL https://pkgs.tailscale.com/stable/debian/bookworm.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list

Install Tailscale using these commands:

sudo apt-get update
sudo apt-get install tailscale

Next, you need to connect your Pi to your Tailscale network and authenticate. You can do that with the following command:

sudo tailscale up

Your browser should look like this.

To locate the Tailscale IPv4 address for the Raspberry Pi, run this command:

tailscale ip -4

You can also see it on the Tailscale dashboard in your browser.

At this point, you’re done installing Tailsacle and you just need to do some finishing touches.

Key Expiry

There is something you need to know when it comes to adding a device to Tailsacle. By default, and as a security feature, Tailscale requires devices to re-authenticate after a certain period of time has elapsed, usually 180 days.

If the re-authentication does not occur, keys expire and the connection stops working. It’s up to you to choose what you prefer, as this is a security feature that comes with some inconvenience.

I will be disabling the key expiry on the Raspberry Pi, as I fully trust it. To do this, you need to:

• Open the Machines page of the Tailscale admin console.

• Find the Raspberry Pi on the row and select the option menu there.

• Click on the Disable Key Expiry option. You should see an Expiry Disable label below the machine name.

How to Configure the Raspberry Pi as an Exit Node

Another thing you’ll need to know about when it comes to Tailscale is what an exit node is. A Tailscale exit node is a designated device in your Tailscale network that routes all of your internet traffic through it. No matter where you are, once you have this device activated as an exit node, when you turn on Tailscale, it routes your internet traffic through the device.

Ideally, you want a device that is powered on 24/7 to serve as your exit node. That’s why we are picking the Raspberry Pi, as it is a low-powered computer.

We are already 90% of the way, as we have Tailscale running on our Pi. Remember to also have Tailscale installed on as many devices on your local network as possible. What’s left is to allow your Pi to act as an exit node, so all your internet traffic or LAN traffic routes through it, giving you access to:

• Local network devices at home

• Your home public IP

• Internal services like NAS, printers, cameras, and so on

To do this, SSH into your Raspberry Pi and follow these steps:

• Enable IP Forwarding. IP forwarding allows your Raspberry Pi to pass traffic between its network interfaces. Run the commands below line by line:

    echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
  
    echo "net.ipv6.conf.all.forwarding=1" | sudo tee -a /etc/sysctl.conf
  
    sudo sysctl -p /etc/sysctl.conf
  

• Advertise the Raspberry Pi as an exit node:

    sudo tailscale up --advertise-exit-node
  

• Open the Machines page of the Tailscale admin console.

• Find the Raspberry Pi on the row. You should see an Exit Node label on its name.

• Click on the options menu there and select Edit Route Settings.

• Check the box for Use as an exit node, then save.

Now you should see the option of routing the internet through an exit node when you open up your Tailscale app on mobile or PC or anywhere you have it installed. When you see that option, you will also see the Raspberry Pi as an exit node option. You can also add more devices as an exit node if you want more options.

Conclusion

Using the Tailscale app on other devices, you can now route traffic securely through the Raspberry Pi by selecting it as an exit node. Tailscale also provides clear, step-by-step guides tailored to each device type for setting up and using an exit node.

You can now be away from your home internet but still connect to the internet as if you were home. See you next time.

We just published a Home Automation with ESP32 course on the freeCodeCamp.org YouTube channel, created by Ebenezer Asabre. This course walks you through every step of building a smart system, from setting up the hardware to developing a web-based control interface. By the end of the course, you’ll have a fully functional system that you can customize and expand further.

What You’ll Learn

• Hardware Setup: You’ll start by setting up the ESP32 microcontroller, LEDs, and servo motors, establishing a solid hardware foundation for your smart system.

• System Architecture: Understand how different components—hardware, software, and communication protocols—work together to create a seamless system. You’ll also learn to design a software flowchart to guide your project development.

• MQTT Protocol: Learn how to configure the ESP32 as an MQTT client to send and receive messages. The MQTT protocol is a key technology for Internet of Things (IoT) projects, enabling efficient communication.

• Database Management: Use PostgreSQL to manage your system’s data and integrate it with a Node.js server. You’ll set up models for storing and handling automation system information.

• Server Design: Master the modular structure of a Node.js server with service, controller, and route modules, making your application maintainable and scalable.

• Real-Time Communication: Implement an MQTT broker and real-time communication using Socket.io to establish reliable connections between your ESP32 devices and control interface.

• Web-Based Control: Build a user-friendly front end using HTML and Embedded JavaScript (EJS). This interface will let you control your smart devices remotely and interact with your system intuitively.

Why Take This Course?

This course is perfect for anyone interested in IoT, whether you're a hobbyist exploring automation or a developer looking to expand your skill set. You'll gain practical experience with popular technologies like ESP32, MQTT, PostgreSQL, and Node.js, all while working on a real-world project. By the end of the course, you'll understand how to design, build, and deploy smart systems using industry-standard tools and techniques.

What You’ll Achieve

• Practical Knowledge: Work hands-on with ESP32 microcontrollers and key IoT technologies.

• Software Development Skills: Create robust applications using Node.js, MQTT, and PostgreSQL.

• System Design Expertise: Learn to design and build scalable, real-time systems.

• A Portfolio Project: Develop a fully functional home automation system you can showcase to employers or use as a foundation for future projects.

Watch the full course on the freeCodeCamp.org YouTube channel (1-hour watch).

In this guide, I’ll show you how to set it up using Docker for a streamlined, privacy-focused smart home. Docker provides an efficient way to run Zigbee2MQTT as a standalone service, offering a lightweight, modular setup – no Home Assistant required.

Table of Contents

• Key IoT Concepts in this Tutorial

• What You’ll Need

• What You’ll Do

• How to Prepare Your Environment

• How to Set Up the Zigbee2MQTT Configuration

• How to Set up Zigbee2MQTT and MQTT Broker in Docker

• Launch the Containers

• Pair Your Zigbee devices

• How to Create an Automation Script

• What’s Next?

Key IoT Concepts in this Tutorial

Here are the key concepts related to the Internet of Things (IoT) and smart homes that you’ll be working with:

• Zigbee is a wireless communication protocol used in smart home devices. It relies on a Zigbee coordinator to communicate with devices like lights, sensors, and switches within a local mesh network. This network allows devices to relay signals to extend coverage and reliability.

• MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol for low-bandwidth and high-latency environments. It uses an MQTT broker to manage communication between devices using a publish/subscribe (pub/sub) model, where devices can either send or receive messages based on specific topics.

• Zigbee2MQTT is a bridge application that connects Zigbee devices to an MQTT broker. It translates Zigbee signals into MQTT messages, and vice versa. Zigbee2MQTT supports a wide range of devices from different manufacturers.

What You’ll Need

1. A Zigbee coordinator connected to your network or device. I have an SLZB-06 ($65 USD) connected to my network.

2. A device capable of running Docker, such as a Raspberry Pi or Linux server. I flashed a Raspberry Pi 4 - Model B.

How to Prepare Your Environment

1. SSH into your Pi using the following command in your terminal window, where pi is the username of your Raspberry Pi OS and <RaspberryPi_IP> is the IP address of your Raspberry Pi on your local network.

    ssh pi@<RaspberryPi_IP>
   

2. Install Docker by inputting the following command at the SSH prompt.

    curl -sSL https://get.docker.com | sh
   

3. Give permissions to the current logged in user. You may then need to close the SSH connection, and re-connect, if the permissions hasn’t taken effect.

    sudo usermod -aG docker $USER
   

How to Set Up the Zigbee2MQTT Configuration

1. Create a new project directory, and also a /data directory to store configuration files and data persistently.

    mkdir -p ~/zigbee2mqtt/data
   

2. Create the configuration file.

    touch ~/zigbee2mqtt/data/configuration.yaml
   

3. Open file with your preferred text editor, like using nano as shown below.

    nano ~/zigbee2mqtt/data/configuration.yaml
   

4. Paste the following YAML code into the configuration file from the text editor interface.

    homeassistant: false
    permit_join: false
    mqtt:
      base_topic: zigbee2mqtt
      server: 'mqtt://mqtt:1883'
    serial:
      port: 'tcp://<IP_OF_ZIGBEE_COORDINATOR>:<PORT>'
    frontend:
      port: 8080
   

5. Update the following details within the configuration.yaml file, and save the changes.

   • <MQTT_BROKER_IP>: Your MQTT broker's IP or hostname.

   • port: This value depends on how your Zigbee coordinator is connected:

     • If your Zigbee coordinator is connected to the network, you can configure the port using TCP/IP as shown in the example above, for example tcp://192.168.1.xxx:6638 where the SLZB-06 is located at 192.168.1.xxx on the local network and 6638 is the default port for that Zigbee coordinator.

     • If the Zigbee coordinator is connected to your device, you can find the serial port (such as /dev/ttyUSB0) by running ls /dev/tty* before and after plugging in the adapter to your device.

How to Set up Zigbee2MQTT and MQTT Broker in Docker

1. In the root of your project directory, create a docker-compose.yaml file to set up the Zigbee2MQTT container and Eclipse Mosquitto broker container to handle communication between Zigbee2MQTT and other services.

    services:
      zigbee2mqtt:
        container_name: zigbee2mqtt
        image: koenkk/zigbee2mqtt
        restart: unless-stopped
        volumes:
          - ./data:/app/data
          - /run/udev:/run/udev:ro
        ports:
          # Frontend port
          - 8080:8080
        environment:
          - TZ=American/Los_Angeles
      mqtt:
        image: eclipse-mosquitto:2.0
        restart: unless-stopped
        volumes:
          - "./mosquitto:/mosquitto"
        ports:
          - "1883:1883"
          - "9001:9001"
        command: "mosquitto -c /mosquitto-no-auth.conf"
   

2. Update the TZ environment variable if you are located in a different time zone, and save any changes.

Launch the Containers

1. Run the containers.

    docker compose up -d
   

2. Test the setup by checking the logs to confirm Zigbee2MQTT is running without errors. And look for lines indicating successful connection to the MQTT broker and Zigbee network initialization.

    docker compose logs
   

Pair Your Zigbee devices

1. Once Zigbee2MQTT is running smoothly, you can access the frontend at http://<your-device-IP>:8080 from a web browser to pair and manage your Zigbee devices.

2. Enable pairing by clicking Permit Join (all), and then pair your devices by putting them in pairing mode, for example holding down a reset button.

3. Finish pairing all the Zigbee devices that you wish to use in an automation. In the screenshot below, I have paired an Aqara button and Third Reality smart plug.

   

4. Give your devices a friendly name by using the pencil icon. Make sure to choose a unique name to avoid messaging conflicts in the following steps. For example, if you have 2 smart plugs, you can name them smart-plug-bedroom and smart-plug-office.

MQTT brokers follow a pub/sub messaging pattern which involves the following:

• Subscribing to MQTT topics like zigbee2mqtt/aqara-button to monitor device states like listening for button presses.

• Publishing to MQTT topics like zigbee2mqtt/third-reality/set to send commands to devices like a smart plug to turn on a light.

A topic such as zigbee2mqtt/third-reality/set is broken down into 3 parts:

• zigbee2mqtt refers to the base topic (default for Zigbee2MQTT is zigbee2mqtt).

• third-reality refers to a specific device or group using the friendly name shown in the Zigbee2MQTT frontend.

• set allows you to control the device or group using a JSON message such as {"state": "TOGGLE"}.

1. Input the following command to see the MQTT messages being published to Zigbee2MQTT.

    docker logs -f zigbee2mqtt
   

2. Complete an action on a Zigbee device, for example pushing a button, and make a note of which topics you want to utilize in your automation for the next steps. For example, in the screenshot of the logs below, there is an MQTT topic published called zigbee2mqtt/Aqara when the Aqara button is pressed.

How to Create an Automation Script

To set up an automation, you can use an external system like Home Assistant or Node-RED, or use Zigbee2MQTT’s external converters to respond to MQTT messages from the broker.

You won’t be doing that. Instead, let’s write a JavaScript script to handle this automation, to keep the functionality modular and independent.

1. From the command line prompt of your terminal window, install the NodeSource setup script on your Raspberry Pi.

    curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
   

2. Install Node.js to use as the runtime for your script.

    sudo apt install -y nodejs
   

3. Verify the installation went smoothly by showing the installed version.

    node -v
   

4. Install MQTT.js, the MQTT client library for Node.js.

    npm install mqtt
   

5. Create a file called automation.js to contain the automation script. In this example, you can run the script on the Raspberry Pi. However, the file can be placed anywhere and doesn’t even need to run on the same device as the MQTT broker. As long as the program can connect to the MQTT broker over the local network, it will function correctly.

    touch automation.js
   

6. Open the file with your preferred text editor, like Nano shown here.

    nano automation.js
   

7. Paste the following code into the file.

    const mqtt = require('mqtt');
   
    // MQTT broker connection details
    const MQTT_BROKER = 'mqtt://localhost'; // Replace with your broker's address
    const BUTTON_TOPIC = 'zigbee2mqtt/aqara-button'; // Replace with your button's topic
    const PLUG_TOPIC = 'zigbee2mqtt/third-reality'; // Replace with your plug's topic
   
    // Connect to the MQTT broker
    const client = mqtt.connect(MQTT_BROKER);
   
    // Handle connection events
    client.on('connect', () => {
        console.log('Connected to MQTT broker');
        // Subscribe to the button's topic
        client.subscribe(BUTTON_TOPIC, (err) => {
            if (!err) {
                console.log(`Subscribed to topic: ${BUTTON_TOPIC}`);
            } else {
                console.error(`Failed to subscribe to topic: ${BUTTON_TOPIC}`, err);
            }
        });
    });
   
    // Handle incoming messages
    client.on('message', (topic, message) => {
        if (topic === BUTTON_TOPIC) {
            try {
                const payload = JSON.parse(message.toString());
                console.log('Received message:', payload);
                const desiredAction = payload.action;
   
                // Check for possible actions
                if (desiredAction === 'single') {
                    // Send a message to the plug's topic to toggle the switch
                    client.publish(`${PLUG_TOPIC}/set`, JSON.stringify({"state": "TOGGLE"}));
                    console.log('Toggling the switch')
                } else if (desiredAction === 'double') {
                    // Send a message to the plug's topic to turn off the switch
                    client.publish(`${PLUG_TOPIC}/set`, JSON.stringify({ state: 'OFF' }));
                    console.log('Turning off the switch')
                }
            } catch (err) { 
                console.error('Failed to parse message:', err.message);
            }           
   
        }
    });
   
    // Handle errors
    client.on('error', (err) => {
        console.error('MQTT error:', err);
    });
   

   This script connects to the MQTT broker and subscribes to the button’s topic (zigbee2mqtt/aqara-button). When a message is received, it examines the payload. If the action is a single click (single), the script sends a toggle command ({state: "TOGGLE"}) to the plug’s topic (zigbee2mqtt/third-reality/set), toggling the plug’s state. A double action turns the plug off.

   

   Update the MQTT broker connection and topic details at the top of the script as needed to accommodate your own Zigbee devices, and save your changes.

8. Run the script from the terminal prompt.

    node automation.js
   

9. Test the setup by pressing the button. The script should log the button action and send a command to toggle on the smart plug. Check the MQTT broker logs if the light doesn’t turn on.

10. Optional*:* Once the script is working as expected, there are a few more optional steps to make sure the script restarts during reboots. Install a process manager like PM2 from the command line prompt of the Raspberry Pi.

    sudo npm install -g pm2
    

11. Start the script again.

    pm2 start automation.js
    

12. Your app should now be daemonized, running in the background, and kept alive forever. Generate and configure a startup script to keep PM2 and your processes alive at every server restart.

    pm2 startup
    

13. Copy and paste the command exactly as shown in the terminal output, and run the suggested command.

14. Save the process list so PM2 can restore it after a system reboot.

    pm2 save
    

What’s Next?

Now that you’ve created a custom automation, there are more ways to grow your home automation setup.

• Explore more Zigbee devices: Zigbee2MQTT supports a wide range of devices from various manufacturers.

• Add custom behaviors: Use Zigbee2MQTT’s external converters to define unique functionality for both supported and unsupported devices.

• Scale your setup: This flexible, lightweight setup is good for beginners and power users alike, who don’t want to get locked into proprietary smart home platforms or cloud services.

If you found this tutorial helpful, don’t forget to check out my recommended Home Automation hardware and how-to videos on YouTube for more inspiration!

You can watch the video version of this article here:

Introduction

Are you curious about the IoT (Internet of Things?) Have you always wanted to try to make your own robot, smart mirror, or bird feeder camera? What about building a computer for a fraction of the cost of a commercially available machine?

If you said yes to any of these questions, you might enjoy playing around with a Raspberry Pi.

In this article, I'll explain what a Raspberry Pi is (and what it’s not.) Then I'll show you some things you can use it for, and finally, I'll list all of the current models along with their specs.

What is Raspberry Pi?

A Raspberry Pi is a single board computer (SBC) created in the United Kingdom by the Raspberry Pi Foundation. It's a charity that "works to put the power of computing and digital making into the hands of people all over the world."

The first model of the Raspberry Pi was released in 2012, and as of 2021 there have been five generations of the boards. A microcontroller (more about that later), called the Pico was released in early 2021.

GPIO Pins

Something that sets the Pi apart from your average computer is the set of 40 GPIO (General Purpose Input Output) pins.

GPIO pins are pretty much exactly what they sound like. They are designed to input and output single bits. This means that you can use them to add all sorts of functionality to your Raspberry Pi using switches, buzzers, lights, sensors, and so on.

Raspberry Pi HATs

There are a number of add-on boards that you can attach to the Raspberry Pi using the GPIO pins.

Raspberry Pi HATs (Hardware Attached on Top) are add-on boards designed according to certain specifications. The Raspberry Pi can automatically detect and configure the HATs, making set-up easy.

There is a huge variety of HATs and other add-on boards that you can buy, but here are some notable ones:

• PoE+ HAT – Power over Ethernet HAT
• Sense HAT – Designed for the Astro Pi mission, the Sense HAT includes a gyroscope, an accelerometer, a magnetometer, and sensors for temperature, humidity, and Barometric pressure.
• Pimoroni Explorer HAT Pro – All-purpose board featuring touch pads, crocodile clip pads, and analog inputs
• Adafruit Capacitive Touch HAT – Similar to a Makey Makey, this HAT allows you to use any conductive object to trigger events using Python.

Raspberry Pi Operating Systems

The Raspberry Pi often runs some form of Linux, but there are a ton of operating systems that you can use.

On the official website, you will find a list of operating system images available for download. These include the official Raspberry Pi OS, Debian Buster, and Ubuntu (desktop, core, and server.)

You will also find RetroPie, a specialized gaming platform operating system, and LibreELEC, a lightweight Linux distribution specifically created for use with the open source media player Kodi.

Raspberry Pi VS Arduino

You may have heard of Arduino boards and wondered what the difference is between them and the Raspberry Pi.

The main difference is that Pis (with the exception of the Pico and the RP2040) are full computers with operating systems. You can connect your Pi to a keyboard, mouse, and monitor and use it like you would use a Mac or PC.

The Arduino, on the other hand, is a microcontroller. It cannot function independently as a computer, but is programmed using a computer and then used to control things like cameras, lights, robots, and so on.

As the official Arduino website puts it: “Arduino boards are able to read inputs… and turn it into an output.”

What is the Raspberry Pi Used For?

Search the internet and you will find a huge array of projects created using Raspberry Pis.

Common use cases include home automation, gaming consoles, servers, WiFi extenders, streaming devices, weather stations, and home computers. (Fun fact: much of this article was written on a Raspberry Pi.)

During the Covid-19 pandemic, Raspberry Pi's were even used to control ventilators in some hard-hit areas.

Raspberry Pi Models

All models of Raspberry Pi that are currently in production have 40 GPIO pins.

This list does not include the Raspberry Pi microcontrollers, the Pico and the RP2040.

You can find out where to purchase any of these boards on the Raspberry Pi website.

Conclusion

The Raspberry Pi is an affordable way to explore electronics, hardware, and computer programming. It can be used for a huge variety of projects, from the very silly (like a hamster powered hamster drawing machine) to the very important (like computer labs in developing nations.)

Now that you know the basics, why don't you go out and make something? Whether you hook a Capacitive Touch HAT up to your Raspberry Pi and turn it into a banana piano or install Linux on it and use it to do your homework, I hope you have a great time creating something cool and useful.

One thing that’s always tripped me up as an IoT developer is figuring out the best way to transmit data. There are many different kinds of radios and mediums. On top of that, there are different protocols to boot.

As of this writing, there is one protocol that has reigned supreme in the IoT world:

MQTT.

Unlike an HTTP server, a device can connect, publish, and subscribe to topics. These topics then get sent to a broker and distributed to other subscribed devices. It also happens that MQTT on Nordic’s nRF9160 is well supported.

In this post, I’ll show you how to connect the nRF9160 Feather to a self-hosted Mosquitto instance. You’ll learn how to generate your own certificates, and get a hang of how to test your connections.

Ready to play? Let’s get to it.

Where to host?

If you want to host Mosquitto, you’ll need a server. Since Mosquitto is written in C it’s lightweight and can go almost anywhere. Plus it sips resources so you can install it on a budget VPS without much worry. That’s where a VPS provider like Digital Ocean or Vultr comes in.

To set up a new server here are some steps:

• Login to Digital Ocean. If you don’t have Digital Ocean and would like to support click here to create an account.
• Create a new Droplet

• Choose the FreeBSD 12.1 with UFS.

• Choose the $5 instance. That’s usually more than enough.

• Make sure you import your public key. Otherwise, you won’t be able to immediately use password-less login.

• Hit that green Create Droplet button, and let’s get this show on the road.

Important Extra step

For the certs to work with Mosquitto, you’ll have to set a domain to point to your VPS IP address. A CNAME or A record works. If you’re unsure how to do that, here’s a good guide. Note which (sub)domain you’ve used. We’ll need it in a bit…

Install Mosquitto

I run my servers inside of a FreeBSD jail using Bastille. In this tutorial, we’ll be skipping the jail part and focusing on getting the nRF9160 Feather working.

• You should be set with a Digital Ocean instance (or similar) using FreeBSD. If you haven't done that yet, head back up to the Where to host? section.
• Next, to install mosquitto on your droplet, run pkg install mosquitto. If you’re running something other than FreeBSD, this command may differ. apt-get install mosquitto works on Debian-based systems. If you want the most up to date repositories, make sure you run sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa beforehand. Here’s what the full output on FreeBSD looks like:

$ pkg install mosquitto
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/quarterly, please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
[mosquitto] Installing pkg-1.14.6...
[mosquitto] Extracting pkg-1.14.6: 100%
Updating FreeBSD repository catalogue...
[mosquitto] Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
[mosquitto] Fetching packagesite.txz: 100%    6 MiB   6.6MB/s    00:01
Processing entries: 100%
FreeBSD repository update completed. 31943 packages processed.
All repositories are up to date.
Updating database digests format: 100%
The following 4 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        c-ares: 1.16.1
        ca_root_nss: 3.55
        e2fsprogs-libuuid: 1.45.6
        mosquitto: 1.6.7

Number of packages to be installed: 4

The process will require 2 MiB more space.
682 KiB to be downloaded.

Proceed with this action? [y/N]: y
[mosquitto] [1/4] Fetching mosquitto-1.6.7.txz: 100%  226 KiB 231.1kB/s    00:01
[mosquitto] [2/4] Fetching ca_root_nss-3.55.txz: 100%  285 KiB 291.5kB/s    00:01
[mosquitto] [3/4] Fetching e2fsprogs-libuuid-1.45.6.txz: 100%   34 KiB  34.7kB/s    00:01
[mosquitto] [4/4] Fetching c-ares-1.16.1.txz: 100%  138 KiB 140.9kB/s    00:01
Checking integrity... done (0 conflicting)
[mosquitto] [1/4] Installing ca_root_nss-3.55...
[mosquitto] [1/4] Extracting ca_root_nss-3.55: 100%
[mosquitto] [2/4] Installing e2fsprogs-libuuid-1.45.6...
[mosquitto] [2/4] Extracting e2fsprogs-libuuid-1.45.6: 100%
[mosquitto] [3/4] Installing c-ares-1.16.1...
[mosquitto] [3/4] Extracting c-ares-1.16.1: 100%
[mosquitto] [4/4] Installing mosquitto-1.6.7...
===> Creating users
Using existing user 'nobody'.
[mosquitto] [4/4] Extracting mosquitto-1.6.7: 100%
=====
Message from ca_root_nss-3.55:

--
FreeBSD does not, and can not warrant that the certification authorities
whose certificates are included in this package have in any way been
audited for trustworthiness or RFC 3647 compliance.

Assessment and verification of trust is the complete responsibility of the
system administrator.

This package installs symlinks to support root certificates discovery by
default for software that uses OpenSSL.

This enables SSL Certificate Verification by client software without manual
intervention.

If you prefer to do this manually, replace the following symlinks with
either an empty file or your site-local certificate bundle.

  * /etc/ssl/cert.pem
  * /usr/local/etc/ssl/cert.pem
  * /usr/local/openssl/cert.pem
=====
Message from mosquitto-1.6.7:

--
The mosquitto MQTT Python driver is now provided by net/py-paho-mqtt

All installed package configuration lives at /usr/local/etc/mosquitto/. We’ll need to edit mosquitto.conf in that folder to use certificates. Here’s what it looks like:

# Daemon configuration
pid_file /var/run/mosquitto.pid
user nobody

# Port to use for the default listener.
port 8885

# At least one of cafile or capath must be defined.
cafile /root/pki/ca.crt

# Path to the PEM encoded server certificate.
certfile /root/pki/issued/mosquitto.crt

# Path to the PEM encoded keyfile.
keyfile /root/pki/private/mosquitto.key

# Path to CRL file
#crlfile /root/pki/crl.pem

# Each client has their own cert
require_certificate true
use_identity_as_username true

# listener port-number [ip address/host name]
listener 1883
protocol mqtt

# listener port-number [ip address/host name]
# listener 8080
# protocol websockets

# =================================================================
# Logging
# =================================================================
log_dest syslog

# Types of messages to log.
log_type all
#log_type warning
# websockets_log_level 127

# -----------------------------------------------------------------
# Default authentication and topic access control
# -----------------------------------------------------------------
# password_file /usr/local/etc/mosquitto/pwfile

Before we can start the server we’ll need to provision some RSA certificates. We’ll get to that in the next step.

Provision Certs

You can use easy-rsa to generate a CA server and client certs. (These instructions come from this guide.) For production, you should generate your keys and certs on an offline machine. That way your private keys are safe if your server becomes a target.

First, install easy-rsa:

$ pkg install easy-rsa
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        easy-rsa: 3.0.7

Number of packages to be installed: 1

44 KiB to be downloaded.

Proceed with this action? [y/N]: y
[mosquitto] [1/1] Fetching easy-rsa-3.0.7.txz: 100%   44 KiB  44.8kB/s    00:01
Checking integrity... done (0 conflicting)
[mosquitto] [1/1] Installing easy-rsa-3.0.7...
[mosquitto] [1/1] Extracting easy-rsa-3.0.7: 100%

Then let's begin the cert creation process:

$ easyrsa init-pki

Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars

init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /root/pki
$
$ easyrsa build-ca

Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars
Using SSL: openssl OpenSSL 1.1.1d-freebsd  10 Sep 2019

Enter New CA Key Passphrase:
Re-Enter New CA Key Passphrase:
Generating RSA private key, 2048 bit long modulus (2 primes)
......................+++++
..................................................................................+++++
e is 65537 (0x010001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:testserver.jaredwolff.com

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/root/pki/ca.crt

Note: You will be prompted for a password at the build-ca step. Make sure you keep this password handy.

Then to generate a server cert use:

$ easyrsa gen-req mosquitto nopass

Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars
Using SSL: openssl OpenSSL 1.1.1d-freebsd  10 Sep 2019
Generating a RSA private key
...............+++++
........................................+++++
writing new private key to '/root/pki/easy-rsa-82720.X2NVQ0/tmp.akOxhO'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [mosquitto]:testserver.jaredwolff.com

Keypair and certificate request completed. Your files are:
req: /root/pki/reqs/mosquitto.req
key: /root/pki/private/mosquitto.key
$
$ easyrsa sign-req server mosquitto

Note: using Easy-RSA configuration from: /usr/local/share/easy-rsa/vars
Using SSL: openssl OpenSSL 1.1.1d-freebsd  10 Sep 2019

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 825 days:

subject=
    commonName                = testserver.jaredwolff.com

Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes
Using configuration from /root/pki/easy-rsa-82744.hyuGzt/tmp.lZHLEH
Enter pass phrase for /root/pki/private/ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'testserver.jaredwolff.com'
Certificate is to be certified until Nov  3 01:12:53 2022 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /root/pki/issued/mosquitto.crt

You’ll be prompted for both the Common Name (i.e. your server name) and the CA cert password in the above step. Important: the Common Name needs to match the domain name of your server! (Remember, we wrote that down earlier?)

To generate the nRF9160 cert, use:

$ easyrsa gen-req nrf9160 nopass batch
$ easyrsa sign-req client nrf9160 batch

Follow the same procedure as earlier. The only difference is that we’re generating a client cert instead of a server cert.

Once complete, we’ll need some files. Here’s a full list:

For your Mosquitto Server

• /root/pki/ca.crt
• /root/pki/private/mosquitto.key
• /root/pki/issued/mosquitto.crt

For your nRF9160 Feather

• /root/pki/ca.crt
• /root/pki/private/nrf9160.key
• /root/pki/issued/nrf9160.crt

If you’re using the configuration from above, it’s already pointing to your server certificates. All we have to do now is start mosquitto!

$ service mosquitto start
Cannot 'start' mosquitto. Set mosquitto_enable to YES in /etc/rc.conf or use 'onestart' instead of 'start'.

If you get an error about mosquitto_enable simply run:

$ sysrc mosquitto_enable=YES
$ service mosquitto start
Starting mosquitto.

This enables mosquitto to start when your system starts.

Now, check if mosquitto is running by using ps aux:

$ ps aux
USER     PID %CPU %MEM   VSZ  RSS TT  STAT STARTED    TIME COMMAND
root   82401  0.0  0.2 11472 2424  -  SsJ  01:02   0:00.00 /usr/sbin/syslogd -ss
root   82457  0.0  0.2 11408 2284  -  IsJ  01:02   0:00.00 /usr/sbin/cron -J 60 -s
nobody 82900  0.0  0.6 16352 6212  -  SsJ  01:17   0:00.02 /usr/local/sbin/mosquitto -c /usr/local/etc/mosquitto/mosquitto.conf -d
root   82488  0.0  0.3 12096 2848  0  IJ   01:02   0:00.01 login [pam] (login)
root   82489  0.0  0.3 13092 3504  0  SJ   01:02   0:00.03 -csh (csh)
root   82902  0.0  0.3 11704 2540  0  R+J  01:17   0:00.00 ps aux

Now that we have a server loaded and running, let’s get the firmware working.

Firmware bits

Dealing with certificates on the nRF9160 Feather is a two-step process. The first step is to load the certificates using the at_client firmware. The second is to load the mqtt_simple library with added TLS support. Let’s tackle the certs first.

Program at_client first

Change directories to ncs/nrf/samples/nrf9160/at_client/ and start a fresh build:

$ west build -b circuitdojo_feather_nrf9160ns -p

Then flash to your board using:

$ west flash --erase
$ nrfjprog -r

We’ll need this sample on your board for the next step.

Add certs to device

To install our new certs, we’ll need nRF Connect Desktop installed. You can download it by going here.

You’ll also need a custom version of LTE Link Monitor. You can get the modified version on docs.jaredwolff.com.

First, Install nRF Connect Desktop app. Then, copy the LTE Link Monitor .tgz file to %USERPROFILE%\.nrfconnect-apps\local (on Windows) or $HOME/.nrfconnect-apps/local (on Linux/macOS). Here’s an example of where it is on Windows:

Close and re-open nRF Connect Desktop (if it’s open).

Then, click Open next to the v1.1.1 version of LTE Link Monitor. It will also have local written underneath it.

Next, let’s launch it!

Once you’ve opened the port, hit the reset button. Make sure you turn off Automatic requests.

Then in the command box send AT+CFUN=4. This will shut down your modem so it’s ready to upload certs. You can run AT+CFUN? to confirm your modem in that mode.

Open up the Certificate manager.

Make sure you set the security tag. In this case, I’m using 1234. This is an important identifier that you’ll need later. Make it whatever you want but I would avoid using 16842753. This is the default tag for NRF Cloud. You don’t want to blast away your nRF Cloud certs!

Copy and paste the contents of your ca.crt, nrf9160.crt and nrf9160.key into the boxes (in that order). You can easily get the certs by using cat on Unix/Linux:

$ cat cat.crt
-----BEGIN CERTIFICATE-----
MIIDdTCCAl2gAwIBAgIUDLkBxLLQO9wosNDtA7E9qvqHOxMwDQYJKoZIhvcNAQEL
BQAwJDEiMCAGA1UEAwwZdGVzdHNlcnZlci5qYXJlZHdvbGZmLmNvbTAeFw0yMDA3
MzEwMTExNDJaFw0zMDA3MjkwMTExNDJaMCQxIjAgBgNVBAMMGXRlc3RzZXJ2ZXIu
amFyZWR3b2xmZi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3
de1v8k+FXzY/Im7Z2YKS7wwbBRft5CUxqP1sdYJgMvheS9LhFufk81URZ0lHD9pK
aNPxU1UEmnLvVDTGLJ+YAmMH08xn17FS1R1UVPYzi2ouwqRM2pR9EStsSlP9Zj44
1MsdizABnnlkZndUVLL/gjc4cNsNncMLBSEbsz6b5WzhtAGg3rOpdAxSSblZVSFw
bquCgg5hb2NUzy+JxGtUIsE5d6CxTDdSs4Z3FK/RRYjmCG6qsaya4N5W35yf8h5O
StfKRecl3kq2kCnWa6P+lErG4wuxIBtMkgz2zV+zd1tz4aHXxSdoZTqLz7dTVbFA
zEVnKD+ZReBG+4fwUL6rAgMBAAGjgZ4wgZswHQYDVR0OBBYEFIvdGnjrxRPzvXQi
7XJ70LzpZSOjMF8GA1UdIwRYMFaAFIvdGnjrxRPzvXQi7XJ70LzpZSOjoSikJjAk
MSIwIAYDVQQDDBl0ZXN0c2VydmVyLmphcmVkd29sZmYuY29tghQMuQHEstA73Ciw
0O0DsT2q+oc7EzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBBjANBgkqhkiG9w0B
AQsFAAOCAQEAIzz1nSSDkPueNPlADRYMDOMFNkxoKA+gRXwDVa7y39As7IZp7Fqr
KAH79U1XtGyDlt6FPKTvDJ7jtd4y8auIGVQO7z3AG9pVU1imIWZHoIqgBUCEhsjp
uMxD23kRCX5kd9dsmF9WOGGxb4kkMv83Rh2rCONQmvnozuI3fJv2ZFX/ORoADGLP
OPSJPl11x+2rxPxiLi+T8RyzDh3DwqnPVsSnbRWV7hosaN0ip/cbnSTaIul9mbCY
ID6qm9leqlY/gha9aZfg+tv1Lm6PT6o8Pzek2VeDoIS5YERBMOwV84hQrZjV3vIE
jT6y663HGsl7KvqVaWdV3fM6Cr7f0QdR5A==
-----END CERTIFICATE-----

You’ll need everything from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----

Check the Log area for more details. If all went well, it should say that your certificates updated.

Using the mqtt_simple example

We’ll be using the mqtt_simple sample within the nRF Connect SDK repository. The full path is: ncs/nrf/samples/nrf9160/mqtt_simple. We’ll need to make a few edits to add full TLS compatibility. All the files are within the mqtt_simple directory.

First, we’ll have to update the proj.conf file. See the highlighted differences:

The # Set the PDP Context section is especially important if you’re using a Hologram SIM card (included with the nRF9160 Feather). If you are using a SIM that doesn’t need it, you do not need this section.

Adopt your CONFIG_MQTT_BROKER_HOSTNAME to your hostname (configured at the beginning of this guide).

You’ll also have to add these lines in KConfig:

config SEC_TAG
    int "Security tag to use for the connection"
    default 1234

config PEER_VERIFY
    int "Peer verify parameter for mqtt_client"
    default 1
    help
            Set to 0 for VERIFY_NONE, 1 for VERIFY_OPTIONAL, and 2 for VERIFY_REQUIRED.

Finally in main add this block to the top of your file:

#if defined(CONFIG_MQTT_LIB_TLS)
static sec_tag_t sec_tag_list[] = { CONFIG_SEC_TAG };
#endif /* defined(CONFIG_MQTT_LIB_TLS) */

Then add this block to client_init under #if defined(CONFIG_MQTT_LIB_TLS)

  struct mqtt_sec_config *tls_config = &client->transport.tls.config;

    client->transport.type = MQTT_TRANSPORT_SECURE;

    tls_config->peer_verify = CONFIG_PEER_VERIFY;
    tls_config->cipher_count = 0;
    tls_config->cipher_list = NULL;
    tls_config->sec_tag_count = ARRAY_SIZE(sec_tag_list);
    tls_config->sec_tag_list = sec_tag_list;
    tls_config->hostname = CONFIG_MQTT_BROKER_HOSTNAME;

The changes should look like this:

Then build with:

$ west build -b circuitdojo_feather_nrf9160ns -p

Finally, flash it using west flash:

$ west flash --erase
$ nrfjprog -r

Open your serial terminal and double check that your nRF9160 Feather is connecting. You can also use LTE Link Monitor to view your progress as well (Example below).

Lots of the information above came from Nordic's post on the subject.

Sending a message

We’re almost there! You’ve configured your nRF9160 Feather to connect to Mosquitto using self-generated certificates. The last part is connecting another device to see if the nRF9160 Feather replies to a message.

I’ve created a new set of certs for this purpose. I called them test.

$ easyrsa gen-req test nopass batch
$ easyrsa sign-req client test batch

I copied them to my desktop using CyberDuck (a great little visual SFTP client):

You can also use something like scp if you're confident in your command line file transfer abilities. Then, open a terminal and run:

mosquitto_sub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/publish/topic" &
mosquitto_pub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/subscribe/topic" -m "hello there"

You should see an output like this:

$ mosquitto_sub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/publish/topic" &
$ mosquitto_pub --cafile ca.crt --cert test.crt --key test.key -q 1 -d -h testserver.jaredwolff.com -p 8885 -t "/my/subscribe/topic" -m "hello there"
Client mosq-CczskQKzMKdtTo4O4s sending CONNECT
Client mosq-CczskQKzMKdtTo4O4s received CONNACK (0)
Client mosq-CczskQKzMKdtTo4O4s sending PUBLISH (d0, q1, r0, m1, '/my/subscribe/topic', ... (11 bytes))
Client mosq-CczskQKzMKdtTo4O4s received PUBACK (Mid: 1, RC:0)
Client mosq-CczskQKzMKdtTo4O4s sending DISCONNECT
MacBook-Pro:Downloads jaredwolff$ Client mosq-qK8tMlJk0Qri4Z7jUo sending PINGREQ
Client mosq-qK8tMlJk0Qri4Z7jUo received PINGRESP
MacBook-Pro:Downloads jaredwolff$ Client mosq-qK8tMlJk0Qri4Z7jUo received PUBLISH (d0, q0, r0, m0, '/my/publish/topic', ... (11 bytes))
hello there

Booyah! You have an active working connection to your very own Mosquitto server.

Conclusion

We’ve made it to the end! By this point in the post, you should have a Mosquitto server running and an nRF9160 connected. Now you can use your new-found skills to add more devices to your deployments and more.

If you haven’t had a chance to play with the nRF9160 you should check out the nRF9160 Feather. It has Nordic Semiconductor’s nRF9160 LTE-M, NB IoT + GPS Combo, plus flexible power supply, external flash, and low power shutdown.

Oh, and did I mention it’s 100% open source? Learn more by checking out the campaign on GroupGets and Hackster Launch. ?

Photo credit to the awesome folks at GroupGets!

You can read this article and lots of other good stuff at jaredwolff.com.

This post is a bit lengthy. If you prefer, signup to get the full PDF here. ?

After Particle's Mesh deprecation announcement, many have been left to figure out how to deploy their low power sensor networks. There was always the option of using Particle's Built in Bluetooth stack but as it stands today it's not secure.

Previously I had helped form a very simple nRF SDK-based hub and spoke IoT deployment. Unfortunately, it was closed source and the company is no longer around.

So what's a guy to do?

Build another one and make it open. (BSD licensed to be exact!) Open and free for anyone to use adopt and improve upon. Plus if you're building a product that's using the code, you don't have to share your improvements or proprietary code with anyone.

In this post I'll be talking about how to get started with Pyrinas. It uses Nordic's time tested SDK as a basis for the kernel of the system. The main concept of Pyrinas is to abstract as much IoT cruft away so you can focus on your application.

So without further ado, let's chat about what Pyrinas is and what it isn't.

What Pyrinas is

• Is an embedded "kernel", written in C. It's open and permissive IoT development environment you can use for anything you want. Seriously. It's BSD licensed and can be used in closed source applications.
• Using the power of Bluetooth 5.0 Long Range, Pyrinas allows you to communicate with many peripheral devices at one time. Currently Pyrinas has been tested with 3 simultaneous peripheral connections. Theoretically, it can support up to 20 simultaneous connections. (Thanks to Nordic's S140 Softdevice)

• Pyrinas transports its data in two ways

  • In a familiar string format used by Particle
  • A custom Protocol Buffer for raw data transmission.

  That way you have a choice of how you want to process and publish your data!

What Pyrinas isn't

• Pyrinas is not a RTOS (real time operating system). If you have a need to run multiple threaded applications on embedded, Pyrinas is not for you.
• Pyrinas, at this time, does not support Mesh.
• An OS for every single kind of Bluetooth SoC on the market. Due to the tight coupling with Nordic's nRF SDK, Pyrinas only works with Nordic's SoCs.
• A turnkey solution for IoT. Pyrinas is early on it it's development process. The aim is for it to become a viable option for anyone to develop and publish IoT applications the way they want to. There's no vendor lock in. There's no surprises.

Things you'll need

There are a few things you'll need in order to get going with Pyrinas.

• At least 2 Particle Xenons
• At least 1 nRF Development board or J-link programmer
• Associated USB cables

Getting started with an example

Getting started with Pyrinas involves two repositories.

• The OS respository
• The template

The OS directory has all the source, SDK dependencies and toolchain you need to use Pyrinas.

The template is where you add all your application code. The template provides a starting point for you and your project.

Here's how everything goes together:

Clone the OS directory to some place on your machine:

git clone https://github.com/pyrinas-iot/pyrinas-os.git --recurse-submodules

Once complete, change directories to pyrinas-os and run make setup

cd pyrinas-os
make setup

This will download your toolchain and SDK dependencies.

In order to use OTA DFU, you will need to also generate the DFU key for the process:

make gen_key

The files generated by this process will be used later.

Next, we'll want to use the template to make two new projects. In this example we'll have one "hub" and one "sensor." Simply navigate to the template repository and click the Use this template button.

Then name your new repository. Click the Create repository from template button when you're happy with everything.

Then clone your repository to the same directory as pyrinas-os. Make sure you replace <your username> and <repo name> with your own.

cd ..
git clone https://github.com/<your username>/<repo name>.git hub

After this is done, go back and create a new repository from the template. We'll be using this one for the sensor node.

Clone this repository once you're done setting it up in the same place as your hub and pyrinas-os repositories.

Now that we have all our repositories, let's start with our sensor node.

Setting up the sensor node repository

Open up the sensor repository using a program like Microsoft's VS Code. If you have the command line shortcuts you can use code to open it from the terminal:

code sensor

Before we do anything we'll need to set up the symbolic link to pyrinas-os. Make sure you're in the sensor directory and then run ln -s ../pyrinas-os/ using the terminal.

cd sensor
ln -s ../pyrinas-os/ .

This allows your project to use all the code, SDK and toolchains within the pyrinas-os repository! As an added bonus you can do this as many times as you want. Have multiple Pyrinas projects? No problem.

Alright! Now, let's check out the Makefile. You'll want to customize some of the definitions within the file:

# Start: Your configuration!

# Set this to the directory of pyrinas-os
# If you used a symbolic link this points to
# the `pyrinas-os` folder in this repository
OS_DIR := pyrinas-os

# This should be the serial number of your Jlink programmer.
# To find simply run `jlinkexe`
PROG_SERIAL=1234678

# This is your debugger port for Jlink's RTT. If you
# have mulitple, you will have to change this on each app
# your're using
PROG_PORT=19021

# This is where you set your board type. Here are the supported boards:
# xenon - Particle Xenon
BOARD=xenon

# This is where you can name your app something. Make it specific
APP_FILENAME=pyrinas-template

# This determines whether or not you're using debug mode
# Comment this out or change to false
DEBUG=true

# End: Your Configuration

For example, you may want to setup your programmer serial. This allows you to use multiple programmers at the same time. (Very helpful in debugging both devices at the same time) To get your programmer's serial plug in your development board and run jlinkexe.

jlinkexe SEGGER J-Link Commander V6.62a (Compiled Jan 31 2020 12:59:22) DLL version V6.62a, compiled Jan 31 2020 12:59:05

Connecting to J-Link via USB...O.K. Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 21 2020 17:30:48 Hardware version: V1.00 S/N: 581758669 License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.300V

Type "connect" to establish a target connection, '?' for help J-Link>

Find the S/N area. This is your serial number!

Alternatively you can look at the sticker on your development kit. It will contain the serial number for your device.

For the PROG_PORT you want to use different ports for each device you're simultaneously debugging. I've found 19021 and 19020 are perfectly good options for most two-device debugging sessions.

The Makefile also includes the ability to choose a board. In our case there's only one option: xenon. Future revisions of Pyrinas will have multiple options.

APP_FILENAME is the name of your app. We'll rename ours to pyrinas-sensor

Finally, DEBUG is used to halt execution either on an error or restart. For production this should be commented out or set to false. We can leave it as is for now.

The Makefile is also the source for some of the most important commands you'll need during development:

• make build - builds your app.
• make clean - cleans all remnants of your app.
• make debug - opens up the jlinkexe debugger console.
• make erase - erases the chip attached to your programmer.
• make flash - flashes the current app to your connected device.
• make flash_softdevice - flashes the soft_device
• make rtt - opens up the debug console.
• make ota - generates a zip file used for BLE DFU

Basic sensor node code

Now that we have some of the basics out of the way, let's create a very simple application that publishes on a set interval. If you look at app.c, you'll see some code in the setup() function. Let's delete all the commented out code. (We'll use it later for the hub though)

Your code should now look something like:

#include "app.h"

void setup()
{
  BLE_STACK_PERIPH_DEF(init);

  // Configuration for ble stack
  ble_stack_init(&init);

  // Start advertising
  advertising_start();
}

void loop()
{
}

Now let's create a timer that we'll use to publish on a set interval. Under #include "app.h" create a new timer:

#include "app.h"

timer_define(m_sensor_timer);

We also need to set it up in the setup() function:

// Sensor timer
timer_create(&m_sensor_timer, TIMER_REPEATED, sensor_timer_evt);

You'll notice that timer_create is referring to a event callback called sensor_timer_evt. We'll need to create that guy as well:

static void sensor_timer_evt() {
    // We'll come back in a sec
}

The last thing is to start the timer. Let's do that underneath timer_create:

// Start
timer_start(&m_sensor_timer, 1000);

This will start our repeating timer on a 1 second interval. (timer_start is configured using milliseconds)

Now, inside sensor_timer_evt we'll publish some data. First though we need to make sure that Bluetooth is connected using ble_is_connected.

static void sensor_timer_evt
{
  // Check if we're connected
  if (ble_is_connected())
  {
    // Sends "ping" with the event name of "data"
    ble_publish("data", "ping");
  }
}

Inside the if statement, we'll use ble_publish. The first argument is the name of the event and the second is the value.

Next, in order to receive messages from the other end we'll need to setup a callback:

// Configuration for ble stack
ble_stack_init(&init);

// Setup BLE callback
ble_subscribe("data", ble_evt);

We'll define ble_evt at the top of the file:

static void ble_evt(char *name, char *data)
{
  NRF_LOG_INFO("%s: %s", name, data);
}

In this case we'll use NRF_LOG_INFO to print out the message from the hub.

Finally, in order to get the MAC address easily, we'll have to add a call to print it out in setup().

// Print the address
util_print_device_address();

In the end your file should look something like this:

#include "app.h"

timer_define(m_sensor_timer);

// Catch events sent over Bluetooth
static void ble_evt(char *name, char *data)
{
  NRF_LOG_INFO("%s: %s", name, data);
}

static void sensor_timer_evt()
{
  // Check if we're connected
  if (ble_is_connected())
  {
    // Sends "ping" with the event name of "data"
    ble_publish("data", "ping");
  }
}

void setup()
{
  BLE_STACK_PERIPH_DEF(init);

  // Configuration for ble stack
  ble_stack_init(&init);

  // Setup BLE callback
  ble_subscribe("data", ble_evt);

  // Start advertising
  advertising_start();

  // Sensor sensor timer.
  timer_create(&m_sensor_timer, TIMER_REPEATED, sensor_timer_evt);

  // Start
  timer_start(&m_sensor_timer, 1000);

  // Print the address
  util_print_device_address();
}

void loop()
{
}

Next, we'll program it to some hardware!

Flashing the basic sensor code:

For this step you'll need to have a Xenon handy. You'll also need a programmer, programming cable and two Micro-B USB cables. Here's a picture of everything connected:

Once connected and powered run these commands:

make erase
make flash_softdevice
make flash
make debug

Then in a separate terminal window run

make rtt

make debug and make rtt will create a debugging session. You can issue commands in the make debug terminal to control the device as well. For instance, r followed by Enter will restart the device. (By far my most common use case).

If you've flashed everything successfully, your device should start blinking green. That's a good sign!

Additionally, if you take a look at the make rtt side your output should be similar to this:

###RTT Client: Connecting to J-Link RTT Server via localhost:19021 ...

###RTT Client: Connected.

SEGGER J-Link V6.62a - Real time terminal output J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 21 2020 17:30:48 V1.0, SN=581758669 Process: JLinkExe app_timer: RTC: initialized. app: Boot count: 4 app: Pyrinas started. app: Address: 11:22:33:44:55:66

Take note of the address displayed above. We'll need that for the hub code!

Setting up the hub repository

If you haven't already, clone your hub repository locally. We'll want to do some of the same steps as we did with the sensor repo like:

• Setting up the symbolic link
• Updating the Makefile
  • Setting your PROG_SERIAL
  • Setting PROG_PORT to a port not used by the sensor setup. 19020 in this case is fine.
  • Setting APP_FILENAME to pyrinas-hub

If you need a reminder how any of these steps work, go back and review the earlier section.

Next, we'll want to open app.c and uncomment the central/hub based code. Plus you'll want to remove the default un-commented code. Your setup() should look something like this:

void setup()
{
  // Default config for central mode
  BLE_STACK_CENTRAL_DEF(init);

  // Add an addresses to scan for
  ble_gap_addr_t first = {
      .addr_type = BLE_GAP_ADDR_TYPE_RANDOM_STATIC,
      .addr = {0x81, 0x64, 0x4C, 0xAD, 0x7D, 0xC0}};
  init.config.devices[0] = first;

  ble_gap_addr_t second = {
      .addr_type = BLE_GAP_ADDR_TYPE_RANDOM_STATIC,
      .addr = {0x7c, 0x84, 0x9d, 0x32, 0x8d, 0xe4}};
  init.config.devices[1] = second;

  // Increment the device_count
  init.config.device_count = 2;

  // Configuration for ble stack
  ble_stack_init(&init);

  // Start scanning.
  scan_start();
}

You'll notice immediately that there are two clients/devices defined here. Let's remove the second one. Should you, in the future, want to connect more devices this is an example of how to do it.

Reminder: also make sure that you change the init.config.device_count to 1.

Then, you'll want to update the .addr field in ble_gap_addr_t first to match the address we got earlier from make rtt:

// Add an addresses to scan for
ble_gap_addr_t first = {
    .addr_type = BLE_GAP_ADDR_TYPE_RANDOM_STATIC,
    .addr = {0x11,0x22,0x33,0x44,0x55,0x66}};
init.config.devices[0] = first;

The address field uses raw bytes, so it has to be represented that way. Remove the : and place 0x in front of each byte. We end up going from 11:22:33:44:55:66 to {0x11,0x22,0x33,0x44,0x55,0x66}

Now before we flash anything, let's also set up the Bluetooth event handler. As with earlier we'll use ble_subscribe to attach an event handler:

// Setup BLE callback
ble_subscribe("data", ble_evt);

Then place the function at the top of the file:

// Catch events sent over Bluetooth
static void ble_evt(char *name, char *data)
{
  NRF_LOG_INFO("%s: %s", name, data);

  ble_publish("data", "pong");
}

You'll notice we're printing out the message using NRF_LOG_INFO. We're also sending a message back to the sensor in the form of ble_publish("data","pong"); In other-words we're playing a game of ping-pong between the two devices!

In the end your code should look something like this:

#include "app.h"

// Catch events sent over Bluetooth
static void ble_evt(char *name, char *data)
{
  NRF_LOG_INFO("%s: %s", name, data);

  ble_publish("data", "pong");
}

void setup()
{
  // Default config for central mode
  BLE_STACK_CENTRAL_DEF(init);

  // Add an addresses to scan for
  ble_gap_addr_t first = {
      .addr_type = BLE_GAP_ADDR_TYPE_RANDOM_STATIC,
      .addr = {0x11, 0x22, 0x33, 0x44, 0x55, 0x66}};
  init.config.devices[0] = first;

  // Increment the device_count
  init.config.device_count = 1;

  // Configuration for ble stack
  ble_stack_init(&init);

  // Setup BLE callback
  ble_subscribe("data", ble_evt);

  // Start scanning.
  scan_start();
}

void loop()
{
}

Reminder: make sure you set ble_gap_addr_t first or the two devices will not connect!

To program, connect the Xenon to program as you did before. We'll flash it using the same methods as before:

make erase
make flash_softdevice
make flash
make debug

Then in a separate terminal window run

make rtt

Then take a look at each of the make rtt screens. There should be some output! For the hub it should look something like this:

Process: JLinkExe app: Boot count: 4 app: Pyrinas started. ble_m_central: Connected to handle 0x0 ble_m_central: Protobuf Service discovered app: data: ping app: data: ping

And the sensor side like this:

Process: JLinkExe app_timer: RTC: initialized. app: Boot count: 4 app: Pyrinas started. app: Address: 11:22:33:44:55:66 ble_m_periph: Notifications enabled! app: data: pong app: data: pong

The ping and pong messages should continue until you stop them. Awesome! If you get any warnings like this one:

Unable to write. Notifications not enabled!

Use the reset button on either of the devices. This should fix the problem.

Side note: the pairing process for Bluetooth is inherently insecure. Once the pairing process is complete though, the devices are secure. (With the caveat that no one was sniffing the pairing process!) There may be improvements on security in the future.

Congrats! ?If you've made it this far, you've deployed your first Pyrinas hub and sensor client!

For more information about what Pyrinas can do you should check out the header files under pyrinas-os/include/. Also, Pyrinas can do anything that you'd normally be able to do with Nordic's SDK. Nordic's Infocenter is a great resource for learning more about what the SDK has to offer.

What does the future hold for Pyrinas?

All future tasks for Pyrinas are shared openly on the Github Repo. Here are some of the high level improvements on the roadmap:

• Particle Boron + LTE support - That's right! Cellular will be coming to Pyrinas. As of this writing, the first board to support Pyrinas LTE will be Particle's Boron.
• MQTT (over TLS) and HTTPS support - Once we have cellular, we need something to communicate with. That's where MQTT and HTTPS come in. They're some of the most popular protocols for IoT today.
• Built in remote OTA support - As it stands today, devices programmed with Pyrinas uses Nordic's Secure Bootloader. That means they can be updated over the air by a computer or cellphone nearby. This isn't sustainable for long term deployments though! Instead, you will be able to push updates to Pyrinas devices over the Cloud. Yup. No reason to get off your couch, you can deploy your updates from anywhere.
• Dynamic configuration and management - adding and removing devices from a Pyrinas system currently takes some effort. In future revisions, it will be easier to add and remove devices on the fly. This allows for remote device management with zero headaches.
• Support for pre-certified modules and other development boards based on Nordic's nRF52840. Currently the Xenon is the only supported board. Development boards aren't great for full production though. Stay tuned for support for pre-certified modules from vendors like Fanstel and more..
• Support for more development environments. Currently Pyrinas supports Mac only.

Star and Watch!

This is only the tip of the iceberg! Stay tuned for more updates and make you you star and watch the repository.

Or, better yet, looking to help out? Contributions are welcome!

You can read other articles on my blog, jaredwolff.com

Understand the business opportunity

In 2019, the market revenue of IoT reached $212 billion. There are about 26.66 billion connected IoT devices worldwide, and this number is set to reach 75.44 billion by 2025.

The UN estimates that, in February 2020, the world population is currently 7.7 billion people. Simple math tells us that the average person owns around 3 to 4 IoT devices. Do you have one? Maybe a smartwatch? A smart TV? Or a smart car?

Moving further, the population is expected to reach 8.1 billion people in 2025. The same math calculation shows us that, in 2025, an average person will have from 9 to 10 smart devices in their possession.

Do you see where I am going with this? Do you want to join this lucrative market niche and make your IoT device one of these 9 to 10?

Statistics retrieved from Statista and the United Nations.

Choose the right framework

The client-side of an IoT device is represented by the hardware itself. It is programmed with C, C++, or Lua – low-level and difficult programming languages. But there is not much you can do about it because of hardware limitations.

Along with high performance, users of IoT devices prioritize low cost and energy-efficiency. Thus, at least for now, you should keep working with low-level languages.

On the other hand, the server side of IoT applications offers you more freedom of choice. Here, you are not limited by the hardware, so you can choose any coding language and framework you prefer.

I believe that the right one is Node.js. Here is why.

Node.js is fast and performant

First of all, any IoT device is constantly working with dynamically changing data. This means that you need a framework which can handle real-time applications and heavy data flows.

Node.js is built on Google’s V8 JS engine, which is highly effective and perfectly scalable. Thanks to this feature, Node.js is the number one framework to be used with real-time apps and platforms. Constantly changing data is not a challenge for it either.

Node.js is easy to integrate with IoT protocols

IoT applications actively use a publish-subscribe-based messaging protocol, MQTT. In turn, for transportation and encapsulation, this protocol uses WebSockets. Both MQTT and WebSockets are well-supported and easily integrated with Node.js.

Node.js modules facilitate IoT development

Node.js is augmented with npm, the Node Package Manager, which features a lot of useful IoT modules. There are about 80 packages for Intel IoT Edison, Arduino, or Raspberry Pi. Also, it features over 30 packages for different sensors, beacons, and other tools.

This is why Internet of Things development is simpler and faster with Node.js IoT modules.

Node.js is resource-efficient and scalable

In general, developers prefer working with Node.js because it does not require a lot of resources. The CPU and RAM are not overloaded.

Also, Node.js is highly scalable, which is absolutely necessary for most modern companies.

Beware of the challenges

Entering the IoT niche can lead you down a path to success. No wonder, then, that there are a lot of challenges and traps awaiting you on your way – success is never easy to achieve. And the first and foremost challenge you should be aware of is security.

Security is one of the top problems in IoT sphere, and one of the first pitfalls you will stumble upon. So what should you do?

Secure authentication

Let’s start with authentication. There are a lot of tools for authentication in Node.js: tokens, JSON web tokens, Auth0, and so on. Each has its advantages and disadvantages. To start, you should look at them from the perspective of IoT.

On the one hand, tokens are effective but not 100 percent safe. They are a cool way to set up authentication as they let you identify a specific user and decide whether to grant or deny them access. A token can be encrypted with any algorithm.

However, the hardware (scanners, sensors, hubs, or other IoT things) should store this token or login/password data in firmware. This means that attackers can steal the token if they have physical access to the hardware. The same story goes for JWT or Auth0.

On the other hand, we can use any tools for authentication on the server side. You can easily integrate any authentication tool on the Node.js platform.

There are a lot of npm packages which allow you to do this manually: Auth0, Passport, and JWT. There are also packages for integration with cloud IoT services: @azure-iot/authentication, aws-iot-device-sdk, and so on.

Secure HTTP requests

Next, be careful with HTTP requests from your IoT devices. You should check if you get a request from a proper IoT device.

Firstly, you should implement HTTPS with your IoT devices. Hardware is not a browser and you should implement HTTPS manually on it. For the server-side, you can either do it manually or use hosting with HTTPS configuration and certificates.

In Node.js, it is quite easy to implement:

const express = require('express');
const https = require('https');
const http = require('http');
const fs = require('fs');
const options = {
  key: fs.readFileSync('path/to/your/key.pem'),
  cert: fs.readFileSync(path/to/your/certificate.cert')
};
const app = express();
http.createServer(app).listen(80);
https.createServer(options, app).listen(443);

HTTPS uses SSL or TLS protocols for data encryption. However, to be sure that you have gotten a request from the necessary server or client, use additional data encryption. For example, this is how you can use a signature:

const fetch = require('node-fetch');
const verifier = crypto.createVerify('RSA-SHA1')
const SIGNATURE_FORMAT = 'base64';
//check if it trusted url for your certificate
const trustedUrl = ‘https://trustedUrl/’
const isTrustedUrl = trustedUrl.match(url);
If (isTrustedUrl) {
verifier.update(req.body, 'utf8')
    fetch(isTrustedUrl)
    .then(certificate => {
    // check signature
const isValidSignature = verifier.verify(certificate, reg.header.signature, SIGNATURE_FORMAT);
   })
    .catch(err => console.log(err));
}

To wrap up this part:

1. First, you have to check the trusted URL of your certificate.
2. Then, you sign a request body with the public key from your certificate.
3. Finally, you compare the signed body with the signature from headers.

It is extremely important to know that you're getting requests from the proper devices and that you're not facing a middle attack.

Check out these examples

Asama – tracking the movement of your employees

Asama is a micro-location system, which uses smartwatches and Bluetooth beacons to track movement and activity of employees. Beacons transmit a regular signal.

According to these signals, the smartwatch defines the location of an employee. The smartwatch also analyzes whether the right person is wearing it and if the employee is sleeping or working.

The data is then transmitted to the mobile app, which is installed and configured on the employer’s phone. The system is powered by Node.js in IoT.

This way, managers can track their employees in real time, find the person they need right away, and optimize the workspace. Also, at the end of the week the employer receives an extensive report on employee activity. All this helps to boost the company's performance and productivity.

This solution might not suit a business with a small office and flexible hours. Yet, it works perfectly for industrial plants, construction sites, factories, warehouses, shopping centers, supermarkets, hotels, security agencies, restaurants, or stores.

It's well-suited anywhere you as an employer need to know if employees are coming too late or leaving too early, being absent at the working place, not working actively throughout the day, or not following routes and schedules.

PREE – finding your belongings

PREE is a system of BLE beacons and mobile software which helps people stop losing their stuff. It is a lifesaver for those who often forget their phone, bag, keys, wallet, or any other valuable belongings.

The user can see the location of their item in real time and share it with trusted contacts. Once the item is out of range, they will get a notification, and so will their friends or family members. It doesn't spam others with notifications when they are not needed – for example, when at home, the user can mute them for a certain area.

This Internet of Things IoT system is built with Node.js, Express, and Mongo on the backend and Ionic with Cordova for the frontend. The combination of these frameworks ensures the best user experience.

Validate your idea

Once you have an idea for an IoT product, start with validating it. You can do this in two ways:

• Hire an idea validation team, who will help you test the viability of your product before you invest in development, or
• Hire a software design and development team, who will launch an extensive product discovery process.

Postscript

I would like to send a huge thank you to Volodya Andrushchak, the IoT guru at KeenEthics, for contributing and basically breathing life into to this article.

If you have enjoyed the article, you should definitely read some more about Node.js: What are the Advantages of Node.JS? or NodeJS vs Python: How to Choose the Best Technology to Develop Your Web App's Back End.

The original article posted on KeenEthics blog can be found here: IoT and Node.JS: How to Catch the Opportunity?

If you're developing any type of IoT product, inevitably you'll need some type of mobile app. While there are easy ways, they're not for production use.

In this tutorial, we'll talk about the basics of Particle app development. You'll learn about some of the many app frameworks you can take advantage of. Plus there's libraries, tricks, and tools along the way to make your life a lot easier.

App Frameworks

Sometimes it's dang near irritating to program multiple applications natively. You see, Swift (or Objective C ?) and Java aren't terrible at first glance (well, maybe except for Obj-C ?). But when you're resource constrained, you have to figure out a new game plan. That's where App Frameworks come in.

These frameworks allow an app developer to write, build and test cross platform apps. In some cases, the frameworks convert your app into native code. That means that they run as fast and as well as one written in Swift or Java.

I did the research and as of January 2020, here are some of the most supported frameworks:

• Framework7
• Flutter
• NativeScript
• ReactNative
• Ionic
• Cordova / PhoneGap
• Meteor
• Xamarin

The list goes on for days.

I've used a few of these frameworks in the past. I've built a Meteor app which (surprisingly) worked. In the end I had to pick one though. What did I go with?

NativeScript.

For the most part, NativeScript's documentation and on-boarding experience is fantastic. Not only can you preview your app inside an emulator but you can load it directly to your phone too!

One of the cool things about NativeScript is that it supports TypeScript. TypeScript is a superset of JavaScript with some extra wiz-bang features.

Unlike other languages, JavaScript technically has no types. If you've done any Particle development you likely know what a type is. We're talking about int, String, float and more. i.e. they're directives to to make sure your JavaScript code stays consistent.

NativeScript is also compatible with most major JavaScript web frameworks. This includes Vue.Js and Angular.

I've only noticed one major drawback thus far: the mobile preview mode (tns preview command) does not pay well with native libraries. If you have some native platform specific libraries, you'll have to use the emulator or a device (if you have one).

If you're gung-ho and you want to build multiple apps in their respective languages, the more power to you. There is an advantage over the above frameworks: tried and true Particle SDKs.

Available Libraries & SDKs

Particle has gone out of their way to make app development a little easier. This is thanks to the massive development work that has gone into their own SDKs. Yup, gone are the days you have to write manual HTTP request handlers.

Here's a link to both the iOS and Android SDKs:

• iOS
• Android

Though we won't be covering them here, they reflect all the potential calls that you can make using the Cloud API.

Speaking of Cloud API, Particle has also developed a Node.js library as well. As you can imagine, you can use this for your server side code or JavaScript based app frameworks. Sadly, it doesn't work with NativeScript. Frameworks that use a WebView should be more compatible.

In the case of this tutorial, we'll be mostly focusing on the Cloud API. This way you have a good understanding of the overall system. It may seem intimidating but if you do it right, you'll get the hang of it real fast.

Making API Calls

In NativeScript you can't use libraries like [request](https://github.com/request/request). (Which happens to be the library Particle's very own DMC used in the CLI — DMC if you're reading this, Hi!) You'll have to use the provided HTTP module.

If you scroll all the way to the bottom of that page, you'll see a fully fledged POST example. I'll reproduce it here but with some Particle specific changes:

// Create form post data
var data = new FormData();
data.append("name", "update");
data.append("data", "It's hammer time!");
data.append("private", "true");
data.append("access_token", _token);

// Configure the httpModule
return httpModule
    .request({
        url: `https://api.particle.io/v1/devices/events`,
        method: "POST",
        content: data
    })
    .then(
        response => {
            const result = response.content.toJSON();
            console.log(result);
        },
        e => {
            if (e) console.log(e);
        }
    );

The above is an example of what's equivalent to Particle.publish in DeviceOS. Let's break down the parts.

First of all, one of the main gotchas of Particle's Web API is the data format. I first expected that they use JSON but I was sorely wrong. After actually reading the documentation I realized that most POST requests were actually application/x-www-form-urlencoded. That means when you submit data, it's the equivalent to hitting the submit button on an HTML form.

Fortunately, there is an easy way to assemble form data in Node/JavaScript. We can use the FormData() object. Take a look at the above. There should be some familiar parameter names in the data.append calls.

"name" refers to the name of the event you're publishing to.

"data" refers to the string formatted data that you're publishing.

"private" dictates whether or not you want to broadcast this data to the whole Particle world, or just your little corner of it.

"access_token" is a token that you can generate in order to make these API calls. Without a token though, you're dead in the water.

Getting a Token

Where do we get this elusive access_token?

At first I had no idea.

I created an OAuth user and secret in the console. That lead to a dead end. Fiddled around with different API calls and settings. Nothing. Then it hit me like a ton of bricks. There's an access_token attached to the curl request on every device page!

Open up any device, click the little console button near Events. A popup with instructions an a URL will pop up. Copy the text after access_token=. That is your access_token! See below:

You can use this token to make calls to the Particle API. This can be to subscribe, publish, write to a function, read variables and more.

Through the command line

That's nice and everything but how the heck can you programmatically generate one? One way is with the command line.

particle token create is the name of the command you need to know about. When you run it, you'll be prompted to login. (Also enter your Authenticator code if you use one.) Then the command line will spit out a shiny new access_token you can use with the API!

Through the API itself

If you couldn't guess, particle token create is a frontend to a raw API call. You can make these API calls directly too. Here's what it looks like in NativeScript.

// Create form post data
var data = new FormData();
data.append("username", "jaredwolff");
data.append("password", "this is not my password");
data.append("grant_type", "password");
data.append("client_name", "user");
data.append("client_secret", "client_secret_here");

// Configure the httpModule
return httpModule
    .request({
        url: `https://api.particle.io/v1/oauth/token`,
        method: "POST",
        content: data
    })
    .then(
        response => {
            const result = response.content.toJSON();
            console.log(result);
        },
        e => {
            if (e) console.log(e);
        }
    );

This call may get more complicated. Mostly in the case if you have two factor authorization setup. It's well worth it when you figure it all out. After all, no one wants to manually create auth tokens if they don't have to!

Now you're ready to write and read from your devices. There's one thing though that may trip you up. Subscribing to events can be troublesome with a regular HTTP client. So much so that if you try to do it with NativeScript's HTTP client, it will lock up and never return. Luckily there is a way to handle these special HTTP calls.

Server Sent What?

Server Sent Events (SSE for short) is an HTTP/S subscription functionality. It allows you to connect to a SSE end point and continuously listen for updates. It's a similar web technology to what companies use for push notifications. It does require some extra functionality under the hood though...

SSE Library

After much head scratching and searching I stumbled upon nativescript-sse. It looked simple enough that I could start using immediately. More problems arose when I tried to use it though.

First, it turns out you can't use the library in tns preview mode. The alternative is to use tns run ios --emulator or use tns run ios with your iPhone connected to your computer. The non-emulator command will automatically deliver your prototype app.

Side note: I had already set up my phone in Xcode. You may have to do this yourself before tns run ios is able to find and deploy to your phone.

Secondly, once I got the library working, I noticed I would get some very nasty errors. The errors seemed to happen whenever a new message from Particle came along.

Turns out the underlying Swift library for iOS had fixed this last year. So I took it upon myself to figure out how to upgrade the NativeScript plugin. I'll save you the time to say that it can be a pain and there is a learning curve!

Fortunately after some hacking I got something working. More instructions on how to compile the plugin are in the README. Alternatively, you can download a pre-built one on the Release page of the repository.

Download the .tgz file to wherever you like. Then, you can add it using tns plugin add. The full command looks like this:

tns plugin add path/to/plugin/file.tgz

You can check to make sure the library is installed by running tns plugin list

**jaredwolff$ tns plugin list
Dependencies:
┌─────────────────────┬──────────────────────────────────────────────────────────────────────────────────┐
│ Plugin              │ Version                                                                          │
│ @nativescript/theme │ ~2.2.1                                                                           │
│ nativescript-sse    │ file:../../Downloads/nativescript-sse/publish/package/nativescript-sse-4.0.3.tgz │
│ tns-core-modules    │ ~6.3.0                                                                           │
└─────────────────────┴──────────────────────────────────────────────────────────────────────────────────┘
Dev Dependencies:
┌──────────────────────────┬─────────┐
│ Plugin                   │ Version │
│ nativescript-dev-webpack │ ~1.4.0  │
│ typescript               │ ~3.5.3  │
└──────────────────────────┴─────────┘
NOTE:
If you want to check the dependencies of installed plugin use npm view <pluginName> grep dependencies
If you want to check the dev dependencies of installed plugin use npm view <pluginName> grep devDependencies**

Once installed, invoking the library takes a few steps. Here's an example:

import { SSE } from "nativescript-sse";

sse = new SSE(
            "https://api.particle.io/v1/events/blob?access_token=<your access token>",
            {}

// Add event listener
sse.addEventListener("blob");

// Add callback
sse.events.on("onMessage", data=>{
    // TODO: do stuff with your event data here!
    console.log(data);
});

// Connect if not already
sse.connect();

First you need to import and create an instance of the library. When you create the instance, you will have to enter the URL that you want to use.

In this case we'll be doing the equivalent of Particle.subscribe(). It should look something similar to the above: https://api.particle.io/v1/events/<your event name>?access_token=<your access token>.

Replace <your event name> and <your access token> with the name of your event and your freshly created token!

Then you set up the library to listen for the event you care about. In this case blob is the event I most care about.

Then make sure you configure a callback! That way you can get access to the data when blob does come along. I've made a TODO note where you can access said data.

Finally, you can connect using the .connect() method. If you don't connect, SSE will not open a session and you'll get no data from Particle.

Placement of the code is up to you but from the examples it looks like within the constructor() of your model is a good place.(https://github.com/jaredwolff/nativescript-sse/blob/master/demo/app/main-view-model.ts)

Other Examples

If you're curious how to use SSE in other places I have another great example: Particle's CLI.

Particle uses the [request](https://github.com/request/request) library to handle SSE events in the app. Whenever you call particle subscribe blob it invokes a getStreamEvent further inside the code. You can check it out here. The request library has more information on streaming here.

More resources

This is but the tip of the iceberg when it comes to connecting with Particle's API. Particle has some great documentation (as always) you can check out. Here are some important links:

• API documentation
• Javascript SDK
• iOS SDK
• Android SDK

Conclusion

In this post we've talked about app frameworks, NativeScript, NativeScript plugins and Server Sent Events. Plus all the Particle related things so you can connect your NativeScript app to Particle's API.

I hope you've found this quick tutorial useful. If you have any questions feel free to leave a comment or send me a message. Also be sure to check out my newly released guide. It has content just like this all about Particle's ecosystem.

Until next time!

This post was originally from https://www.jaredwolff.com/how-to-develop-particle-iot-apps-using-nativescript/

This post is originally from www.jaredwolff.com

In this post, I’m going to show you how to get started with Grafana and InfluxDB. All of this running docker container on Digital Ocean.

That way you can have pretty graphs like these:

The cost?

$5 a month

Let’s get to it.

Steps

1. Login to Digital Ocean. If you don’t have Digital Ocean and would like to support this blog click here to create an account.
2. Go to Account Settings -> Security and make sure you have an SSH key setup.
3. Create a new droplet use their docker image
4. Make sure you select the $5 a month plan. For simple installs, this is more than enough!
5. SSH in once you’re done: ssh root@<yourserverip>

6. Set up InfluxDB

      docker run --rm -e INFLUXDB_HTTP_AUTH_ENABLED=true -e INFLUXDB_DB=particle -e INFLUXDB_ADMIN_ENABLED=true -e INFLUXDB_ADMIN_USER=admin -e INFLUXDB_USER=grafana -v influxdb:/var/lib/influxdb influxdb /init-influxdb.sh
   

   Watch the output of this command. It will generate passwords for both your admin and grafana user. Save these in a safe place!

7. Start influx

      docker run -d -p 8086:8086 \
            -v influxdb:/var/lib/influxdb \
            -e INFLUXDB_HTTP_AUTH_ENABLED=true \
            influxdb
   

8. Add firewall rule

      ufw allow 8086
   

   This allows the outside world to get to your InfluxDB instance.

9. Set up curl from Particle

   Example equivalent call:

      curl -i -XPOST 'http://<DOCKER IP HERE>:8086/write?db=particle' --data-binary 'temperature,id=<ID HERE> value=22.1'
   

   The version of this to put in the custom request would be:

      temperature,id={{{PARTICLE_DEVICE_ID}}} value={{{temperature}}}
   

   

   Note: see under QUERY PARAMETERS that db is pointing to particle. This should point to whatever you set INFLUXDB_DB to in step 6

   Second Note: make sure that the username and password is the one you set up on step 6 as well. In this example the username is grafana

   

   Here’s a more complex version:

      temperature,id={{{PARTICLE_DEVICE_ID}}} value={{{temperature}}}
      humidity,id={{{PARTICLE_DEVICE_ID}}} value={{{humidity}}}
      tvoc,id={{{PARTICLE_DEVICE_ID}}} value={{{tvoc}}}
      c02,id={{{PARTICLE_DEVICE_ID}}} value={{{c02}}}
      {{#pm25}}pm25,id={{{PARTICLE_DEVICE_ID}}} value={{{pm25}}}{{/pm25}}
      {{#pm10}}pm10,id={{{PARTICLE_DEVICE_ID}}} value={{{pm10}}}{{/pm10}}
      {{#sgp30_tvoc}}sgp30_tvoc,id={{{PARTICLE_DEVICE_ID}}} value={{{sgp30_tvoc}}}{{/sgp30_tvoc}}
      {{#sgp30_c02}}sgp30_c02,id={{{PARTICLE_DEVICE_ID}}} value={{{sgp30_c02}}}{{/sgp30_c02}}
      {{#bme680_pres}}bme680_pres,id={{{PARTICLE_DEVICE_ID}}} value={{{bme680_pres}}}{{/bme680_pres}}
      {{#bme680_iaq}}bme680_iaq,id={{{PARTICLE_DEVICE_ID}}} value={{{bme680_iaq}}}{{/bme680_iaq}}
      {{#bme680_temp_calc}}bme680_temp_calc,id={{{PARTICLE_DEVICE_ID}}} value={{{bme680_temp_calc}}}{{/bme680_temp_calc}}
      {{#bme680_hum_calc}}bme680_hum_calc,id={{{PARTICLE_DEVICE_ID}}} value={{{bme680_hum_calc}}}{{/bme680_hum_calc}}
   

   For conditional data you can wrap the whole line in the variable that may or may not be there:

      {{#bme680_pres}}<insert stuff related to bme680_pres>{{/bme680_pres}}
   

10. Next! Install Grafana with persistent storage

      # create a persistent volume for your data in /var/lib/grafana (database and plugins)
      docker volume create grafana-storage
    
      # start grafana
      docker run \
        -d \
        -p 3000:3000 \
        --name=grafana \
        -v grafana-storage:/var/lib/grafana \
        grafana/grafana
    

11. Add firewall rule for graphana

        ufw allow 3000
        `
    

12. Login. This should be your Digital Ocean Droplet ip + :3000 appended. Example: 123.456.789.101:3000 (Default username and password is admin and admin)

13. Connect Grafana to Influx (should be one of the first options on a fresh Grafana install)

    

    

    Note under user, you’ll have to put the username grafana and the generated password from step 6. Also the name of the database has been set as particle in the same step.

14. Test your connection by clicking Save & Test It should come back quickly saying whether or not a connection has been successful.

15. Start up your device, if not already, and get it publishing to your InfluxDB database.

    (Need data? This project should get you some!)

16. Create graphs!

    Finally, the reason why you came to this page: pretty graphs

    Click the + icon on the left and create a new dashboard

    

17. Select Add Query

    

18. Go down and click select measurement If your device has been publishing to your database, you should see some options for values.

    

19. Under fill(null) change that to fill(none). That should give you a nice line between datapoints.

20. You should see the graph appear!
21. Click the back arrow button and then click the save button.
22. You now created a simple graph on the data directly from your device! I recommend you play around with the Grafana interface. It's fairly intuitive and takes only a few short minutes to get used to!

HTTPS/SSL

Installing HTTPS/SSL is fairly straight forward. Follow the steps below:

1. Stop the Grafana instance if you haven't already

2. Start a new container with nginx-proxy

   docker run --detach \
       --name nginx-proxy \
       --publish 80:80 \
       --publish 443:443 \
       --volume /etc/nginx/certs \
       --volume /etc/nginx/vhost.d \
       —volume /usr/share/nginx/html \
       —volume /var/run/docker.sock:/tmp/docker.sock:ro \
       jwilder/nginx-proxy
   

3. Run the letsencrypt-nginx-proxy-companion

   docker run —detach \
       —name nginx-proxy-letsencrypt \
       —volumes-from nginx-proxy \
       —volume /var/run/docker.sock:/var/run/docker.sock:ro \
       jrcs/letsencrypt-nginx-proxy-companion
   

4. Restart the Grafana container

   docker run \
     -d \
       --env "VIRTUAL_HOST=<YOUR SUBDOMAIN ADDRESS>" \
     --env "VIRTUAL_PORT=3000" \
     --env "LETSENCRYPT_HOST=<YOUR SUBDOMAIN ADDRESS>" \
     --env "LETSENCRYPT_EMAIL=<YOUR EMAIL ADDRESS>" \
     --name=grafana \
     -v grafana-storage:/var/lib/grafana \
     grafana/grafana
   

   Note: make sure you replace <YOUR SUBDOMAIN ADDRESS> and <YOUR EMAIL ADDRESS> above with your own info.

The proxy companion will generate an SSL certificate for the virtual host that you provided to the Grafana container. The proxy is used to forward all HTTP/HTTPS traffic to your Grafana container. It's clean, it's simple and it's secure!

Note InfluxDB is a bit more difficult. You either need to make a separate subdomain or configure HTTPS to share the certs between Grafana and Influx. This Docker Compose script does it all if you haven't already installed everything. You can follow the same steps above if you want to run it on a separate sub-domain.

Handy Links

Here are some handy links that I found useful getting started with Grafana + InfluxDB

• influxdb | Docker Documentation
• Getting Started | Grafana Documentation
• Installing using Docker | Grafana Documentation
• Let's Encrypt Nginx Proxy Companion
• Very Handy about Setting up HTTPS for both Grafana and Influx

Conclusion

You made it. Enjoy your new Grafana + InfluxDB install!

If you liked this tutorial, please share with your friends and your enemies. Also if you’re craving more, check out how to build your own air quality sensor using only a few parts.

This post is originally from www.jaredwolff.com

I got my hands on some of the mesh based Particle boards not too long ago. I’ve been itching to try them out but haven’t quite figured out the project.

One thing has been bothering me though: air quality. I spend a good amount of time in my office tinkering, soldering, coding and writing. I sneeze occasionally so I always wondered, how bad is it? The house is also prone to mold exposure during the hot months which had me concerned.

So why not cook something up?

What’s needed

The most important sensor is the Honeywell HPM series PM2.5/PM10 sensor. This tells you how many micrograms of material is floating around in a cubic volume of space. i.e. it counts the little particles flying around in your air.

Second to that, is the AMS CCS811. This sensor tells you the total amount of volatile organic compounds are in the air along with things like C02. It’s another datapoint which is interesting to see. I’ve previously placed this sensor in our basement only to be surprised and see huge spikes in VOC and C02 levels from our (oil burning) furnace turning on in the morning. Time for better ventilation!

Finally, the Silicon Labs Si7021 temperature and humidity sensor. These two bits of environmental data are useful. More importantly they’re used by the algorithm in the CCS811 to compute the TVOC and C02. Considering the cost of the CCS811, I’m surprised it doesn’t have these measurements on board but maybe in their next revision..

Wiring it all together

It’s time to wire everything together. At the very least you’ll need:

1. Solder-less breadboard hookup wire
2. A solder-less breadboard
3. A CCS811 breakout board from Adafruit (more details here)
4. A Si7021 breakout from Adafruit(more details here)
5. A Particle board of your choice.
6. A HPMA115 Particle sensor
7. Pre assembled Molex cable for the HPMA115 (Molex P/N 0151340803 or similar)
8. Some 0.1” pitch headers

I’ve included a Fritzing example with this project. There’s also a hookup image below:

Note: the original Fritzing diagram was incorrect. Both Vin of the CCS811 and Si7021 should be connected to the 3.3V on the Particle

An Adafruit Feather is used to represent the Particle Argon. Particle does not have Fritzing models quite yet.

As you can see everything is hooked up except for the PM2.5 sensor. The pinout is included below.

The most important pins are the 5V, GND, RX and TX pins. The other ones can stay disconnected if you choose. Here are the connections called out:

5V -> USB GND -> GND RX -> TX (on the Argon) TX -> RX (on the Argon).

Here’s a picture of everything assembled on a solder-less breadboard.

Another important note is that I modified the cable for the HPMA so they had male pins on the end. That made it easy to insert into the solder-less breadboard. Here’s a zoomed in shot:

When you purchase the cable for the PM2.5 sensor it came pre-populated with 8 wires. To make things simpler, you can remove 4 of the wires that are not used. The best way to do that is take a sharp tipped tool (dental pick, sewing needle, etc) and stick it under the clips I’ve pointed out in red below:

Then, once you have your sharp implement underneath, tug on the wire and it should slide out.

Now you have less wire and less headache. You can use this technique to modify any Molex-like connector.

Plumbing the firmware

For this project I decided to keep my code consistent with the Wiring/Arduino-like API. That means object oriented C++. It’s been a while where I’ve coded in C++ so when you’re looking at the codebase and wondering “why the hell did he do that!?” Sorry, not sorry. ?

The best way to get started is to use Visual Code with the Particle plugins for this project. Click here to get started if you're not already setup.

Si7021

The Si7021 is super simple. It only has 4 active pins out of the 6 on the chip.

(Copied directly from the Si7021 documentation)

The best say to read the temperature/humidity sensor is to issue a blocking read command. In an embedded world, this is not ideal. Unfortunately, there’s no way to know when the readings are ready because there is no interrupt pin.

As described in the data-sheet, you first write the command and then attempt to read directly from the device. The code looks something like this:

    // Si7021 Temperature
    Wire.beginTransmission(SI7021_ADDRESS);
    Wire.write(SI7021_TEMP_HOLD_CMD); // sends one byte
    Wire.endTransmission();           // stop transaction
    Wire.requestFrom(SI7021_ADDRESS, 2);

    // Get the raw temperature from the device
    uint16_t temp_code = (Wire.read() & 0x00ff) << 8 | (Wire.read() & 0x00ff);

Wire the address of the device, write the command and then subsequently read the number of bytes necessary (Two in this case) The Si7021 will then stretch the clock until the reading has completed.

I didn’t mess around with other settings. Depending on your environment you may have to tweak how much current to feed the heater. You’re mileage may vary so prepare accordingly!

Finally, these readings are read on a reoccurring timer. I originally was using the millis() call and calculating the different of the start and current time but this eventually breaks (in 50 or so days). Instead I decided to use a system timer (similar to if not the same as the APP_TIMER in the NRF SDK)

Timer timer(MEASUREMENT_DELAY_MS, timer_handler);

That way you get your interrupt always at MEASUREMENT_DELAY_MS no matter what! (In my case MEASUREMENT_DELAY_MS = 60000 ms == 60s)

The CCS811

The CCS811 gives you a bit more freedom to play but it comes with it’s own specialness.

In most cases the ADDR pin is set low. This pin modifies one bit of the address. This is useful if you have two of the same device or two devices with the same address on the same I2C bus.

The CCS811 also has a few handy input and output pins. The most important is the interrupt pin. Whenever a reading is complete, this open drain pin will be pulled low. It will only get reset once you read the status register. This is great for asynchronous reads that way you’re not locking up your MCU.

One important point is that the CCS811 does require you to issue a “start” command. This forces the internal MCU to start executing the TVOC/CO2 sensing algorithm. If you attempt to read the data registers before the application is started you will get bogus data. (The command is 0x90)

In the firmware, the CSS811 is processed in the same loop as the Si7021. The code pulls the available data from the CSS811 asynchronous readings. No blocking code!

The HPMA115

The particle sensor is a bit more tricky. When it is turned on, the device starts sending particulate data on a regular interval. i.e. it’s in auto-send mode every time it powers up.

I tried previously to configure the device but sometimes I wouldn’t get a response back. It was always hit and miss. It drove me crazy.

So, in order to turn the device off wen you’re not using it I highly suggest using a load switch of some kind. Not only will this save power but according to Honeywell, it will also increase the lifespan of the fan.

The flow of the readings:

• Every minute turn it on
• Wait for data to be sent
• Read the reading asynchronously via UART
• Turn it off
• Bundle that data into the JSON blob to be sent to the server

This way there’s no need to mess with any registers. All the more reason why I2C and even SPI are better data buses than UART. I just want it to work!

I originally chose this sensor a while back for it’s enclosed nature. In my option, it’s easier to integrate. My electrical engineer brain doesn’t want to deal with complex stuff. Give me a box and lets go.

Getting everything working

During the development phase of this project I happened to be traveling abroad. The crappy wifi was not cutting it and it was taking forever to iterate on the code. The Argon also had a hard time connected to my iPhone’s AP so I gave up on that idea early on.

So, in order to develop the code that didn’t require the internet I placed the device into manual mode. What does manual mode do? It allows the code to start execution despite not being connected to the Particle cloud. That way you can take readings all day but you don’t have to be connected to Wifi. You can put the device in manual mode by putting this define in your .ino file:

SYSTEM_MODE(MANUAL);

In battery powered applications, this is ideal. Wifi is expensive power-wise and you don’t need to be running it if you don’t have to!

In a previous experiment, I found that it took about 10-15 seconds from nothing to sending data to the Particle cloud. That’s a long time in the embedded world. That’s one of the main reasons I suspect Particle came out with their mesh system. This allows sleepy end nodes (or nodes that are taking data and periodically sending it to a central point) to run much longer than their Wifi based cousins.

Remember you will have to run the Particle.connect() function in order to connect to wifi in manual mode. Or if you’re ready for it to re-connect, remove SYSTEM_MODE(MANUAL); from your .ino file.

Changing Wifi Credentials

During my experiment in trying to get my wifi to work I did discover a few handy Particle tools to change wifi credentials etc. By holding the mode button during operation, the device eventually starts blinking blue. Once blinking blue, you can issue a particle serial wifi which will walk you through the process of changing the credentials.

The above process is light years faster than using the iPhone/Android app. I thought the app was cool at first but man does it take a long time to scan and get your devices connected.

More info on this procedure go here.

Recovering when things go awry

I had to recover my Argon during my development process. I did some digging and found that re-programming the OS, App and Bootloader seemed to do the trick.

Get the files here: Release 0.9.0 (Gen 3) · particle-iot/device-os · GitHub (As of this writing the latest is 0.9.0)

Then program these files in DFU mode by holding the mode button after tapping the reset button once.

particle flash --usb system-part1-0.9.0-argon.bin
particle flash --usb tinker-0.9.0-argon.bin

Program this one in Listening mode:

particle flash --serial bootloader-0.9.0-argon.bin

Note: the -argon suffix may be different depending on what you’re programming to. Other options are -boron and -xenon.

Monitoring on the command line

Finally, one of the most useful commands is this one:

particle serial monitor --follow

This allows you to use the USB Serial interface to receive debug messages from he device. This is akin to connecting an FTDI device to an Arduino.

For instance, I may be debugging part of the code so I want to see some data. In the Setup() function I’ll be sure to run Serial.begin(), then later on I’ll make a Serial.printf(“data: %d”,data.tvoc); in order for it to be sent over the USB Serial interface.

Serial UART for debugging, it’s a beautiful thing.

Publishing

One thing I did discover during the development process was the publishing limits of the Particle platform. For a single device, you cannot Particle.Publish more than 4 pieces of data in one second. Even though I was taking data every minute, I was sending 6 pieces of individual data to the server at the same time. After testing I soon started to wonder why the heck my C02 and TVOC readings disappeared.

I had found the culprit.

So, in order to make things work, I had to format it as a JSON blob. See how I did it exactly below:

String out = String::format("{\"temperature\":%.2f,\"humidity\":%.2f,\"pm25\":%d,\"pm10\":%d,\"tvoc\":%d,\"c02\":%d}",si7021_data.temperature,si7021_data.humidity,hpma115_data.pm25,hpma115_data.pm10,ccs811_data.tvoc,ccs811_data.c02);
Particle.publish("blob", out , PRIVATE, WITH_ACK);

I created a JSON structure and then used String::format to insert each piece where they needed to be. If you are running your device over LTE this will cause you to send more data than necessary. There are better options like Protocol Buffers or using MessagePack. If you’re dealing with complex data, I recommend the former because of its programatic nature. Plus, you can use it with just about any programming language. So web to embedded? No problem.

After every minute, I only send the data when all three sensors have been read. I use three separate boolean values to determine the state of the sensor readings. Once they have all been set to true do I invoke the Particle.Publishcall.

Then after publishing, I reset all variables like so:

ccs811_data_ready = false;
si7021_data_ready = false;
hpma115_data_ready = false;

Then, everything starts all over again. You can also create a status struct which has each of these flags neatly inside. Considering I only have three data points, I didn’t go the extra mile there.

Using Adafruit IO

One way to publish is by using Adafruits IO platform. Here's how to get started.

1. Create an account here: https://io.adafruit.com

2. Next is to create feeds for each of the data types. We’ll need 6 in total.

3. For each feed, add a Webhook.

4. Take each webhook address and create a new Webhook in the Particle console
5. Change the Request format to JSON
6. Then under Advanced Settings click on Custom for the JSON DATA

7. Replace what’s there using mustache templates. Adafruit IO is looking for a JSON key called value. So set it like this:

   {
    “value”:”{{{c02}}}”
   }
   

   You can replace c02 with any of the keys in your JSON blob. As a reminder the current JSON blob looks something like this:

   {
    “temperature”:21.2,
    “humidity”:30,
    “pm10”:2,
    “pm25”:1,
    “tvoc”:650,
    “c02”:1001
   }
   

8. Repeat this as necessary until all feeds have a corresponding Webhook configured.
9. Finally, you can create a dashboard to see them all in one place. This is straight forward just follow the on screen prompts. :)

You can check out my live dashboard here. It’s nifty and just another way to display your data.

Sidenote: My first impressions on Adafruit IO are good. It was easy to setup and start using. The main drawback that it’s tedious especially if you have more than a handful of data points. But maybe they’ll fix that in the future!

Update: If you have multiple pieces of data. You can point your Particle integration to a single endpoint. Just make sure the data is in the same group! Here's an example of multiple values sent to the same group:

{
  "feeds": [
    {
      "key": "tvoc",
      "value": "{{{tvoc}}}"
    },
    {
      "key": "c02",
      "value": "{{{c02}}}"
    },
    {
      "key": "temperature",
      "value": "{{{temperature}}}"
    },
    {
      "key": "humidity",
      "value": "{{{humidity}}}"
    },
    {
      "key": "pm2-dot-5",
      "value": "{{{pm25}}}"
    },
    {
      "key": "pm10",
      "value": "{{{pm10}}}"
    }
  ]
}

Where your URL should look something like:

https://io.adafruit.com/api/v2/<USERNAME>/groups/<GROUPNAME>/data

That should keep your Particle integration page a little more sane!

Making sense of the readings

The readings can be confusing. Here’s the breakdown of how they work:

1. Humidity is showing in relative percentage points. This is the relative humidity we know and love. Remember it may differ with what’s outside. This depends on if your house is air conditioned or if you’re running a heater etc.
2. Temperature is in degrees C (can be modified in firmware if you so choose)
3. TVOC is in ppb (parts per billion). VOCs can be in the form of harmful chemicals you have around the house. More information about VOCs check out thislink from the EPA.
4. C02 is in ppm (parts per million). We breathe in oxygen and exhale carbon dioxide. You may find your VOC and C02 levels rising when you’re in the room. C02 does correlate to VOCs as well. More info in the data sheet.
5. PM10. Is in µg/m3 (micrograms per meter cubed). The particle sensor uses a scattered laser when then shines across the air chamber to a sensor on the other side. The more the rays are blocked, the more particles in the air. The particle sensor then does some calculations to determine the amount of particles in a certain volume and thus your µg/m3.
6. PM2.5 is the same as above but it tracks much smaller particles. (Less than or equal to 2.5µm in size!) More information on the EPA’s website here.

Don't care for something you have no control over?

Check out my tutorial on creating your own amazing looking IoT dashboard.

You did it!

Congrats. You've made it this far. You deserve a day at the spa. Or maybe some chocolate ice cream. Or if you're really feeling adventurous, both, at the same time?? ?

After building one of these you may feel like your time is worth investing elsewhere. Maybe you want to build a cool web backend with fancier charts and algorithms. Maybe even use some machine learning (why not!)

If you want something already assembled and available you should check out the Particle^2 (Pronounced Particle Squared). It has everything here including the ability to switch on and off the HPM particle sensor. You can even run it on batteries! So put that sucker anywhere you want. Check it out here.

Here's the full video on the Particle Squared.

Code and Source

This whole project is released under the Creative Commons Share-Alike license. Get the source code and hardware files here.

Get Ready for the Ultimate Guide

This post is an excerpt from my upcoming Ultimate Guide on Particle Mesh. Early subscribers get a discount when it becomes available! Click here to get signed up.

“The Internet will disappear. There will be so many IP addresses, so many devices, sensors, things that you are wearing, things that you are interacting with, that you won’t even sense it. It will be part of your presence all the time. Imagine you walk into a room, and the room is dynamic. And with your permission and all of that, you are interacting with the things going on in the room.”

Nowadays many devices that we use day to day are connected to the internet like Television, smart speakers, refrigerators, etc. These devices extend their primary functions which allows them to interact with other devices on the internet and to be controlled remotely.

You can build your own IoT devices using some sensors and microcontrollers. There are many development boards that will help you get started with IoT like Arduino, NodeMCU, Raspberry Pi, etc. You can automate your home by building from these devices.

In this post, we will be using NodeMCU devkit and Firebase for turning on and off LED remotely. NodeMCU devkit and Firebase are the best combinations to get started with building some IoT projects. NodeMCU is cheap and has built-in wifi for internet connectivity, and the Firebase free plan is more than enough.

Setting up Development Environment

1. We will be using Arduino IDE for writing code and we will flash the code to the device. Download the latest version of the IDE here.

2. Since we are using NodeMCU which is not officially supported by Arduino IDE, we have to add the JSON file of the device. In Arduino IDE add this URL in

Open File > Preferences > Additional Board Manager URLs

http://arduino.esp8266.com/stable/package_esp8266com_index.json

3. Select your Board from

Tools > Board > NodeMCU 1.o

4. To use firebase database in NodeMCU you need to download the firebase-arduino library which abstracts the REST API of the firebase. Download firebase-arduino here.

5. Include the downloaded zip file on Arduino IDE.

Sketch > Include library > Add .zip > Select zip file

6. You also need to install the ArduinoJson library which can be downloaded from Arduino IDE itself.

Note: The library version should not be 6.x.x — use the latest 5.x.x

Sketch > Include library > Manage Libraries > Search for ArduinoJson by Benoit Blanchon

Setting up Firebase Database

7. Create a new firebase project from the console and head towards the database section. Select the firebase real-time database.

8. Copy the database secret for authentication from Settings Panel > Service accounts.

Database secret

9. Add a led node to the firebase database. This value will decide whether to turn on or off the LED.

Configuring Arduino IDE and firebase database to work together

Now that all the setup procedures are done let’s start coding.

You need to create a macro for your database URL and firebase secret which you had copied in Step 8.

#define FIREBASE_HOST “yourfirebasedatabase.firebaseio.com”

#define FIREBASE_AUTH “*”

For simplicity, we will write a simple code for turning on and off LED remotely

10. The positive of the LED should be connected to the D1 pin and negative pin to the ground pin of NodeMCU.

11. Upload your code from Arduino IDE.

Sketch > Upload

12. Now try changing the database value to true and false. The led should now start turn on and off. Additionally, you can extend this project by creating a web app that will toggle the LED instead of manually changing the value in the database.

So now that you understand the basics of how to go about connecting NodeMCU to the internet and controlling it remotely, start hacking some new projects with it.