Use of MQTT in Snap! projects

DRAFT _ WORK IN PROGRESS :slight_smile:

The basic use of MQTT in Snap! lets you send a message to a broker on a particular topic and then that broker will forward the message onto other programs running on other computers subscribing to the same topic on the same broker.

The converse is true, someone can send a message to a broker on a particular topic from another program (libraries are available for all the usual programming languages) and Snap! can subscribe to that topic and receive a message every time the other computer/program sends one out

FAQ - Can I store a message on a broker at say 3pm, and someone connect to the same broker and topic at 4pm and retrieve the message?

Also, the free public brokers have no guarantee of service and may delete any messages and topics at anytime. They may also, have topic storage and rate limits on them and they may IP ban you if you exceed these

Do do this, you need to set the second option of your published message to true

Any message published using this option, will be stored on the broker (it is termed a retained message) and as long as no other messages are published to the broker on that topic (or the broker is reset/cleared by it's system administrators) the message will remain on the broker indefinitely

To erase a message retained in this manner, you just need to send an empty payload on the same topic

Ugh, the options have an undocumented fixed order? What a kludge. Sooner or later I'm going to convince Jens that we need a category of 0/0/1 (min, default, max number of slots) multiple inputs with labels, so it could be "options :arrow_forward::arrow_forward::arrow_forward:︎" for however many options there are, and if you click the second one it turns into "retain: <● >" (that's ascii-art for a Boolean slot) and the same for the others. Or, I guess even better, a multiple input group consisting of a menu of option names and an Any slot, so you could choose "retain" from the menu and drag in a True, so you don't have to remember which arrowhead to click. Or, if all the options are Boolean, we could just have a multiple-slot menu with the names, and turn on the ones the user chooses.

Labeling of options would be great :slight_smile:

BTW. The options are not undocumented - they are mentioned in the block help :slight_smile:

But no-one reads helps :slight_smile:

Is the help menu new with the recent updates? The blocks previously did not have a help menu.

The help text has been there for a while. Only thing I did last release was to correct a spilling mistook

Sorry, what I meant was, not self-documenting in the block itself.

One of the reasons why I never learned Smalltalk was that the first example of creating a method was something like

method foo [] [] [] [bar, baz]

(I'm sure I have the details all wrong) and when I finally got my tongue rolled back into my mouth I had lost my motivation.

I think I was better able to tolerate such interfaces in my youth. There are things a little like that in Berkeley Logo, although the fields are closely related to each other, and the same set of options occur in a bunch of different contexts so you only have to learn it once.

ERASE [[proc1 proc2 ...] [var1 var2 ...] [plist1 plist2 ...]]

The input is called a "contents list" and the three pieces are in order of common use, so you can say ERASE [[proc1 proc2 ...]] and it's only if you have only property lists to erase (or save or print out etc.) that you need [[ ] [ ] [plist1 plist2 ...]]. (And we also accept ERASE [proc1 proc2 ...] not inside an outer list wrapper, or ERASE "proc1 if there's only one procedure involved.)

The new facilities in the dev version should solve the documenting issue :slight_smile: