uBeac IoT Platform — From a Gateway on the Shelf to a Live Dashboard

uBeac was an IoT platform I founded and built from 2017 to 2020. It let anyone connect off-the-shelf Bluetooth gateways, phones and custom devices, and see their buildings live on real-time dashboards in minutes, without writing firmware or cloud code. uBeac was acquired in 2020, and I’ve now published the platform’s source code.

Backend · Web app · Admin panel · OSMonitoring · SBCGateway · Original docs · Setup videos

Why I built it

In 2017, putting a building’s Bluetooth sensors online was harder than it should have been. The hardware was cheap and good: a BLE gateway could already hear every beacon in a room and post what it heard to any URL. The platforms were the problem. The big clouds wanted a certificate for every device and custom code to parse every vendor’s payload. The friendlier dashboard services wanted data in their own format. Either way, someone had to write glue code before anyone saw a chart. I wanted a platform that met the hardware where it was: pick your gateway from a list, paste one URL into its settings page, and watch your building come alive.

The front door: uBeac Hook

In 2018 I launched uBeac Hook at hook.ubeac.io, a free tool for anyone wiring up IoT hardware. One click created an endpoint with its own URL, with no sign-up. Point a gateway, a phone app or a board at it, and every request appeared in the browser as it arrived: headers, body and sender, the payload as a collapsible JSON tree, a live requests chart, export to CSV, and a dozen ready-made snippets to replay the request, from cURL and Python to C# and Node.js. It later learned MQTT, too.

Hook answered the first question every hardware project gets stuck on: is my device sending anything, and what does it send? That made it the natural place to start our tutorials. Between August and October 2018 we published nine short videos, one for each gateway and app uBeac supported early on: the Ingics iGS01, BlueCats Edge Relay, April Brothers BLE Gateway V4, Jaalee iB006N, Minew G1 and Mist AP41 gateways, and the Ruuvi Station, Beacon Scanner and Data Collector phone apps.

Watched back to back, they show the problem uBeac was built to solve. No two vendors set up the same way. Two gateways put up their own Wi-Fi hotspot with a settings page at a different address. One needed an Ethernet cable to a laptop, one a vendor phone app, one a desktop configuration tool, and the Mist access point a full cloud console with floor plans and asset claiming. Some posted over HTTPS, others over plain HTTP, and each sent data in its own format. Yet every setup ended the same way: paste one URL, and data starts flowing.

The same idea carried into the platform. Those gateways and apps make up most of its decoder catalog, and Hook’s live request view grew into the per-gateway debugging screen described below.

Watch the setup videos

What it did

• Connect anything that speaks HTTP or MQTT. Each team got its own ingestion address. A gateway’s native payload was decoded on the server, so nothing was installed on the gateway.
• Discover devices automatically. Devices and sensors registered themselves from their first message, and uBeac learned each sensor’s data shape as it went. Nearby beacons that weren’t yours waited in a live list until you adopted them.
• Put data on the floor plan. Buildings, floors and positioned devices were core features, and a floor-plan widget showed live readings where the sensors actually were.
• Build dashboards without code. A drag-and-drop grid offered indicators, charts, gauges, maps, floor plans and a custom-code widget, in light and dark themes.
• Send alerts. Readings could trigger notifications by email, SMS, Telegram and WhatsApp, through services like Twilio and IFTTT.
• Show the whole path, live. For every gateway, the web app streamed each raw request next to what uBeac decoded from it, and any errors. “Why isn’t my data showing up?” had an answer on one screen.

How it compared

uBeac competed with very different kinds of platforms. This is how it stood during its active years:

The trade-offs were real. uBeac never had device commands or over-the-air updates, and it didn’t speak CoAP or LoRaWAN. The hyperscalers brought per-device certificates, global scale and compliance programs no small platform could match. uBeac made a different bet: the shortest path from “I bought a gateway” to “I can see my building.”

How it’s built

Ingest fast, process later. Two ingestion services, one for HTTP and one for MQTT, do only what has to happen while a gateway waits: identify the team and gateway (from the host name, or the MQTT client ID), check the gateway’s security settings, and put the message on a queue. Six small workers do the rest, each with one job, connected by RabbitMQ. A single message envelope travels the whole way and picks up detail at each step.

Decoders are data, not deployments. Every gateway model in uBeac’s catalog carried its decoder as C# source code in the database. At start-up, the decoding worker compiled every decoder in memory with Roslyn, the .NET compiler. Supporting a new gateway meant adding a catalog entry and restarting one worker, not releasing a new version of the platform. Shared parsers for iBeacon and Eddystone, plus helpers for generic JSON, kept most decoders short.

The database doubles as the configuration bus. When someone added a gateway or edited a dashboard, the API wrote to MongoDB, and MongoDB change streams told every service that cared. The ingestion hubs started accepting the new gateway’s traffic, and every open browser on that team updated, with no polling and no restarts.

Tenants are separated at every layer. Each team had its own ingestion subdomain, its own time-series collections with automatic 90-day retention, and its own slice of the MQTT broker’s topic space, so the broker doubled as a private one for the team’s own subscribers.

From a phone to a dashboard in two minutes. New users didn’t need hardware. The onboarding wizard showed a QR code that turned the user’s phone into a gateway streaming its own sensors, spotted the first data live, and generated a dashboard for it.

Around the platform

Two small edge agents show how uBeac reached devices that no gateway vendor covered. Both post plain JSON over HTTP and needed nothing special from the platform.

OSMonitoring turns a Windows or Linux computer into a uBeac device. Every few seconds, a Python agent reads the machine’s CPU, memory, disk, network, battery, fan and temperature sensors, measures internet speed, and posts it all in uBeac’s generic JSON format. The platform created the device and its sensors from the first post, so a live dashboard for a server room or a home lab took minutes. It’s also why uBeac’s sensor catalog has types like Processor, Memory, DiskSpace and BandWidth next to temperature and humidity.

SBCGateway, built by the uBeac team in 2018, turns a Raspberry Pi into a do-it-yourself gateway. Three scanners listen to the room: one for BLE advertisements from beacons and sensor tags, one for classic Bluetooth devices, and one for the Wi-Fi probe requests phones send while looking for networks, which is the basis of presence detection. The Pi forwards raw advertisements, so parsing stays on the server, where uBeac’s decoders live.

Engineering notes

Four of the harder problems, and what worked:

• MongoDB at more than 100 million documents a week. A collection-per-gateway design, index tuning (one query fell from 2,020 ms to 186 ms), batch-size tuning and a Decimal128 serializer brought inserts to a steady 13,000 to 19,500 documents a second.
• Retries on RabbitMQ. Failed messages were retried through per-step TTL queues that dead-letter back to the source queue.
• Live data. For the Vue web app, the SignalR connection pool was cut from 100 to 20, and connections stayed alive across web-server restarts.
• Security. MQTT on ASP.NET Core 2.2, IdentityServer authentication for SignalR, machine access tokens, per-gateway throttling, and IP allow and deny lists.

My role

I founded uBeac on my own in 2017 and designed the platform end to end: the ingestion model, the queue-based pipeline, the decoder catalog, multi-tenancy, the identity and real-time services, and the building-centered data model. As uBeac grew, I led a small team and kept writing much of the core myself: the Roslyn-compiled decoder engine and the BLE parsers, the MongoDB change-stream plumbing, the web app that sat on top of it, and uBeac Hook.

The architecture evolved with the product. The first version was a conventional web API on Azure. By 2018 I had rebuilt it on .NET Core with MongoDB, RabbitMQ and MessagePack. In mid-2019 I split two monoliths into the eleven small services it ran on until the end.

What happened next

uBeac was acquired in 2020, and the hosted service has since been retired. In 2026 I published the backend, the web app, the original admin panel and the two edge agents under the MIT license, with each repository documented from the code: architecture diagrams, the full pipeline, the data model, developer workflows, and an honest list of what I’d fix before running it again.

Stack

.NET Core · ASP.NET Core · RabbitMQ · MongoDB (replica set, change streams) · IdentityServer4 · SignalR · MQTTnet · Roslyn · MessagePack · Serilog · Vue 2 · Vuex · Highcharts · Leaflet · Google Maps · gridstack.js · Azure Pipelines · IIS · Python (edge agents)

From the uBeac years

• Configure BLE Gateways with hook.ubeac.io — nine setup videos on uBeac’s YouTube channel, August to October 2018
• Getting Your uBeac Web Hook and Viewing Data — my post on Medium, May 2019
• IoT Solution with ESP32, JSON and a Perfect Simple Platform — Hackster, June 2019
• IoT Dashboards for Sensors on Android Device using uBeac — my tutorial on Hackster, January 2020
• BLE Weather Station with ESP32 and Ruuvi — Hackster
• Coronavirus Tracking and Monitoring: Using IoT with an ODROID-C2 — ODROID Magazine