OMG with embedded broker?

was it ever considered to add an embedded broker to OMG - for example PicoMQTT?

I am aware this sounds like a whacky idea

however, it would cover a scenario which are hard to cover otherwise:

  • no stable net connectivity to use an external broker
  • clients which are unable to run a broker (for instance a mobile app)
  • running a separate broker on a third device would be too cumbersome

feel free to shoot down the idea :wink:



I tested picoMQTT and tinyMQTT on an esp32 without any added program. Had better success with pico than tiny.

What would be your use cases behind these scenarios?

(post deleted by author)

use cases:

(1) I’m helping Kelvin with his sensor-logger project which started out as a logger for sensors in a mobile but since has become a more generalized logging tool which can live-push via MQTT and log advertisement-based BLE sensors

adding external sensors was always a theme for me, and Kelvin will add what we called “MQTT sensors” - basically a MQTT subscription

that begs the question “where is the broker” - if there’s net connectivity, not an issue

for instance, to integrate OMG one could have publish it to some cloud-based broker, and have sensor-logger subscribe to topics there - done

that doesnt work if no net connectivity, and it adds quite some roundtrip time ontop

so my idea was to see if a broker can be integrated into OMG, have OMG Wifi-connect to the mobile’s hotspot, and sensor-logger subscribe to topics on the “local” broker in OMG

(2) I’m working on an instrument which could be either an embedded controller with display, or a PWA say on Android - in the first case custom sensors are easy, in the second case not so much - the crippled BLE browser API stands in the way

using say paho mqttjs is an option, again begginng the question “where’s the broker” if no net connectivity; a local broker in OMG would fix that, assuming the custom sensors are made to work with OMG (which either is the case or should be straightforward)

I’ve played with (2) and paho mqttjs needs MQTT-in-websockets which PicoMQTT doesnt support. I tried a Websockets-to-TCP proxy with ArduinoWebsockets which I’m still struggling with (works with paho mqtt python/ws but doesnt with paho mqtt js - some handshaking issue during setup)

that’s the backdrop for the idea


PicoMQTT vs TinyMQTT: same results here. I also tried EmbeddedMQTTBroker - not quite up to the task.

Unfortunately PicoMQTT is GPL3

meanwhile, I have made some progress on the MQTT-over-websockets support for PicoMQTT

see issue 28 of the github PicoMQTT repo


ps: unsure why the original post was tagged as spam, reposting without links

Michał Leśniewski’s PicoMQTT broker works with MQTT-over-websockets with a simple websockets proxy I built

meaning any MQTT-over-websockets client like Paho MQTT/JS&Python or MQTT.js can talk to it, as can Kelvin’s sensorlogger

this is an interim solution until we have PicoMQTT enabled to talk websockets natively

in the OpenMQTT Gateway this would mean one could connect directly to OMQ with a webapp without an external proxy

still unconvinced ;?