brianmay

Any recommendations on a MQTT client for Elixir?

Hello,

Is there a good mqtt client library for Elixir? Getting a bit disillusioned, none of the options seem very good.

GitHub - gausby/tortoise: A MQTT Client written in Elixir - initially seemed very good. Particularly with the rewrite mqtt-5 support - which I suspect is in the mqtt-5 branch. But has numerous bugs, particularly when mqtt server goes down (pub requests can hang - hanging my application) or if trying to dynamically subscribe to topics at run-time. These errors aren’t always easy to reproduce on demand, and at one stage I was told that there were fundamental design issues. Was looking forward to the rewrite, but development has stalled, and status unclear. I don’t blame the author in anyway (I have a lot of projects in this state myself). Would consider contributing to mqtt-5 branch development if this is the best option.
GitHub - brianbinbin/exmqtt: Elixir MQTT v5.0 Client - no development for 15 months. But does support MQTT 5 - according to description at least.
A number of other options that look hopeful, but looks like development has also stalled.
Maybe I should be looking at erlang solutions? e.g. GitHub - emqx/emqtt: Erlang MQTT v5.0 Client looks like it is actively maintained.

So wondering what the best option forward is. Examples:

Take over the development of the mqtt-5 branch on tortoise.
Take over another project.
Learn about MQTT-5 and start my own project from scratch?
Write Elixir wrapper for Erlang solution.

I tend to favor the last option right now. Unless of course somebody has already written such a wrapper.

But would appreciate any opinions,

51 comments

#mqtt

23 7832 51

2023-09-15 23:34:56 UTC

Marked As Solved

Sebb

I would go with emqtt.
There seems to be zero documentation on the web how to use it with Elixir.
We should change that.

Here is a starting point. (connects to test.mosquitto.org with no auth and subscribes to # so you get lots of messages)

deps (latest - 1.4.0 - seems to be out of sync with the docs in readme)

{:emqtt, github: "emqx/emqtt", tag: "v1.2.0"},

some code

defmodule MqttHowto do
  def hello do
    opts = [
      clientid: "my_client_id",
      host: 'test.mosquitto.org',
      port: 1883
    ]

    {:ok, pid} = :emqtt.start_link(opts)
    {:ok, _} = :emqtt.connect(pid)
    {:ok, _, _} = :emqtt.subscribe(pid, %{}, [{"#", []}])

    recv()
  end

  def recv() do
    receive do
      message -> IO.inspect(message)
    end

    recv()
  end
end

Post #5

Also Liked

brianmay

I think there are Two questions here, which I will answer:

Why create a separate project?

I will face the same challenges regardless if I add the code directly to my project or not. Plus this way I am more likely to be able to get help, then if it it integrated into my project with numerous external dependencies. And I get to reuse the same code in my other projects.

There is at least one other open source software project I use that uses tortoise. Would be good to move these projects to something better supported. In fact based on the tortoise bug reports I see, I think there are a number of people who incorrectly feel that is the only option available. So demand might be higher then you think.

Why base on project that is 2 years old?

The code structure + my changes is very similar to what I would be used anyway, and similar to what my existing code already expects (being based on tortoise).

While your code certainly looks simple, I believe it wouldn’t try to gracefully reconnect if there is a connection error. In fact a connection error will kill the process that called hello - as I discovered earlier - because the emqtt process is linked, when the connection dies, it dies, which will in turn kill the calling process. As these are long running processes, that is important for me, and where most of the complexity lies.

Yes better documentation would be very useful. e.g. Took me ages to work out how to get mqtt over TLS working with peer verification enabled.

Post #10

brianmay

Your theory makes sense. But if I don’t specify port: 8883 I get symptoms that look identical to what you observed. Which is somewhat weird and confusing.

… Oh wait, that default is only applicable for the CLI I think.

Post #24

Hanspagh

I have been using tortoise in production for a while now, without any major issues. The latest release fixed some of the problems we have had. Our use case is very simple, so maybe that is why we haven’t hit any of the problems you described

Post #36

brianmay

GitHub - ryanwinchester/exmqtt: Elixir wrapper for emqx/emqtt - interesting. No development for 2 years. But might be really good starting point.

Post #2

brianmay

Hmmm. Something weird with emqtt. exmqtt a lot of nice logic to handle gentle back-offs with retries if there is a connection fault. But none of this actually gets used.

Still not 100% clear what is going on. It appears that emqtt.connect(conn_pid) |> IO.inspect() returns and will print the error result. But if I have a call to IO.puts("xxxx") immediately following, it will never get called. Then the genserver process gets recreated 4 times.

Initially I thought maybe an exception is being generated and silently discarded. But I can’t see any evidence of this actually happening.

I think that the genserver process is silently getting killed by another process immediately after an error. And the supervisor recreates it 4 times, before the supervisor dies. Which is standard supervisor behavior. But the supervisor doesn’t print any messages about the process having died. But still is my most likely theory. Maybe the supervisor sees it as a normal exit, not an error exit, so doesn’t print anything.

If correct, this is a bit awkward, I want to process the errors myself, and not have my genserver killed.

If anybody else is interested in testing, I can publish my test code and it should be easy to reproduce.

Post #3