MQTT enablement

[NohWayJose]

Hiya,

I know you weren't keen to implement MQTT in Juggluco yourself but I really need it and so I've forked your repo and added MQTT capability using the Paho library that an old colleague of mine maintains. I don't have the Android SDK or experience using it or experience of Gradle, so can we discuss you taking a look at my fork and building it. All I want is an MQTT enabled apk, to see how it's turned out, maybe make a UI tweak or two, if necessary. Then, if it's useful to you or others, run with it. As I recall, there were several of your users, including me who were interested in an MQTT enabled version.

Take a look at: https://github.com/NohWayJose/Juggluco

Please help :D

Regards,
Greg

[j-kaltes]

I have no idea what use could be made of MQTT. Could give the following information?

• How does one configure a free MQTT server at the internet so that Juggluco can communicate with it?
• What are the apps that make use of it? Could you can give an url to them so that I can test out what can be done with MQTT?

[NohWayJose]

Hiya, just so I understand...
a) can you see the fork and its proposed changes?
b) how much time/effort is it to run a build against it (assuming there are no blocking errors)? If it's relatively easy, please will you indulge me and spin up an apk for me to try out, to see how well it works. As I said, I've no Android or Gradle experience and could really do with your help. If it isn't too much of an ask?

[NohWayJose]

@j-kaltes Hi Jaap, any thoughts on helping me out - I hope it's not too difficult or time consuming and it would help me construct my favoured use case, which is sending (and tuning) a regular update of my blood glucose summary data, trends & correlations to my diabetic nurse. I'm happy to walk you through the MQTT/Node-Red parts once I've managed to build it, but I'm reliant on you for an initial build of my fork.
Kind regards
Greg

[NohWayJose]

@j-kaltes any chance of an encouraging reply. I'd really appreciate it and it would be a good way to see what interest there is out there for MQTT (I think a lot, particularly in relation to Home Assistant.) Please.....

[NohWayJose]

For users who are personally technical, there are at least two routes to exploit a regularly published blood glucose reading

1. set up a personal broker - for example Mosquitto on a Raspberry Pi and then use the graphical programming to process/aggregate/analyse the reading immediately or over time
2. Use an IoT solution cloud or locally hosted to digest and process the reading for analysis/graphing/reporting

For non technical users, its presence offers an opportunity for new and existing apps to consume the data, with little or no user config.

MQTT and NodeRed allow the adoption of a much more efficient pub/sub model (than a polling model). MQTT also has the benefit of using an asynchronous, content agnostic transport that can also carry related data from say a fitness tracker. Just as an off the cuff idea, inputs from CGM and fitness tracker can be consumed securely & easily aggregated into a datastructure and concurrently reported on, fead to a health professional and used to build an LLM prompt to feed back on the correlation between exercise markers, such as Blood O2, heart rate and the blood glucose trend and perhaps offer contextually grounded advice on keeping glucose constrained.

As for apps that use it, again there are at least three answers:

1. Write your own. Using NodeRed for example, makes this trivial and highly personal
2. Using IoT home managers, such as HomeAssistant, gives more generic analysis and dashboards in a common dashboard environment, using HomeAssistant's auto-discovery capability. Or customised for a more personalised dashboard
3. Once an MQTT output is available, there is a ready market for App designers to create apps with added value to give away or sell on the App Stores that use this and other associated data sources, using this open prototcol.

Because it's an open prototcol, using it both decouples the innards of your app from how it's consumed and makes it MUCH easier to consume and is not a drain on processing, like a polling model. MQTT is a pub-sub model, so if a consumer is interested, it just needs to subscribe and it will get the notification as and when it is published, not on a regular cadence whether or not the information is updated.
6.

[NohWayJose]

https://mqtt.org/use-cases/
https://nodered.org/
https://www.home-assistant.io/integrations/mqtt

[stephend61]

Hi All,

Sorry a bit late to this party, but I could see some use for mqtt messaging of my readings, but I can see one downside, that you could miss some readings if you went off line as at best, you can only retain the last message.

I am thinking the mqtt part might be better in the server than the mobile device, that would reduce the likely hood of losing data and avoids the polling as it would just send a message when it recieves data from the mobile device.
Probably easier to implement too.

I currently use the server and call the export on a timer to send the data to influxDB and then graph the data in grafana.
so mqtt would get rid of the polling and avoid reimporting all that data everytime.

I use tailscale to maintain a connection to my home network so generally would work fine for me, I have been very happy with it.

PS. thanks for the great app, I have been using it for a few years now, but did take a little break due to the cost of the CGM's but found a cheaper one now, 1/2 the price of libra, so trying that out.

[NohWayJose]

That isn't true though. See https://mosquitto.org/man/mqtt-7.html

Quality of Service

MQTT defines three levels of Quality of Service (QoS). The QoS defines how hard the broker/client will try to ensure that a message is received. Messages may be sent at any QoS level, and clients may attempt to subscribe to topics at any QoS level. This means that the client chooses the maximum QoS it will receive. For example, if a message is published at QoS 2 and a client is subscribed with QoS 0, the message will be delivered to that client with QoS 0. If a second client is also subscribed to the same topic, but with QoS 2, then it will receive the same message but with QoS 2. For a second example, if a client is subscribed with QoS 2 and a message is published on QoS 0, the client will receive it on QoS 0.

Higher levels of QoS are more reliable, but involve higher latency and have higher bandwidth requirements.

0: The broker/client will deliver the message once, with no confirmation.

1: The broker/client will deliver the message at least once, with confirmation required.

2: The broker/client will deliver the message exactly once by using a four step handshake.

And the beauty of it is that the publisher, broker and subscriber don't have to be connected or even on at the same time and yet still achieve lossless comms with the correct QoS

[stephend61]

Thanks , I didn't realise it could guarantee delivery, I have been using for years, I will have to try it and see, in any case it could be implemented from either end server or mobile, I would use it if available.

[stephend61]

Hi All,

If you are interested I have done some work on the server code to add mqtt, I have it working on my private server in a kubernetes cluster, the output looks like below, I can put the code up on git if interested.

All the mqtt config is contained in the .jugglucorc file. Note you need be careful not clear it due to the -d / -c option.

The output is generated when a new reading comes in from the mobile device.

This is the output from mosquitto_sub:

juggluco/glucose {"sensor_index":0,"sensor_id":"C1QBA5A04503","time":1776667522,"time_local":"2026-04-20 16:45:22","tz":10,"minute_index":5895,"raw_mgdl":131,"raw_mmol":7.3,"cal_mgdl":106.5,"cal_mmol":5.9,"cal_available":true,"change":-0.242246,"trend":3}

juggluco/glucose {"sensor_index":0,"sensor_id":"C1QBA5A04503","time":1776667822,"time_local":"2026-04-20 16:50:22","tz":10,"minute_index":5900,"raw_mgdl":131,"raw_mmol":7.3,"cal_mgdl":106.5,"cal_mmol":5.9,"cal_available":true,"change":-0.221180,"trend":3}

here is the code

https://github.com/stephend61/Juggluco/tree/mqtt-branch/Common/src/main/cpp
See the readme

[NohWayJose]

Hi All,

Great to see @stephend61 has got a server-side implementation working — and with a very rich payload too. Between the two approaches there's now a complete solution for j-kaltes to consider:

Server-side (stephend61's implementation)
https://github.com/stephend61/Juggluco/tree/mqtt-branch/Common/src/main/cpp

• Published from the Juggluco server daemon, configured via .jugglucorc
• Rich payload including raw vs calibrated values, sensor ID, trend code, local time
• Ideal for users already running the server component

Android/mobile-side (my fork)
https://github.com/NohWayJose/Juggluco

• Published directly from the Android app on every sensor reading
• Configured via Settings → Exchanges → MQTT (broker, port, topic, optional credentials, test button)
• Uses Eclipse Paho MQTT v3 (mobileImplementation only — no impact on wear/small build size)
• Minimal payload: {"mgdl":105,"mmol":5.8,"trend":0.0012,"timestamp":1716630000000}
• Useful for mobile-only users who don't run a dedicated server

The two are complementary rather than competing. A user running the server gets the richer payload from stephend61's implementation; a user running the app standalone gets coverage from the Android side. If j-kaltes wanted a single merged approach, stephend61's payload schema would be the better one to standardise on — the Android side could be updated to match it.

@j-kaltes — would you be open to reviewing one or both of these? Happy to help with anything on the Android/Gradle side.

[NohWayJose]

Node-RED workaround: Nightscout bridge → MQTT → MySQL + nurse email reports

While waiting for native MQTT support in Juggluco, I built a Node-RED-based
workaround that uses Juggluco's existing built-in Nightscout publisher as
the transport. No app changes needed at all.

---

How it works

Juggluco already knows how to POST to a Nightscout server. This flow
implements just enough of the Nightscout REST API in Node-RED to accept those
posts, so you point Juggluco at your Node-RED instance instead of a real
Nightscout server.

Node-RED then:

1. Validates the API secret
2. Republishes the reading to a local MQTT broker (glucose/reading)
3. Inserts it into a MySQL table (readings) for history

A second flow subscribes to glucose/reading on MQTT and handles the MySQL
insert, so any other MQTT publisher (including a future native one) feeds the
same pipeline automatically.

Flow: Glucose Readings

Juggluco (Nightscout POST /api/v1/entries)
    → validate API secret
    → parse SGV entries
    → MQTT publish  →  glucose/reading topic
    → HTTP 200 response (Juggluco happy)

MQTT glucose/reading
    → INSERT IGNORE INTO readings (ts, mgdl, mmol)

A GET /api/v1/status stub is also included so Juggluco's connectivity
check passes.

---

Bonus: automated glucose report emails

Flow: Glucose Report

A dashboard page (Node-RED Dashboard 2) lets you set a nurse/clinician email
and a report period (1–31 days). Reports can be sent on demand or fire
automatically at 8am once the configured period has elapsed.

The HTML email includes:

• Average glucose (mmol/L and mg/dL)
• Min / max
• Estimated HbA1c (derived from average glucose)
• Time in range / above / below (4–10 mmol/L)
• Day-by-day breakdown table

Sending uses a local SMTP relay (I use the socat trick to forward via
Protonmail Bridge, but any SMTP relay works).

---

Prerequisites

• Node-RED with nodes: node-red-node-mysql, node-red-node-email,
  node-red-contrib-cronplus, @flowfuse/node-red-dashboard
• A MySQL/MariaDB database with a readings table:

CREATE TABLE readings (
    ts    BIGINT PRIMARY KEY,
    mgdl  INT    NOT NULL,
    mmol  DECIMAL(4,1) NOT NULL
);

• A local MQTT broker (Mosquitto)
• Juggluco configured to post to Nightscout at http://<node-red-ip>:1880
  with your API secret

---

Configuration after import

1. Set your MQTT broker address in the broker config node
2. Set your MySQL credentials in both database config nodes
3. Set your SMTP relay in the email node
4. Replace YOUR_API_SECRET_SHA1_HASH in the "Validate & parse" function
   with the SHA-1 of your chosen API secret — generate with:
   echo -n 'yourpassword' | sha1sum
5. In Juggluco: Settings → Exchanges → Nightscout → set URL to
   http://<node-red-host>:1880 and API secret to match

---

Flow JSON

flows.json
README.md

[NohWayJose]

Comparison: Node-RED Nightscout bridge vs native MQTT

Why the Node-RED bridge works well

• No app changes — uses Juggluco's existing Nightscout publisher out of
  the box. Works with any stock release, no fork or build required.
• Gets data onto MQTT — once in the broker, any subscriber (Home Assistant,
  Grafana via Telegraf, Node-RED automations, custom apps) can consume it
  exactly as they would with native MQTT.
• Bonus functionality — Node-RED can enrich the data on the way through:
  persistence to MySQL, email reports, alerting, dashboard visualisation.
• Deployable today — anyone with a Raspberry Pi running Mosquitto and
  Node-RED can have this working in an afternoon.

---

What it misses compared to native MQTT

	Node-RED bridge	Native MQTT
Architecture	Phone → HTTP → Node-RED → MQTT	Phone → MQTT broker (direct)
Infrastructure dependency	Requires Node-RED reachable from phone at all times	Broker only
Single point of failure	Node-RED down = readings lost silently	Broker down = QoS 1/2 queues and retries on reconnect
Network requirement	Phone must reach Node-RED host	Phone must reach broker only
Latency	Two hops (HTTP + MQTT publish)	One hop
Delivery guarantee	HTTP has no retry on failure; Nightscout publisher may silently drop	MQTT QoS 1/2 guarantees at-least-once / exactly-once delivery
Offline resilience	Missed if Node-RED unreachable	Persistent MQTT session queues missed messages for delivery on reconnect
Configuration complexity	Requires Node-RED + MySQL + correct Nightscout URL	Broker host, port, topic — three fields in the app
Transport overhead	HTTP headers + JSON body per reading	Minimal MQTT framing
Payload richness	Nightscout SGV format (sgv, date, type) — what Juggluco sends to Nightscout	Can be whatever the publisher defines — richer fields possible

The fundamental issue

The bridge trades reliability for zero app changes. HTTP fire-and-forget
over a local network is fine most of the time, but MQTT was specifically
designed for the constrained, intermittent connectivity conditions a phone
experiences — moving between WiFi and mobile, going out of range, the broker
temporarily restarting. A native MQTT publisher benefits from the protocol's
built-in session persistence and QoS guarantees at the point of origin, which
no HTTP bridge can fully replicate.

For a CGM specifically — where a missed reading during a hypoglycaemic episode
could matter — the delivery guarantee is not just a technical nicety.