MQTT 3.1.1 in pure LCscript

[ClipArtGuy]

Working on an MQTT 3.1.1 library that is fully compatible with LCC 9.6.3. Here's a video of some tests in action:

https://youtu.be/lH-XMPhwm6o

Anybody over here interested in something like this?

This is what a super simple MQTT enabled appp would look like in 10 lines:

Code: Select all

-- Complete working app
on openstack
mqttSetCallbackTarget the long id of this card
mqttSetMessageCallback "onMessage"
mqttConnect("broker.hivemq.com", 1883, "myApp", "", "", 60, false, true, "", "", 0, false, false, false, "")
wait until mqttIsConnected("broker.hivemq.com", 1883) with messages
mqttSubscribe "broker.hivemq.com", 1883, "sensors/#", 0
end openstack 

--put callback handler in card script.
on onMessage pTopic, pMessage
   put pMessage into field "Display"
end onMessage

[stam]

Interesting... out of curiosity, what would you be using this for?
Looking at the MQTT protocol it seems like fairly standard publish/subscribe but over the net, and perhaps unnecessarily over-complicated.
Are you implementing the full MQTT spec? how are you deploying this with LiveCode if I may ask?

[ClipArtGuy]

Good questions!

What it's for:
MQTT is the standard protocol for IoT devices. If you want to connect LiveCode to smart home devices, industrial sensors, or cloud IoT platforms, MQTT is what they speak. It's also useful for any scenario where you need lightweight real-time messaging: chat apps, live dashboards, or distributed systems. I work in a facility with many sensors, devices, PLCs, etc that "speak" MQTT. This will make it easy to implement a dashboard/control center easily in a stack.

Why not just REST/HTTP?
MQTT is persistent bidirectional. One connection stays open and both sides can send anytime. HTTP requires the client to constantly poll "any updates? any updates?" which wastes bandwidth and adds latency. For a sensor sending data every second, or a dashboard needing instant updates, MQTT is much more efficient.

The "over-complicated" part:
The core is simple (publish/subscribe), but the spec adds reliability features:

• QoS levels: Choose between "fire and forget" (QoS 0), "at least once" (QoS 1), or "exactly once" (QoS 2)
• Persistent sessions: Broker remembers your subscriptions if you disconnect
• Last Will: Broker auto-publishes a message if you disconnect unexpectedly
• Retain flag: New subscribers instantly get the last message

You don't need to use these features, but they're available when you need guaranteed delivery.

Spec coverage:
Yes, I'm implementing the full MQTT 3.1.1 spec. All QoS levels, wildcards, TLS, keep-alive, etc. The test suite in the video validates against HiveMQ Cloud.

Deployment:
It will be a script-only library stack. Add it to your project,

Code: Select all

start using stack "MQTTLibrary"

, and you're done. No external dependencies, no plugins, pure LiveCode talking TCP sockets to the broker.

[stam]

Yeah, I guess the part I don't quite get is open persistent bidirectional connection.

I draw parallels from app-level pub/sub (eg https://github.com/stam66/skPubSub - but this lightweight implementation does not ensure message is received or store a last will and testament etc. I suppose this can't be too difficult to implement though).
In this, the broker has a list of all messages and subscribers and immediately sends a command to a subscriber when a message is broadcast, but as a "fire and forget" method.

I suppose in an IoT environment this means each subscriber having an active listener since the server by default always listens.
Does that mean having a persistent socket connection in your case? Does that present any issues in and of itself?

This does look interesting; right now I have no use for this, but it's conceivable I will in the future.
Happy to help with beta testing if needed - let me know.

[christoph]

Could this be used to connect to Arduino Wifi boards?
That would be interesting!
There is a library for the arduino at: https://docs.arduino.cc/tutorials/uno-w ... to-device/

[ClipArtGuy]

Does that mean having a persistent socket connection in your case?

Yes - one persistent TCP socket per broker connection. The library uses LiveCode's native open socket with non-blocking reads (read from socket ... with message). Socket callbacks fire on incoming data, so your app never blocks.
Key difference from skPubSub: MQTT is network-based with a remote broker. Your library is perfect for in-app messaging, MQTT adds network resilience: automatic reconnection with exponential backoff, broker-side message queuing during disconnects (QoS 1/2), and guaranteed message delivery even across network failures. Think of it as skPubSub that works across the internet with reliability guarantees.


Reply to christoph:

Could this be used to connect to Arduino Wifi boards?

Absolutely! Arduino Uno WiFi R4 (or any ESP32/ESP8266) publishes sensor data to an MQTT broker, LiveCode subscribes to receive it. Both use the same broker as middleman.
Setup flow:

Arduino: Publishes to sensors/temperature every second
Broker: Routes messages (cloud like HiveMQ or local Mosquitto)
LiveCode: Subscribes to sensors/# wildcard, callback fires on each update

The library handles TLS (for secure cloud brokers), QoS levels (choose speed vs. reliability), and automatic reconnection if WiFi drops. That Arduino tutorial's MQTT library is fully compatible.


I should have time this evening to finish cleaning up the script and post it here as an alpha version under GPL3

[ClipArtGuy]

libMQTTxt v0.0.1 ALPHA - MQTT 3.1.1 Client Library for LiveCode

Alpha release of a pure xTalk MQTT client library for LiveCode Community. Seeking testers for protocol compliance and edge case validation.

Implementation Status

• MQTT 3.1.1 protocol support (QoS 0, 1, 2)
• TLS/SSL encryption (without certificate verification)
• Auto-reconnection with exponential backoff
• Keep-alive with configurable threshold
• Wildcard subscriptions (+ and #)
• Retained messages
• Last Will and Testament
• Persistent sessions
• Binary-safe message handling
• Multiple simultaneous connections

Architecture Notes

The library uses custom properties to pass data from the library stack to your callback handlers:

• Incoming messages are stored in cMQTT_Topic and cMQTT_Message custom properties
• Library sends message to callback target to invoke wrapper handler
• Wrapper reads custom properties and dispatches to your actual handler

This approach ensures reliable message delivery in script-only stacks. Your callback target card requires the __mqttInvokeCallback wrapper (included in test suite).

Quick Start

Code: Select all

-- Load library
start using stack "libMQTTxt.livecode"

-- Configure callbacks
mqttSetCallbackTarget the long id of this card
mqttSetMessageCallback "onMqttMessage"

-- Connect to public broker
put mqttConnect("broker.hivemq.com", 1883, "testClient", "", "", \
                60, false, true, "", "", 0, false, false, false, "") into tResult

-- Subscribe and publish
mqttSubscribe "broker.hivemq.com", 1883, "test/topic", 0
mqttPublish "broker.hivemq.com", 1883, "test/topic", "Hello MQTT", 0, false

-- Callback wrapper (required on your card)
on __mqttInvokeCallback
   global gMQTTMessageCallback
   local tTopic, tMessage
   put the cMQTT_Topic of me into tTopic
   put the cMQTT_Message of me into tMessage
   dispatch gMQTTMessageCallback to me with tTopic, tMessage
end __mqttInvokeCallback

-- Your message handler
on onMqttMessage pTopic, pMessage
   put pTopic && pMessage
end onMqttMessage

Test Suite

Included test script validates many test cases:

• Library initialization and self-test
• Configuration functions
• Connection establishment (plain and TLS)
• QoS 0, 1, 2 message delivery
• Wildcard subscriptions
• Retained messages
• Multiple topic handling
• Binary data support
• Large message handling
• Error validation
• Statistics tracking
• Live connection monitoring

Test suite provides real-time feedback and verifies protocol compliance against public brokers.

Known Limitations

• Alpha quality - expect issues
• No MQTT 5.0 support
• TLS certificate verification not implemented (uses "without verification")
• Persistent store implementation is basic

Testing Instructions

1. Load both stacks (library + test suite)
2. Configure broker details in test UI fields
3. Click "Run All Tests"
4. Review results in output field
5. Press ESC during monitoring to disconnect

Public test brokers (no registration):

• test.mosquitto.org:1883
• broker.hivemq.com:1883
• broker.emqx.io:1883

Feedback Requested

• Connection stability across different brokers
• QoS 2 handshake reliability
• Auto-reconnection behavior
• TLS/SSL connection stability (no verification)
• Performance with high message rates
• Binary data edge cases
• Cross-platform issues

Files

• libMQTTxt.livecode - Library (script-only stack)
• test stack - Test suite (card script with UI)

License
GPLv3 - See library header for full terms.

Requirements
LiveCode Community 9.6.3+ or OXT-lite