QL48 - The QL48 Place

Hello

WLED Setup Notes

Architecture Update (2024/09/24)

Having an MQTT Broker for WLED controller subscribing to all topics needed by all modes imply the Controller EC2 Instance to be flowed with data that are no used.

I’m gonna try a different approach.

For data coming from the Cloud (IOT Core):

The “local” MQTT Broker will handle messages from/to Controller - Device
The Controller will use another mqtt connection to subscribe to topic relevants to the mode it is currently running, making sure that when it does switch mode, it unsubscribe from topics needed by the previuos mode.
The controller will still publish to the local MQTT Broker on device topics to control the Leds

Needed Changes

The mosquitto configuration for the MQTT Broker in the Controller instances (no AWS IOT Bridging needed)
The WLED Controller App will manage two connections:
1. To AWS IOT (subscribing to specific topics based on the mode)
2. To Local MQTT Broker to publish/subscribe to WLED device topics

So that’s what I have got so far

This nodejs app that can “listen” to different type of events and send commands to a WLED Device (En ESP32 running WLED and connected to a Single Addressable Led Strip) in response to such events based an specific logics.

The app represents what I call the WLED Controller. The way the events data get in is through MQTT. It is capable of connecting to AWS IoT Core (running aws-iot-sdk and act as a IOT Thing) as well as connect to an MQTT Broker running on the same device the app run on (this can be either a raspberrypi installed locally or a small ec2 instance running in the cloud).

Since to control the WLED device an MQTT Broker is needed anyway (WLED cannot connect to AWS IoT a this time since it miss SSL support), the node app subcribe and publish always to the local MQTT Broker.

To send commands to the WLED unit, it will publish to local MQTT Broker to which the WLED unit subscribe to specific topic (see: WLED Sync Interfaces)
To receive events the app will subscribe to specific event at the Local Broker that is configure as MQTT Bridge so that it can subscribe to AWS IoT Core topics as well as publish data to it.

With this configuration the WLED unit get connected to AWS IoT and make it very easy to integrate things such as:

Run WLED Playlist/Animations whenever an new PullRequest (or any other intersting event into a GitHub repo/org) happen. This become as easy as configure a API Gateway/Lambda function as GitHub event Webhook target and publish Data to IOT topics in response to such type of events. Once the event reach AWS IOT, the Local MQTT Bridge (that is subscribed to such topic) get the data and the node App who is subscribed to that event can run logic and light the WLED Strip.
The same identical setup can easily display on the WLED CloudWatch alarms, Website trafffic, Ecommerce sites sales, Booking Bot events in real time.

Option with remote/public mqtt bridge

The Controller element is responsable of receiving events (GitHub Webhooks, WIFI packets, QM4IL events …). This would tipically be a lambda function behing an API gateway.

When the data is received, the controller run the logic to control the WLED strips by publishing mqtt messages to the device/group topic the WLED strip(s) subscribe to [see: Syncing Interfaces]

Now, WLED cannot connect to AWS IOT Broker, since it doesn’t support SSL, so a mosquitto MQTT Brigding Broker is needed.

The following is how the MQTT configuration might look like for the wled1 device in the Ql48/WLED environment.

{
    "en": true,
    "broker": "18.195.204.215",
    "port": 1883,
    "user": "wled1",
    "pskl": 4,
    "cid": "wled1",
    "rtn": false,
    "topics": {
        "device": "Ql48/WLEDS/wled1",
        "group": "Ql48/WLEDS/all"
    }
}

And this is how the mosquitto bridge configuration might look like:

Basic Config:

# Listener
listener 1883 0.0.0.0

# User
user mosquitto

# Auth
password_file /usr/local/etc/mosquitto/passwd

# Logging
log_type all

AWS IoT Core Bridge Configuration

connection AWSIOT

address a3jrny6g05hjqv-ats.iot.eu-central-1.amazonaws.com:8883

topic Ql48/WLEDS/# in 1

bridge_protocol_version mqttv311
bridge_insecure false

cleansession true
clientid EC2MQTTBrokerDefault

start_type automatic
notifications false

bridge_cafile /usr/local/etc/mosquitto/certs/aws-root-ca.pem
bridge_certfile /usr/local/etc/mosquitto/certs/certificate.pem.crt
bridge_keyfile /usr/local/etc/mosquitto/certs/private.pem.key

This line:

Ql48/WLED/# in 1

make sure that each message received by AWS IoT Core from this topic will be forwarded to the local gateway to which the WLED device is subscribed.

This is how, now is possible to control the “local” WLED device by publishing to IoT.

For example this piece of code is from a lambda that receives GitHub Webhook data and publish them to IoT to play an playlist on a WLED


const { body, headers } = event 
const payload = JSON.parse(
    body
);
const GitHubHeaders = filterGitHubHeaders(
    headers
);

const eventType     = GitHubHeaders['X-GitHub-Event'];
const signature     = GitHubHeaders['X-Hub-Signature'];
const signature256  = GitHubHeaders['X-Hub-Signature-256'];

// TODO:
// Validate delivery

// Data to publish to IOT
const publishData = {
    event: eventType
}

await dataPlanePublish(
    TOPIC.githubEvent,
    publishData
);

Dyndns Me