I guess I deserve the questions when I haven’t written documentation yet

You have to implement a callback module for handling the incoming traffic; you can see examples of these in the Tortoise.Handler.Logger, which implement the Tortoise.Handler-behaviour. The key is to do non-blocking calls here, as the process running the handler is the process that own the main controller—in other words, use it to pattern match on the incoming data and dispatch it to other processes!

When you have a connection you can use the client_id you used for the connection in the Tortoise.publish/4. If you publish with a QoS you will get a message in your process mailbox when the message has been handed over to the server—there is a Tortoise.publish_sync/4 variant that will block the calling process until it has been delivered (this of course only make sense for messages with a quality of service bigger than 0, as 0 is a fire and forget)

So: You have to implement a callback behaviour called Tortoise.Handler for receiving messages, which should do as little as possible; just dispatch messages to the rest of the system; and you should use the Tortoise.publish/publish_sync to publish to the broker; then Tortoise should handle the details of the protocol!

Hi, I am the author of Tortoise (as well as the gen_mqtt client/wrapper)

Tortoise is the successor to gen_mqtt; it doesn’t quite work the way I described in a previous post (I have a full time job and all that, so time is scarce which conflicts with really ambitious projects) but I think Tortoise is really nice at separating the MQTT semantics from the Elixir semantics; right now it support publishing and subscribing to topics with Quality of Service 0 through 2; TCP and SSL transports, and it behaves pretty well when it reconnect to the broker.

I still have some way to go before I can call it 1.0, but I’d say it is usable now; everyone who uses gen_mqtt should switch to Tortoise. Don’t be shy if you have any questions

Hi. I did the GenMQTT project that wraps an Erlang module called gen_emqtt that was written by Erlio for their VerneMQ MQTT broker. gen_emqtt used to be in a separate project called vmq_commons, but that project has been moved into the vernemq application, and hence the gen_emqtt is no longer available without getting the entire VerneMQ broker.

GenMQTT is thus deprecated, because I am not going to maintain the Erlang library, since it has some flaws—a proper error kernel being one of them. I am working on an implementation in pure Elixir, and I have some different approaches than Hulaaki. I don’t know how long this will take as I have a fulltime job that doesn’t relate to MQTT.

As for now I would recommend looking into both Hulaaki and GenMQTT; if you decide to go with GenMQTT I will happily accept pull requests.