OMG with embedded broker?

Theengs OpenMQTTGateway
1

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:

Michael

2

Hello,

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?

3

(post deleted by author)

4

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

Michael

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

-Michael

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

5

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 ;?