Extensions in Scratch let you add additional blocks to the palette. I’ve written about how to create extensions before, but in this post I want to share my latest extension which adds MQTT support.
I don’t have a particular Scratch project in mind for this yet, but publishing and subscribing to an MQTT broker from a Scratch project would allow multiple web browsers each running Scratch to communicate with each other. I’m sure there are some fun things this could be used for.
Connecting to an MQTT broker from Scratch
To connect to an MQTT broker:
- Add the new MQTT extension
- Choose which broker you want to connect to
- Click on Go to editor
MQTT blocks in Scratch
The extension adds three new blocks:
publish– publishes a message to an MQTT topicnew message– fires when a new message is received on an MQTT topicmessage– contains the most recent message from an MQTT topic
Demonstrating the MQTT blocks in Scratch
Here is a simple project that shows the new blocks in action.
I have two sprites:
sender
This will publish an MQTT message when you click on the sprite
postman
This will display MQTT messages when they are received
Giving the project a try…
Communicating between Scratch browsers using MQTT
Sending and receiving a message in one browser isn’t very interesting, as Scratch already has blocks to send and receive events.
Where this gets interesting is in being able to communicate between multiple browsers, running on different machines.
A warning
All of the MQTT brokers I’m using in the extension are public. This means that every message that is published is available for anyone in the world to see. As such, this isn’t appropriate for publishing anything private or sensitive.
Ideas?
I’ve added this to the version of Scratch that I run at scratch.machinelearningforkids.co.uk.
What could this be used for? What sort of games and projects could be enabled by allowing multiple student projects to communicate with each other?
If you give anything like that a try, please let me know how you get on!
Hello I would like add a new MQTT broker, but I don’t know how do that.
Please, could you help me?
Best regards,
José
@José – what broker would you like added?
Thanks for the extension. It’s something I’ve wanted for my students for some time. We often build microcontroller projects (…mainly using the ESP32 and https://github.com/QuirkyCort/IoTy), and wanted a way to use the microcontroller to control a Scratch game.
Noticed a couple of bugs / limitations in your extension (…tested with Chrome on Linux using the mosquitto broker)…
1) The “new message from” block does not work if “when green flag clicked” is not running. If I use these blocks…
new message from scratch/mqtt
say message from scratch/mqtt
…and then publish a message to test.mosquitto.org (…using mosquitto_pub on the commandline), nothing will be received. I can work around this by adding…
when green flag clicked
forever (empty)
…and clicking the green flag before publish.
2) If 2 messages are published in rapid succession, this seems to “crash” the receiver process somehow. The first message will be received, the second message will not. Any messages published after that will also not be received. I can recover from this by clicking the red stop button, then re-clicking the green flag. Example code…
new message from scratch/mqtt
say message from scratch/mqtt
when green flag clicked
forever (empty)
when this sprite clicked
publish timer to scratch/mqtt
publish second_msg to scratch/mqtt
Test procedure…
– Click the green flag.
– Click the cat sprite. It should say some number (…based on the timer). It will not say “second_msg”.
– Click the cat sprite again. The number in the text bubble will not change (ie. it is not receiving any more messages).
If the source for your extension is published somewhere, I can take a look through and probably file a better bug report.
Sorry for the messed up formatting. Didn’t expect the newlines to be stripped. Don’t know how to work around the comment formatting issue, so I’m putting the bug report in a text file here https://files.aposteriori.com.sg/get/HdQJEmqUct.txt This should be more readable.
@Cort – thanks very much for the feedback, much appreciated
> The “new message from” block does not work
> if “when green flag clicked” is not running.
That’s not exactly true, however you do need to click on the Green Flag to start the script.
It connects to the MQTT broker when you click on the green flag. It disconnects when you click on the red stop button.
I feel like this is standard Scratch behaviour.
> I can work around this by adding…
>
> when green flag clicked
> forever (empty)
>
> …and clicking the green flag before publish.
You don’t need to add the no-op code. Clicking on the Green Flag is enough.
To see an example of this, see https://www.youtube.com/watch?v=LF65rFQehb4
> If 2 messages are published in rapid succession, this
> seems to “crash” the receiver process somehow. The
> first message will be received, the second message
> will not. Any messages published after that will also
> not be received.
That’s not exactly true. What I think you’re describing is what happens if your “new message” block takes longer to run then how frequently new messages are received. Messages are queued as they’re received, and when you use the “message from” block you are taking a message from the queue.
To see an exaggerated example of this, see https://www.youtube.com/watch?v=ejylbUP_PV4
Thanks for the clarification.
I’m not sure if it’s standard Scratch behavior to require clicking a green flag first; none of the standard Scratch event blocks requires that (eg. a key press event will trigger regardless of whether the green flag was clicked). I see from the developer console that the connection to the broker is made when the broker is selected, but subscription only occurs when the green flag is clicked.
Perhaps I can suggest a few alternatives…
1) Trigger the subscription / unsubscription when the “new message” block is added / removed / modified from the workspace. It should be possible to detect these through addChangeListener.
2) Make the subscription / unsubscription explicit through a block (ie. the script must run a “subscribe” block before the “new message” event works.
3) Document the requirement for the green flag, perhaps on the connection window? I personally like to add tooltips to all my blocks, but that doesn’t seem to be the Scratch way.
For the issue with multiple messages, I see now that the “new message” event won’t trigger if there are messages remaining in the queue. I feel that this behavior is not intuitive. Perhaps I can suggest queuing the “new message” events, so that it always trigger once for each new message.
Regardless of your decision in this, I appreciate the work you have done. Thanks!