spin-trigger-mqtt VS spin-mqtt-booth-volume-app

The MQTT trigger is a feature of the Spin framework that allows a Spin application to subscribe to a specific MQTT address. Individual components within that application can then be configured to monitor particular topics at the address. When messages are detected on these topics, the corresponding component functions are triggered.

Let’s start by looking at the implementation of our first component, which is triggered by messages published to an MQTT topic and persists the data in a SQLite database. It is implemented in Rust and was scaffolded using the MQTT template. In the Spin application manifest (spin.toml), we are using a Spin application variable to dynamically configure the address for the MQTT broker. This will enable us to set Spin to connect to a broker at "mqtt://localhost:1883" when running locally and at "mqtt://emqx.default.svc.cluster.local:1883" when running in SpinKube. We also set the keep alive interval (secs) for connections with the broker and username and password authentication credentials. In this example application, the broker does not require authentication, so the credentials are left empty.

In this blog, we will learn how to compose a full-stack, IoT Spin application and deploy it to Kubernetes via SpinKube. First, we will dissect our full-stack Spin application, that not only consumes data from the MQTT sound sensors but also contains a frontend to visualize the collected data. Next, we will deploy our Spin application to Kubernetes using SpinKube which now supports the MQTT trigger. We will use a mock MQTT device for our demo, but the repository that hosts the example contains steps for configuring a WiFi enabled arduino board in case you want to bring this to your booth.