Using BeagleBone Black as an edge node for real-time ward monitoring — looking for advice on the MQTT to REST bridge

General Discussion
,
1

Hi all, long-time reader, first post. Working on a project that I think is reasonably relevant here and could use some community input on a specific integration challenge.

Background

I work on the IT and operations side of a clinic network. We recently finished rolling out a Hospital Management System across our sites, which handles patient records, admissions, pharmacy, billing, and the usual administrative stack. The core platform is working well. The gap we are now trying to close is real-time environmental and equipment monitoring at the ward level, specifically bed occupancy sensing, room temperature logging, and infusion pump status tracking, feeding live data back into the central system dashboard.

The architecture we are prototyping uses BeagleBone Black units as edge nodes in each ward. Each node reads from a small cluster of sensors over I2C and GPIO, publishes to a local MQTT broker, and is supposed to forward processed readings to the HMS REST API endpoint on a defined interval. We are running Debian on the BeagleBones with a lightweight Python service managing the sensor polling and MQTT publish side.

The specific problem

The MQTT to REST bridge is where we are hitting friction. We have tried two approaches so far.

The first was a custom Python script running as a systemd service on each BeagleBone that subscribes to local MQTT topics and posts to the REST endpoint directly. This works in normal conditions but handles reconnection poorly when the ward network drops briefly, which happens often enough in our environment to be a real operational issue. Missed readings during reconnection windows are not acceptable for the infusion pump status data specifically.

The second approach was pushing the bridge off the edge node entirely and handling the MQTT to REST translation at a central aggregator on the local server, with the BeagleBones only responsible for sensor read and MQTT publish. This is cleaner in principle but introduces a single point of failure we are not comfortable with given the clinical environment.

What we are actually asking

Has anyone here built a reliable MQTT to REST bridge on BeagleBone that handles intermittent connectivity gracefully? Specifically looking for guidance on local message queuing during disconnection windows so readings are buffered on the device and flushed in order when connectivity restores. We have looked at using SQLite as a local queue but are not sure this is the right tool or whether there is a more established pattern for this class of problem on resource-constrained edge hardware.

Also open to suggestions on whether BeagleBone Black is the right choice for this node role or whether BeaglePlay would give us meaningfully better headroom for the same use case. The I2C and GPIO requirements are modest but we would eventually like to add a small local display for ward staff without a separate microcontroller.

Any pointers to relevant projects or prior threads appreciated. Happy to share more detail on the sensor setup or the REST API structure if it helps diagnose the bridge problem.

2

Hello, and well met!

While I’m sure we’re pleased that you’d consider Beagle devices,
I’m also somewhat puzzled as to the why, so forgive me for asking,
but if network flakiness is the problem, why not start by addressing that?

Secondly, for very modest hardware requirements, why not just use
a ESPHome based approach? I’d certainly be cheaper if you didn’t
have to start from scratch…

Given your area of application, I’m quite amazed how you could actually
manage to get stuff like this certified; unless that’s not a “thing” anymore?

3

Hi Aniket,
I’ve been using Beagle Blacks with MQTT (Mosquitto and Paho-mqtt) for a few years, with a broker open to the wild behind various security measures.

May I ask a few questions? Firstly, what’s the reason for having an MQTT Broker or any message passing service at all? At the outset I intended to minimise the customer bandwidth and data volume, used by the internet connections our Beagles were on. But MQTT can be quite tricky, and has a few pitfalls. In retrospect it would have been much much easier to write a FastAPI app. So why not just let the Beagles make Post requests direct to the REST API? There’s not much in it now for O(1 per sec) message volumes, especially if http3 / quic is used. I’ve never done this with mosquitto, but is the intention to have some redundancy from a broker service running across multiple machines or some HA solution?

Secondly, if there is a real need for MQTT, why is the REST bridge needed if the general purpose is data logging? Testing? My current set up has a client process subscribe to the topics, unpack the payloads, and write directly to the DB (Postgres has WAL enabled, and hopefully no more is needed to prevent concurrency issues when we scale up, but I’ll cross that bridge when we come to it). For security the Beagles and Broker can be on one network (effectively public), the subscriber and broker can be on a separate private sub network, and the broker and DB can be on a third.

I don’t see any reason at all why you couldn’t have a subscribing client process act as an MQTT / REST bridge. The minimal implementation is essentially just Python code in a while loop that polls the broker periodically (and calls a callback function whenever a message arrives on a topic it’s subscribed to). But as with your second approach, this just seems to me to introduce an extra potential point of failure.

I hope that was of some use, and wasn’t just me expalining what I don’t understand about your system design. Fire away with any specific questions and I’ll do my best.

P.S. I assume you’ve already found http://www.steves-internet-guide.com/ ?

4

You can use BeagleBone Black as an edge node by running an MQTT client (like Mosquitto) to collect real-time ward data, then bridge it to REST APIs using a lightweight service (Python Flask / Node.js Express).

Approach (short):

  • MQTT subscriber listens to sensor topics

  • Process/format data locally (edge filtering)

  • Send to REST API using HTTP POST (JSON)

  • Use async queue (like Node.js or Python asyncio) for reliability

Tools:

  • Mosquitto (MQTT broker/client)

  • Node.js (mqtt + axios) or Python (paho-mqtt + requests)

  • Optional: Redis / buffer for offline cases

For scalable and production-ready implementation, you can also refer to services like electronics embedded development solutions which cover IoT edge + cloud integration.

Tip: Add retry + caching logic so data is not lost if API is down.

1 Like
5

I wrote a bridge for my inverter values mqtt publish it is quite fast and buried the BBB receive side (running Venus OS) . I updated the code to have the callback write to a local python dict and then a separate loop/thread to read the dict and send to my bbb ( at reduced 10 sec intervals) otherwise you are at the mecy of the publish side to send your rest calls if they require any kind of response/token I could see the potential to overload …